CIP-68: Datum Metadata Standard for Cardano Tokens

introduction

NEXT-GENERATION TOKEN METADATA ARCHITECTURE

What is CIP-68?

CIP-68 defines a new on-chain metadata standard for Cardano native assets, enabling a single UTXO to carry both a reference NFT and a fungible token with rich, programmable datums.

CIP-68 is a Cardano Improvement Proposal that introduces a datum-based metadata standard, fundamentally changing how fungible and non-fungible tokens are structured on the ledger. Unlike CIP-25, which attaches metadata directly to a token's minting transaction, CIP-68 uses a pair of assets held within a single UTXO: a reference NFT that stores metadata in its transaction output datum, and a separate fungible or non-fungible token whose logic can reference that datum. This separation allows for metadata to be updated by the reference NFT holder without requiring a new minting policy, solving a critical limitation of the first-generation standard.

The operational impact for builders is significant. A CIP-68 token is identified by its policyID and an assetName that follows a strict label convention (e.g., 000de140 for the reference NFT and 000de140 for the user token). Wallets, explorers, and marketplaces must be updated to parse these datum fields and correctly display the associated metadata. For DeFi protocols, this standard enables more complex asset logic, as the reference NFT's datum can be read by Plutus scripts via reference inputs, allowing for on-chain validation of token properties without consuming the metadata UTXO. The standard also introduces a version field in the datum, providing a built-in upgrade path for metadata schemas.

Adopting CIP-68 is not a simple drop-in replacement for CIP-25; it requires a deliberate migration strategy. Projects must decide whether to issue new assets under the standard or build a bridge mechanism for legacy tokens. Custodians and exchanges need to update their asset indexing and balance-tracking logic to recognize the paired asset structure. Chainscore Labs can provide an upgrade readiness review for teams planning a CIP-68 migration, including a compatibility assessment for wallet integrations, a script architecture review for Plutus-based metadata validation, and a monitoring plan to ensure correct datum parsing across ecosystem indexers.

NEXT-GENERATION ASSET METADATA ARCHITECTURE

CIP-68 at a Glance

Operational impact matrix for teams evaluating the shift from CIP-25 to the CIP-68 datum metadata standard

Area	What changes	Who is affected	Action
Asset structure	Single UTXO holds a reference NFT and user token, with metadata stored in the reference NFT's datum	NFT projects, minting platforms, DeFi protocols	Redesign minting transactions to output two tokens in one UTXO; verify datum schema compliance
Metadata lookup	Metadata moves from transaction metadata (off-chain indexable) to on-chain datums, requiring script or query-layer access	Wallets, explorers, marketplaces, indexers	Update indexing infrastructure to parse datums; wallets must support datum display for asset identification
Wallet integration	Wallets must recognize CIP-68 token pairs as a single logical asset and display datum fields correctly	Light wallets, hardware wallets, custody platforms	Audit asset display logic; implement CIP-68 detection heuristics; test against reference implementations
Smart contract interaction	Plutus scripts can read and enforce metadata logic on-chain, enabling royalty enforcement and trait-based rules	DApp developers, DeFi protocols, NFT marketplaces	Review script assumptions about metadata location; migrate from off-chain metadata trust to on-chain datum validation
Migration from CIP-25	Existing CIP-25 NFTs remain valid but lack on-chain metadata programmability; dual-standard support needed during transition	Established NFT collections, secondary marketplaces	Plan migration path for legacy collections; implement dual-read logic for CIP-25 and CIP-68 during coexistence period
Exchange and custodian support	Deposit and withdrawal flows must handle CIP-68 token pairs without breaking balance checks or asset identification	Centralized exchanges, custodians, OTC desks	Update asset ingestion pipelines; test deposit/withdrawal with CIP-68 test assets; verify fingerprint generation
Governance and upgrade readiness	CIP-68 is a voluntary standard; adoption depends on ecosystem coordination rather than protocol-level activation	Standards working groups, ecosystem coordinators	Monitor CIP status in the official repository; participate in community testing and feedback cycles

technical-context

EUTXO OPTIMIZATION

Technical Architecture: The Single UTXO Model

How CIP-68 rearchitects asset minting to issue a fungible token and its associated NFTs within a single transaction output, resolving the fragmentation of CIP-25.

