# Mint NFTs (CIP-68) #### What is CIP-68? Cardano Improvement Proposal 68 (CIP-68) is a metadata standard that revolutionized how NFT metadata is managed on Cardano. It enabled **truly updatable metadata after minting** through a dual-token architecture, perfect for dynamic NFTs like game items, evolving collectibles, or interactive art. #### Why CIP-68 Was Created **CIP-25 Limitations:** * Metadata inaccessible to smart contracts (stored in transaction metadata). * Complex and high cost metadata updates requiring mint/burn cycles with double-mint periods. * Metadata resolution requires scanning blockchain history to find the "last minted transaction" for each token. * Permanent immutability once policy is time-locked. **CIP-68 Solution:** A dual-token architecture separating metadata storage from ownership, enabling seamless updates, smart contract integration, and enhanced security through datum-based metadata storage. Unlike CIP-25, metadata updates remain possible even after the minting policy is time-locked, as updates are controlled by the reference token's spending script rather than the minting policy. **CIP-68 Trade-offs:** * Higher initial minting costs (requires creating two tokens instead of one) * Increased complexity managing dual-token architecture, creating additional UTxO overhead for reference token storage. #### How It Works CIP-68 uses an innovative **dual-token system** where each NFT consists of two linked tokens: * **Reference Token (Label 100)**: Stores the updatable metadata at a script address or Admin wallet * **User Token (Label 222)**: Resides in the user's wallet and inherits metadata from the reference token This separation allows metadata updates without affecting user ownership or requiring token transfers. #### Validation Approaches: Native Scripts vs. Smart Contracts CIP-68's updatable metadata is managed by a Reference Token, which can be secured in two ways: 1. **Metadata-Manager Wallet with a Native Script:** This approach uses a standard wallet and a native script to control the Reference Token. It's straightforward and low-cost, making it ideal for projects that don't need complex on-chain logic. The trade-off is that it relies on trusting the wallet owner to manage metadata updates and token supply correctly. 2. **Smart Contract (Plutus/Aiken):** This method uses a full smart contract to govern the Reference Token. While someone still needs to trigger updates, the smart contract validates critical aspects like supply limits and reference token to user token ratios on-chain, requiring less trust than the wallet approach. It enables complex rules for metadata updates, supply caps, and other on-chain logic, but is more complex and expensive to develop and interact with. The choice between them depends on your project's need for trustless validation versus simplicity and cost-effectiveness. If you need custom smart contract development, or are not sure which option to choose, we recommend reaching out at . ### Prerequisites Before you start, make sure you have: * **Anvil API key** – Get one [here](/anvil-api/authentication.md) * **Cardano wallets** – Use our [wallet CLI](/developer-tools/wallet-cli.md) to create them * **Basic understanding** of CIP-68's two token system. See [CIP-68 Standard Reference](/guides/nft-and-ft/mint-nft-cip-68/cip-68-standard.md) ### Choose Your Approach CIP-68 offers two main validation approaches for securing reference tokens: Choose your approach based on your specific needs: | Criteria | Native Scripts | Smart Contracts | | ---------------------------------- | -------------------------------------- | ------------------------------------- | | **Validation Logic Customization** | Simple signature + timelock validation | Complex programmable business rules | | **Metadata Updates** | Manual wallet-based updates | Automated rule-based validation | | **Development Complexity** | Low - JSON configuration | High - Aiken Development | | **Cardano Transaction Costs** | Lower | Higher (\~2x ADA) | | **Use Cases** | Simple collections, personal projects | Gaming, DeFi, enterprise applications | ### All Guides #### Getting Started {% content-ref url="/pages/XUCgyiqYozlRhiFHziFc" %} [Native Script Minting](/guides/nft-and-ft/mint-nft-cip-68/deno-and-fetch.md) {% endcontent-ref %} #### Smart Contract Guides {% content-ref url="" %} {% endcontent-ref %} {% content-ref url="/pages/gTfFEvJFTCraDlihyDEG" %} [Mint Example](/guides/nft-and-ft/mint-nft-cip-68/smart-contract/mint-example.md) {% endcontent-ref %} {% content-ref url="" %} {% endcontent-ref %} ### References & Further Reading #### Official CIP Specifications * [CIP-68: Datum Metadata Standard](https://cips.cardano.org/cip/CIP-68) - The official specification for updatable NFT metadata * [CIP-25: NFT Metadata Standard](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) - Traditional NFT metadata standard * [CIP-86: NFT Metadata Update Oracles](https://cips.cardano.org/cip/CIP-86) - Extension for CIP-25 metadata updates --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://dev.ada-anvil.io/guides/nft-and-ft/mint-nft-cip-68.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.