Dynamic NFTs.
Building stateful, evolving, generative NFTs on LUKSO uses LSP8 (per-token bytes32 IDs), LSP4 (metadata under ERC-725Y typed keys), and LSP1 (transfer receiver hooks). Each token's attributes, traits, image reference, and provenance live under typed keys on the token contract; updates go through `setDataForTokenId(tokenId, key, value)` gated by LSP6 permissions. No metadata refresh button, no off-chain server required for state changes, no ERC-4906 event bolted on — dynamic behavior is built into the standard rather than patched over it.
If the NFT changes — traits evolve, levels accrue, music reveals, art shifts on a calendar — then metadata is data, not a URL. LSP8 makes that distinction structural.
When this vertical fits
The asset has per-token state that mutates. The state should be readable by any app, not just yours. The token ID itself might mean something (a content hash, a serial). You don’t want users hitting “refresh metadata” because the marketplace cache went stale.
When ERC-721 is still the right call
Marketplace compatibility is the product. If the collection has to list on every major NFT venue out of the gate, ERC-721 is the path — even with the tokenURI tax.
The minimum stack
- LSP8 for ownership + per-token data
- LSP4 for collection metadata
- ERC-725Y for typed key-value storage (per-collection and per-token)
- VerifiableURI when the off-chain media needs integrity guarantees
- LSP1 on the receiver side for profiles that want to react when the NFT lands
Reading list.
A curated path — problem → standard → migration.
- [ 01 ] problem The tokenURI trap
- [ 02 ] problem uint256 tokenIds were always a compromise
- [ 03 ] LSP8 Identifiable Asset — the spec
- [ 04 ] LSP4 Digital Asset Metadata
- [ 05 ] compare ERC-721 vs LSP8
- [ 06 ] migrate Migrate ERC-721 → LSP8