CIP-68 fundamentally departs from the CIP-25 metadata standard by collapsing the minting of a collection into a single UTXO. Under CIP-25, a typical NFT project mints a distinct token in a separate UTXO for each asset, leading to linear blockchain state growth and complex, multi-UTXO transaction construction for marketplace and DeFi interactions. CIP-68 introduces a reference NFT and a user token minted together in one output, where the reference NFT acts as a pointer to the collection's metadata, and the user token is the tradable asset. This architecture is enabled by Cardano's extended UTXO (eUTXO) model, which allows multiple native assets to coexist in a single output and leverages inline datums to store structured metadata directly on-chain.

The standard defines a specific datum structure attached to the output, containing a map of metadata fields for the collection and individual tokens. The reference NFT is identified by a standardized asset name prefix (000643b0 for the reference token, 000de140 for the user token), allowing indexers, wallets, and marketplaces to parse the output deterministically without off-chain metadata aggregation. This single-UTXO design drastically reduces the transaction size and execution cost for common operations like listing an NFT for sale, as the smart contract only needs to consume and recreate one output containing both the asset and its verifiable metadata, rather than assembling a complex transaction referencing multiple UTXOs.

For builders, the operational impact is a migration from off-chain metadata management to on-chain datum construction. Minting services must generate the correct CBOR-encoded datum and attach it to the transaction output. Wallets and explorers must update their indexing logic to parse the new asset name prefixes and datum schema to correctly display collections. DeFi protocols integrating CIP-68 assets must adjust their script logic to validate the datum of the single UTXO rather than relying on external metadata. Teams currently operating on CIP-25 should treat a migration as a new minting event, as the standard does not define a retroactive wrapping mechanism for existing assets.

ACTOR-BY-ACTOR IMPACT ASSESSMENT

Who is Affected by CIP-68?

Creators and Issuers

CIP-68 fundamentally changes how metadata is stored and referenced for both fungible and non-fungible tokens. Projects currently using CIP-25 must plan a migration path.

Key impacts:

Metadata is stored in a separate UTxO using inline datums, not attached directly to the mint transaction.
A single minting policy can now manage a collection with a reference NFT and many user NFTs.
Royalty and attribute data can be updated without burning or re-minting tokens.

Action items:

Audit existing minting policies for compatibility with the (100) reference token and (222) user token structure.
Design a migration strategy for existing CIP-25 collections.
Update off-chain metadata indexing to read datum fields instead of transaction metadata.

Chainscore Labs can perform a minting policy audit and design a migration readiness plan for your collection.

implementation-impact

ADOPTION AND COMPATIBILITY

Implementation Impact and Migration Path

CIP-68 introduces a fundamentally different on-chain architecture for assets. Migration is not automatic, and the standard's benefits require deliberate integration work from builders, wallets, and marketplaces.

Dual-Token UTXO Architecture

CIP-68 uses a single UTXO containing a reference NFT and a user token. This tightly couples asset identity with its metadata, enabling on-chain logic to trust the pairing. Builders must redesign minting pipelines to construct this specific output structure, and wallets must update their UTXO selection and parsing logic to correctly identify and display CIP-68 assets without breaking existing CIP-25 support.

Metadata Standard and Datum Schemas

Metadata is stored as inline datums on the reference NFT output, using a structured 3-field schema (constructor 0). This shifts metadata from off-chain transaction metadata to on-chain data, making it directly accessible to Plutus scripts. Integrators must update their indexers (e.g., DB-Sync, Carp) to parse datum fields rather than transaction metadata, and dApps must refactor their off-chain code to query datum-based metadata for asset display and logic.

Wallet and Explorer Integration

Wallets and explorers must implement a new asset discovery heuristic: scan for reference NFTs with CIP-68 datums, then locate the paired user token within the same UTXO. This is a non-trivial indexing change. Teams should implement feature flags to support both CIP-25 and CIP-68 assets during a transition period, ensuring users do not see duplicate or broken asset representations. A phased rollout with user education is critical.

Marketplace and DeFi Compatibility

