Build Dynamic NFTs on LUKSO
If an NFT's traits evolve, levels accrue, or its art changes on a schedule, metadata has to be data — not just a URL. LSP8 makes that distinction structural rather than bolted on: every token's attributes, image reference, and provenance live under typed LSP4 keys on the token contract, and updates go through setDataForTokenId(tokenId, key, value) — gated by LSP6 permissions. No metadata refresh button on a marketplace, no off-chain server required for state to change, no ERC-4906 update event bolted on after the fact.
The stack
| Standard | Role |
|---|---|
| LSP8 | Ownership + per-token bytes32 IDs |
| LSP4 | Collection and per-token metadata under typed keys |
| ERC725Y | The typed key-value storage substrate underneath LSP4 |
| VerifiableURI (LSP4 option) | Integrity guarantees when off-chain media is still involved |
| LSP1 | Receiver hook so profiles can react when the NFT lands |
When this vertical fits
The asset has per-token state that mutates over time, and that state needs to be readable by any app — not just yours. The token ID itself might carry meaning (a content hash, a serial). And you don't want to rely on users clicking "refresh metadata" every time a marketplace's cache goes stale.
If marketplace compatibility on day one is the entire product — the collection has to list on every major NFT venue immediately — ERC721 is the pragmatic path, tokenURI tax included. LSP8 is the right call once dynamic, per-token, on-chain state is a real requirement rather than a nice-to-have.
Related reading: ERC721 vs LSP8 · ERC721's dynamic metadata problem · ERC721 token ID limits · Migrate ERC721 to LSP8