CIP-68 splits an asset into a pair that shares one policy id: a reference token (asset-name label 100) that holds the metadata, and the user-facing token the holder actually owns (222 for an NFT, 333 for a fungible token, 444 for a rich fungible token). The metadata itself is stored as an inline datum on the UTxO that carries the reference token, so any Plutus script can read it directly on-chain instead of relying on off-chain indexers, which is something CIP-25 metadata cannot offer.
This design makes metadata programmable: because the reference token's datum can be spent and recreated by an authorized transaction, traits can evolve (game items that level up, dynamic art, identity records) while collectors keep holding the same user token. The cost is more moving parts than CIP-25, so simple static collections often still use CIP-25 while projects that need contract-readable or updatable metadata reach for CIP-68.
Sources
Explore next
- DatumA piece of data attached to a UTxO that a smart contract can read when deciding whether the UTxO can be spent.View term
- Native TokenA token created and managed directly on the Cardano blockchain using its built-in token functionality, without requiring smart contracts.View term
- NFTA token that represents ownership of a specific unique item, recorded on-chain; anyone can copy the picture, but only one wallet holds the original record.View term
- CIP-25The convention that tells wallets and marketplaces how to read an NFT's name, image, and attributes from the metadata attached when the token was minted.View term
- Reference InputAn input a transaction reads without consuming, letting a smart contract look at on-chain state without locking it out of other transactions.View term