Marketplaces must update their listing and bidding contracts to handle CIP-68's dual-token UTXO structure. A sale must transfer both the reference NFT and user token together to preserve the asset's integrity. DeFi protocols accepting NFTs as collateral must verify the on-chain datum metadata to prevent spoofed assets. Teams should audit their smart contracts for assumptions about single-token UTXOs and implement CIP-68-aware validation logic.

Migration Path from CIP-25

There is no automatic migration. Projects must design a user-facing migration mechanism, typically a burn-and-remint process where the old CIP-25 asset is destroyed and a new CIP-68 compliant UTXO is created. This requires careful transaction construction to preserve token ownership history and may involve a snapshot-based airdrop. Teams should plan for a long coexistence period and provide clear tooling to guide users through the migration.

Chainscore Labs Upgrade Readiness Review

Adopting CIP-68 touches minting, indexing, wallet UX, and smart contract security. Chainscore Labs provides a structured readiness review covering your minting policy design, off-chain transaction builder logic, indexer integration, and Plutus script compatibility. We help teams identify breaking changes, plan a safe migration, and avoid common eUTXO pitfalls before mainnet deployment.

CIP-68 ADOPTION IMPACT

Compatibility and Risk Assessment

Evaluates the operational and integration risks for systems adopting or interacting with the CIP-68 Datum Metadata Standard, moving from off-chain metadata (CIP-25) to on-chain datums.

Area	What changes	Who is affected	Action
Asset Identification	Assets are identified by a combination of Policy ID and a fungible/non-fungible token name, not a single asset name. The reference NFT points to metadata, not the user-facing token.	Wallets, explorers, exchanges, marketplaces	Update asset indexing logic to resolve metadata via the reference NFT's datum. Verify asset listing and display pipelines against CIP-68 test vectors.
Metadata Retrieval	Metadata is stored in the datum of a reference UTXO, not in the transaction metadata field. Off-chain indexers must parse CBOR datums.	Blockchain indexers (e.g., Blockfrost, db-sync), NFT marketplaces, data teams	Refactor metadata ingestion to parse inline datums from reference UTXOs. Ensure indexers correctly handle the 500-byte datum limit and multi-asset output structure.
Wallet Integration	Wallets must construct complex multi-asset UTXOs containing a reference NFT and user tokens. Display logic must resolve metadata from the reference NFT's datum.	Wallet providers (light and hardware), dApp front-ends	Implement CIP-68 UTXO construction and parsing. Audit user-facing asset display to ensure it correctly dereferences the metadata datum. Test with hardware wallet memory constraints.
Smart Contract Logic	Plutus scripts must navigate the CIP-68 output structure to validate metadata or enforce royalty logic. The reference NFT is a separate token in the same UTXO.	DeFi protocols, NFT minting platforms, Plutus developers	Review and refactor on-chain validators that inspect asset metadata. Ensure scripts correctly identify the reference NFT and parse its datum without exceeding script budget limits.
CIP-25 Coexistence	Projects may dual-mint with both CIP-25 and CIP-68 metadata, creating ambiguity. Indexers and wallets may display conflicting or duplicate data.	NFT projects, marketplaces, wallets	Establish a resolution strategy for dual-minted assets. Prioritize CIP-68 datum as the source of truth if present. Communicate display logic clearly to users to prevent confusion.
Minting and Migration	Migrating from CIP-25 to CIP-68 requires a new mint transaction to create the reference NFT and re-wrap assets. The original Policy ID remains unchanged.	NFT creators, token issuers, minting services	Design a migration transaction template. Test the migration flow on a testnet to ensure the reference NFT is correctly linked and the user token remains fungible/non-fungible.
Exchange Deposit Detection	Exchanges scanning for incoming native assets may not recognize CIP-68 structured UTXOs as a single logical deposit.	Exchange operations teams, custodians	Update deposit monitoring systems to recognize CIP-68 output patterns. Ensure reconciliation logic groups the reference NFT and user tokens as a single logical asset for crediting.

CIP-68 READINESS

Adoption and Migration Checklist

A practical checklist for builders, wallet teams, and marketplaces planning to adopt CIP-68 or migrate from CIP-25. Each item identifies a critical integration point, explains why it matters, and specifies the signal that confirms readiness.

What to check: Your transaction builder correctly constructs a single UTXO containing the reference NFT (label 100) and the user token (label 222) with their respective inline datums.

