# 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.