CIP-68: Cardano’s approach to native asset design

LeeMaimai

/Oct 16, 2025

Key Takeaways

• Cardano's native assets are treated as first-class citizens, improving efficiency and security.

• CIP-68 enables on-chain metadata that is upgradeable and easily accessible without consuming the asset.

• The three-token pattern allows for better organization and management of assets and their metadata.

• Vasil-era features enhance the practicality and cost-effectiveness of on-chain metadata.

• Users benefit from deterministic metadata and lower friction in asset upgrades.

Cardano treats native assets as first-class citizens at the ledger level, avoiding ERC‑20/721-style contract wrappers and inheriting the same security and fee model as ada. That design choice makes asset issuance efficient but also raises practical questions about metadata, mutability, royalties, and composability. Cardano Improvement Proposal CIP‑68 introduces a robust pattern for “smart assets”: upgradeable, on-chain metadata for NFTs and fungible tokens that can be read and validated without spending the asset itself.

This article explains why CIP‑68 matters, how it works, and what it unlocks for builders and users across the Cardano ecosystem.

Why Cardano native assets are different

Unlike account-based chains, Cardano’s extended UTXO (EUTXO) ledger lets you mint and transfer multiple assets in the same UTXO, tracked by minting policies instead of token-specific contracts. This provides predictable fees and parallelizability while keeping asset accounting simple at the ledger layer. For background, see the Cardano documentation on native tokens and how the EUTXO model enables scriptable transactions with deterministic behavior:

Native assets overview (Cardano Docs) — linked at the end of this paragraph
Extended UTXO research and developer materials — linked at the end of this paragraph

Reference: read the official docs on native tokens in Cardano and the EUTXO model at the Cardano developer portal and associated research blogs. Visit the official documentation via Native assets and EUTXO model to learn more.

The problem with legacy metadata (CIP‑25)

Early Cardano NFTs relied on off-chain indexers and transaction metadata via CIP‑25. While simple, this approach:

Relied on third-party indexers for correctness
Made upgrades awkward or impossible
Could not easily enforce on-chain royalty logic or stateful behavior

As the ecosystem matured, builders needed a standard that keeps metadata and state on-chain, versioned, and reliably discoverable without sacrificing user experience.

You can find the original NFT metadata approach in CIP‑25 for historical context (reference at the end of this sentence). See the specification in CIP‑25.

Enter CIP‑68: on-chain, upgradable “smart assets”

CIP‑68 defines a pattern to store metadata and state inside UTXO datums while maintaining a clean, user-facing token. It formalizes a relationship among multiple tokens minted under the same policy to separate concerns:

A user-facing asset that people hold and trade
A reference asset whose UTXO carries the canonical, versioned metadata in an inline datum
An optional state/thread token to manage mutability or state transitions

Crucially, wallets and dApps can read the metadata from the reference asset without consuming it, and updates are performed by spending and recreating the reference UTXO with a new datum. This gives projects “smart NFT” behavior without relying on off-chain databases. Read the standard at CIP‑68.

Why Vasil-era features matter: reference inputs, inline datums, and reference scripts

CIP‑68 leverages three Vasil-era improvements that made on-chain metadata practical and cost-efficient:

CIP‑31 Reference inputs: read data from a UTXO in a transaction without spending it, ideal for consulting a reference NFT’s metadata UTXO. See CIP‑31.
CIP‑32 Inline datums: store the datum directly in the UTXO, enabling canonical on-chain metadata without external lookup. See CIP‑32.
CIP‑33 Reference scripts: attach scripts to UTXOs and reference them for validation, reducing transaction size and costs when interacting with the same script repeatedly. See CIP‑33.

These features together enable low-cost, composable read-access to metadata and state while avoiding unnecessary UTXO churn.

The three-token pattern in practice

While implementations vary, a typical CIP‑68 deployment looks like this:

User token (the tradable asset): what users see in their wallet and marketplaces.
Reference token (non-tradable or protocol-held): anchors the canonical metadata in an inline datum; indexers and dApps read from this UTXO via reference inputs.
State thread token (optional): governs updates, enforces uniqueness, or carries programmatic state for use cases like dynamic art, credentials, positions, or in-game items.

CIP‑68 also encourages schema versioning for datums so that metadata can evolve without breaking consumers. The result is a versioned, on-chain source of truth that any dApp can query consistently.

You can explore the formal specification and recommended schemas at CIP‑68.

What builders get

Composability: dApps can trust a single on-chain metadata source and consume it without spending the asset, enabling seamless integrations in marketplaces, DeFi protocols, and games.
Upgradability with transparency: on-chain datums are auditable; projects can publish change policies, timelocks, or multisig requirements around updates.
Better indexing: indexers no longer need to reconcile off-chain metadata with user-facing assets; they can follow the policy-defined relationship and datum schema.
Royalties and policy rules: while royalties are not enforced at the ledger level, CIP‑68 pairs well with policy logic and marketplace conventions for honoring creator intent. For royalty conventions, see CIP‑27.

Reference the royalty convention in CIP‑27.

What users get

Deterministic metadata: wallets can show the same data that dApps and explorers read from the reference UTXO.
Lower friction: upgrades to artwork, attributes, or state no longer require awkward re-mints or off-chain coordination.
Clearer trust model: projects can disclose whether metadata is mutable, who can update it, and under what conditions.

As always, verify policy IDs and inspect metadata from reputable explorers before interacting with unfamiliar assets. You can verify policies and transactions using Cardano explorers such as Cardanoscan.

Practical use cases

Dynamic NFTs: evolving artwork, season passes, or game items whose attributes change over time.
Credentials and SBT-style artifacts: badges with revocation or update mechanics powered by a state token.
DeFi positions: LP shares or vault receipts that carry position state in the datum while the user token remains tradable where appropriate.
Real-world assets: provenance and attestations stored on-chain in a versioned, auditable way.

Developer tips and best practices

Adopt clear, versioned datum schemas and document them publicly so wallets and indexers can integrate quickly.
Signal mutability: if metadata can change, make that explicit and explain governance (e.g., multisig signers, timelocks, or DAO approvals).
Use reference scripts and reference inputs to minimize fees and UTXO churn.
Avoid unnecessary state complexity; keep the user token UX simple and fast to transfer.
Consider combining CIP‑68 with time locks or policy locking once the collection’s rules are finalized.

For the underlying features that make this pattern efficient, see CIP‑31, CIP‑32, and CIP‑33.

2025 outlook

As Cardano continues evolving into the Conway era with on-chain governance foundations like CIP‑1694, standards that improve asset expressiveness and composability will only grow in importance for dApps and partner ecosystems. Governance and protocol upgrades can strengthen assurances around mutability, provenance, and long-lived metadata for tokenized real-world use cases. For governance background, read CIP‑1694.

Security and wallet considerations

CIP‑68 assets rely on reference UTXOs and inline datums. When signing transactions:

Review the transaction’s minting policies and any scripts being referenced.
Prefer wallets that display policy IDs, datums, and clear asset metadata sourced on-chain.
Store long-term holdings in cold storage and use hardware signing to reduce key exposure.

If you operate a multi-chain portfolio that includes Cardano native tokens, an open-source hardware wallet like OneKey can serve as the offline signing anchor in your stack. OneKey focuses on transparent, audit-friendly firmware and secure offline flows, helping you keep private keys off internet-connected devices while interacting with dApps through compatible software wallets.