Why it matters: CIP-68's core architecture depends on a strict UTXO structure. A malformed output—such as placing the user token in a separate UTXO or using hash datums instead of inline datums—breaks the standard and makes the asset unreadable by compliant indexers and wallets.

Readiness signal: A testnet transaction where a CIP-68 asset is successfully parsed by a block explorer (e.g., Cardanoscan) and a wallet (e.g., Eternl, Typhon) displaying the metadata from the inline datum.

resource-links

CIP-68 REFERENCES

Source Resources and Canonical Links

Canonical sources for teams implementing or reviewing CIP-68 datum metadata support for Cardano fungible and non-fungible tokens. Use these links to verify the current standard, related dependencies, and integration behavior before shipping wallet, marketplace, minting, or indexing changes.

CIP-68 Canonical Specification

Start with the CIP-68 specification in the Cardano Foundation CIPs repository. Engineering teams should use it to confirm the datum structure, reference-token pattern, asset naming expectations, and metadata fields before minting or indexing CIP-68 assets. Because CIPs are standards documents rather than consensus rules, teams should also check the repository history, open issues, and merged pull requests to verify whether implementation details have changed since an earlier integration review.

EXPLORE

CIP-67 Asset Name Label Dependency

CIP-68 relies on labeled asset names to distinguish reference tokens from user-facing token classes. Wallets, explorers, marketplaces, custodians, and DeFi protocols should implement CIP-67 parsing rather than treating every native asset name as an opaque display string. This is especially important for preventing reference tokens from being shown as transferable collectibles or misclassified in balance views, policy filters, royalty logic, or token allowlists.

EXPLORE

CIP-25 Legacy Metadata Reference

Review CIP-25 when planning migrations from legacy NFT metadata to CIP-68. CIP-25 metadata is transaction-metadata based, while CIP-68 moves asset metadata into datum-bearing UTXOs associated with labeled tokens. Marketplaces and indexers should support both formats during transition periods and should define precedence rules for display, update detection, and collection verification instead of assuming CIP-68 automatically replaces existing CIP-25 assets.

EXPLORE

CIP Repository and Standards Lifecycle

Use the main Cardano CIPs repository to verify proposal status, related standards, editor discussions, and changes affecting CIP-68 integrations. Product and risk teams should not treat a single blog post, SDK example, or marketplace implementation as normative. Before committing to production support, pin the reviewed repository revision, record assumptions about status and compatibility, and monitor future CIP changes that could affect token classification or metadata interpretation.

EXPLORE

CIP-30 Wallet Bridge for dApp Integration

dApps that mint, update, list, or interact with CIP-68 assets commonly depend on wallet transaction construction and signing flows exposed through CIP-30-compatible wallets. Teams should verify that wallet integrations preserve datum, reference input, and native asset details correctly before asking users to sign transactions. Wallet providers should also test how CIP-68 assets are displayed to avoid confusing reference tokens, user NFTs, and fungible token balances.

EXPLORE

Cardano Serialization Library Implementation Reference

For transaction construction, datum encoding, native asset handling, and CBOR serialization checks, review the Cardano Serialization Library used by many Cardano wallet and dApp stacks. CIP-68 implementations should test serialization determinism, asset-name byte handling, inline datum construction, and signing behavior across the exact library versions used in production. Chainscore Labs can help teams review these integration paths before enabling user-facing CIP-68 support.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

CIP-68 MIGRATION AND IMPLEMENTATION

Frequently Asked Questions

Common questions from builders, wallet teams, and protocol architects evaluating the transition from CIP-25 to CIP-68 for asset metadata on Cardano.

CIP-68 moves metadata from a transaction's auxiliary data field into the datum of a dedicated UTXO. This creates a single, self-contained output that holds the minting policy, the reference NFT, and the user token. The key architectural shift is that metadata becomes part of the transaction's deterministic data, making it accessible to Plutus scripts and indexers without relying on off-chain transaction metadata that can be pruned or ignored. This enables on-chain logic to read and enforce metadata conditions, which is impossible under CIP-25's design.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

CIP-68: Datum Metadata Standard for Fungible and Non-Fungible Tokens

What is CIP-68?

CIP-68 at a Glance

Technical Architecture: The Single UTXO Model

Who is Affected by CIP-68?

Creators and Issuers