NFT & FT

Introduction

Cardano supports native tokens—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.

• 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:

{
  "version": "cip-25",
  "assetName": "my_collection_nft_01",
  "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

{
  "changeAddress": "SEE THE GUIDE FOR DETAILS; Can be the customer wallet address. Be careful if otherwise."
  "message": "Asset minted with anvil api",
  "mint": [
    {
      "version": "cip-25",
      "assetName": "anvil_api_cip_25",
      "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": "SEE THE GUIDE FOR DETAILS",
      "quantity": 1,
      "destAddress": "Useful when the change address is NOT the destination OR having multiple destinations."
    }
  ],
  "preloadedScripts": [
    {
      "type": "simple",
      "script": {
       	"type": "all",
       	"scripts": [
        		{
         			"type": "sig",
         			"keyHash": "SEE THE GUIDE FOR DETAILS",
        		},
        		{
         			"type": "before",
         			"slot": "SEE THE GUIDE FOR DETAILS",
        		},
       	],
      },
      "hash": "SEE THE GUIDE FOR DETAILS",
    }
  ],

}

// TODO: ADD CIP-68 Payload

---

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 in ASCII (or hex).

  • metadata: CIP-25 fields like name, image, mediaType, description.

  • policyId: The unique 56-hex string for your minting policy 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 “simple” 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 policy 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.