# Native Assets (NFTs/FTs) ## Introduction Cardano supports native assets—both Fungible Tokens (FTs) (like a custom currency) and Non-Fungible Tokens (NFTs) (unique collectibles). Anvil provides straightforward ways to mint, send, or burn these assets, whether they follow CIP-25 (the classic NFT metadata standard) or CIP-68 (a more advanced approach allowing evolving or updatable data). ## In this section * We’ll show how CIP-25 metadata might be integrated in a transaction payload. * We’ll highlight how you can combine CIP-68 references similarly (should you want dynamic or updatable NFTs). * We’ll note how to incorporate these tokens into your transaction using mint or outputs. ## NFTs vs. FTs: Dollar Bills vs. Art ### Fungible Tokens (FT) **Analogy:** Think of them like dollar bills—each bill has the same value and is interchangeable with any other. **1 FT = 1 FT, regardless of its “serial number.”** **Use Cases:** * In-Game Currencies: A consistent token players can trade. * Community Tokens: Reward points or governance tokens. * Stablecoins: Pegged to fiat currency. ### Non-Fungible Tokens (NFT) **Analogy:** Think of them like a one-of-a-kind painting—unique art with no duplicates. **1 NFT cannot simply be swapped for another NFT of the same “collection” because each is different.** **Use Cases:** * Digital Art & Collectibles: Rare items or artwork minted under a policy. * Event Tickets: Each ticket is unique, can’t be replaced by another. * Real-World Asset Tokens: Tokenizing property deeds, certificates, or identity credentials. *** ## Policy IDs: The Artist’s Collection Tokens on Cardano—whether NFT or FT—are grouped under a **Policy ID**. * **Policy ID** = A unique hash generated from a minting script or policy. See [Native Scripts](https://github.com/Cardano-Forge/anvil-api/blob/main/docs/guides/native-scripts/README.md). * **Collection**: If an artist mints multiple NFTs under the same policy ID, they effectively form a “series” or “collection.” * **Locking**: The policy can be time-locked or multi-signature locked, controlling whether more tokens can be minted in the future. **In our analogy:** Policy ID = The “brand” or “collection” label that says “all these paintings or bills come from the same source.” *** ## CIP-25 / CIP-68 Metadata (for NFTs) When you mint an NFT, you usually include metadata that describes the token’s name, image, description, attributes, etc. The most common metadata standards: * **CIP-25 (Label 721):** Legacy standard for NFT metadata, widely supported by wallets and marketplaces. * **CIP-68:** Newer approach that places more data in the on-chain datum, allowing dynamic NFTs or advanced features. Many still store a CIP-25–style JSON under label 721 for backward compatibility. ### Example: ```json { "version": "cip-25", "assetName": {"name": "my_collection_nft_01", "format": "utf8"}, "metadata": { "name": "My Collection NFT #1", "image": "ipfs://QmExampleHash", "mediaType": "image/png", "description": "Unique artwork minted with the Anvil API", "quantity": 1 } } ``` Depending on your approach, you embed this in your transaction’s metadata—Anvil can help you structure that under label 721. *** ## CIP-25 Payload **Minting** ```json { // Address to pay for the TX and receive any leftover ADA from the transaction. "changeAddress": "addr_test1...", // UTXOs from the wallet paying for fees (list of CBOR UTXOs) "utxos": ["8282...", "8282..."], // Message to include in the transaction "message": "Asset minted with anvil api", // Array of assets to mint "mint": [ { "version": "cip-25", "assetName": {"name": "anvil_api_cip_25", "format": "utf8"}, "metadata": { "name": "anvil_api_cip_25 #1", "image": [ "https://ada-anvil.s3.ca-central-1.amazonaws.com/", "logo_pres_V2_3.png" ], "mediaType": "image/png", "description": "Testing CIP-25 using anvil API", }, "policyId": "4d5bd6249f0d9e4b2762ce334e2973dc7fd414ec1e08b4b0c2159bfb", "quantity": 1, // Destination to send minted asset. "destAddress": "addr_test1..." } ], // Optional but recommended for performance and latency. Required for new/unregistered scripts. "preloadedScripts": [ { "type": "simple", "script": { "type": "all", "scripts": [ { // Defines the policy wallet that will sign the transaction "type": "sig", "keyHash": "fdf151b600df2492005221876c7d7e33056496572c7363c33a1e3609", }, { // Defines the slot number that this policy can mint/burn tokens "type": "before", "slot": "100000000", }, ], }, // The hash of the native script, which is the Policy ID. "hash": "4d5bd6249f0d9e4b2762ce334e2973dc7fd414ec1e08b4b0c2159bfb", } ], } ``` ## CIP-68 Payload ```json { // Address receive any leftover UTxOs from the transaction. Usually the "changeAddress": "addr_test1...", // UTXOs from the wallet paying for fees (list of CBOR UTXOs) "utxos": ["8282...", "8282..."], "mint": [ { // Reference Token - Label 100 -> Sent to Metadata Manager Wallet or Script Address "version": "cip68", //Name of the asset. Must be the same for both tokens "assetName": { "name": "youruniquecip68asset", "format": "utf8", "label": 100 }, "metadata": { "name": "Your NFT Name", "image": "ipfs://your-image-hash", "mediaType": "image/png", "description": "A description for your CIP-68 asset" }, "policyId": "8e024681ee83f54bd5f9a0334641...", "quantity": 1, // Destination to send minted asset. "destAddress": "addr_test2..." }, { // User Token - Label 222 -> Sent to User Wallet "version": "cip68", // Asset name must be identical to the (100) token's assetName "assetName": { "name": "youruniquecip68asset", "format": "utf8", "label": 222 }, "policyId": "8e024681ee83f54bd5f9a033464...", "quantity": 1, // Destination to send minted asset. "destAddress": "addr_test1..." } ], // The `preloadedScripts` array provides script data for minting authorization. // - Native scripts: contains the actual native script // - Plutus scripts: contains blueprint data (native script derived from blueprint) // Optional but recommended for performance and latency. Required for new/unregistered scripts. "preloadedScripts": [ /* ... script details ... */ ], // The `scriptInteractions` array is ONLY required for smart contract validation. // It is not used for the native script / Metadata-Manager Wallet approach. // It is ONLY required for blueprints that are not registered yet. // The full payload format is covered in the smart contract guide. "scriptInteractions": [ /* ... validator, redeemer, datum ... */ ], } ``` *** ## Explanation * **changeAddress:** Where leftover funds or minted assets return if they’re not explicitly assigned. * **message:** This sets CIP-20–style text if you want a short on-chain memo. * **mint array:** * **version:** "cip-25" tells Anvil you’re embedding CIP-25–compliant metadata. * **assetName:** The token’s name as a JSON object * **name:** The name of the asset. * **format:** The format of the name. Can be "utf8" or "hex". * **Example:** {name: "MyAssetName", format: "utf8"} * **metadata:** CIP-25 fields like name, image, mediaType, description. * **policyId:** The unique 56-hex string for your minting native script. * **quantity:** How many tokens to mint (1 for a single NFT). * **destAddress:** If you want the minted asset to go to a specific address different from your changeAddress. * **preloadedScripts:** Example of a native script using `type": "all"` (ScriptAll). Includes a signature requirement and time-lock. *** ## Minting vs. Sending * **Mint:** Use the `mint` array. If you want to send additional tokens after minting, include them in the `outputs[]`. * **Transferring an existing token:** Just specify it under `outputs[].assets[]`. No need to define `mint`. *** ## Key Steps to Use 1. Assemble the payload: `changeAddress` or `utxos` + the `mint` array if creating tokens. 2. Optionally add `CIP-20` or `CIP-25` metadata under `metadata` or `message`. 3. Call `POST /transactions/build`. 4. Sign the resulting transaction with your policy key and/or user’s key. 5. Submit the signed transaction to `POST /transactions/submit`. *** ## Conclusion NFT & FT usage on Cardano with Anvil revolves around two primary tasks: * **Minting tokens** by specifying them in the `mint` array (plus a reference native script if needed). * **Transferring tokens** by listing them in `outputs[].assets[]`. For CIP-25 or CIP-68 metadata, you embed JSON describing your asset (NFT name, image, etc.) so wallets and explorers can parse it. The snippet above with preloadedScripts and policyId is a typical CIP-25 single NFT example. Whether you’re distributing a fungible currency or a one-of-a-kind collectible, the approach is the same—CIP standards define the metadata, and Anvil’s transaction builder handles the heavy lifting. --- # 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.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.