Cardano Native Token Tutorial Advanced: Multi-Sig, Time-Locks, and CIP-68 Mastery

Key Takeaways

• Cardano native tokens are tracked directly by the ledger — no smart contract required — making them faster and cheaper to manage than ERC-20 tokens on Ethereum.
• Advanced minting policies use native JSON scripts for multi-signature control and time-locks — no Plutus code needed for most real-world use cases.
• A Policy ID is a permanent, cryptographic hash of your script. Once generated, the link between a token and its policy can never be changed.
• CIP-68 replaces CIP-25 for metadata by storing token data in on-chain datums, enabling dynamic updates without a burn-and-remint cycle.
• Multi-asset transactions let you mint, transfer, and burn multiple token types in a single transaction — a key efficiency advantage on Cardano.
• Hardware wallet integration via cardano-hw-cli lets teams require a physical device signature before any tokens are minted.

Advanced Cardano native token management means moving beyond a single-key minting setup and into the full power of the multi-asset ledger. At this level, you control who can mint, when they can mint, how many times minting is allowed, and how token metadata evolves over time — all without deploying a Plutus smart contract.¹

Why the Cardano Native Token Tutorial Advanced Path Skips Smart Contracts

If you came from Ethereum, your first instinct is to reach for a smart contract when you need token logic. Cardano works differently. The ledger itself handles token accounting as a native feature — the same way it tracks ADA.² Every native asset on Cardano is identified by a policyId.assetName pair. The policyId is the SHA-256 hash of your minting script, and the assetName is arbitrary bytes — often the token’s ticker encoded in hex.

This matters for developers, because the security guarantees for basic token transfers come from the protocol, not from your contract code. There are no Solidity bugs to audit for standard transfers. There are no gas spikes from complex ERC-20 logic. The minting policy defines who is allowed to mint or burn, and the ledger enforces it — period.³

Where this tutorial picks up from the beginner lesson is the policy layer itself. Single-key policies are fine for testing. Production tokens — launch tokens, NFT collections, governance tokens, stablecoins — need policies that reflect real operational security: multiple signers, time-based restrictions, or one-time locks that make future minting mathematically impossible.

For context, other Layer 1 blockchains take very different approaches to token issuance at the protocol level. Modular chains like Celestia, for example, separate consensus from execution entirely, meaning token logic lives in rollup layers rather than the base chain.ⁱ Cardano’s approach keeps token rules closer to the base ledger, which simplifies the security model for developers who want predictable, low-cost minting without deploying execution environments.

Advanced Minting Policies: Native Scripts Without Plutus

A minting policy on Cardano is a set of rules that governs who can create or destroy tokens and under what conditions.⁴ Native scripts express these rules as JSON. They are hashed to create the policy ID. When a transaction tries to mint tokens under a given policy, the node checks that the transaction satisfies those rules — right then, at submission time.

Multi-Signature Minting Policies

A multi-sig policy requires more than one key to sign before any minting is valid. This is the go-to setup for teams, DAOs, or any scenario where a single compromised key should not be enough to print new tokens. You define the policy using the type: "all" structure for an M-of-N requirement, or type: "any" if one key out of several is sufficient.⁵

Here is a two-of-two multi-sig policy script in JSON format:

{
  "type": "all",
  "scripts": [
    {
      "type": "sig",
      "keyHash": "KEYHASH_OF_FIRST_SIGNER"
    },
    {
      "type": "sig",
      "keyHash": "KEYHASH_OF_SECOND_SIGNER"
    }
  ]
}

Both key hashes must sign the transaction for it to pass. You generate the policy ID the same way as a single-key policy:

cardano-cli transaction policyid --script-file policy.script > policy/policyID

When you build the transaction, you reference this script file with --minting-script-file policy.script and provide witness files for each required signer. The node counts the witnesses and rejects the transaction if any required signature is missing. Multi-sig is the most practical way to protect a production token supply from a single point of key compromise.

Time-Locked Minting Policies

A time-lock binds minting permission to a window of blockchain slots. Cardano slots are roughly one second each, so you can calculate a target slot number and use it to set a hard deadline on when tokens can ever be created.³ There are two time-lock types:

• Before (mustMintBefore): Minting is only valid in transactions submitted before a certain slot. Used for NFT collections where the supply must be fully locked by a public date.
• After (mustMintAfter): Minting is only valid after a certain slot. Used for token launches with a vesting or embargo period.

A time-locked, multi-sig combination looks like this:

{
  "type": "all",
  "scripts": [
    {
      "type": "sig",
      "keyHash": "YOUR_KEY_HASH"
    },
    {
      "type": "before",
      "slot": 99999999
    }
  ]
}

Once the chain passes that slot number, no transaction — regardless of who signs it — can mint tokens under this policy. The lock is enforced by the protocol, not by your promises. This is a powerful guarantee for NFT buyers and token investors: they can verify the policy ID on-chain and confirm the supply is mathematically capped.

One-Time Minting Policies

The strictest form of a minting policy is one that locks forever after a single use. You achieve this by combining your key signature with a before slot set to a time in the very near future — essentially minting in one transaction, then letting the time-lock expire naturally.⁴ Once the slot passes, the policy is permanently closed. No more tokens can ever be minted under that policy ID, regardless of who holds the keys. This design pattern is standard for limited-edition NFT drops where immutable supply is part of the value proposition.

Quick Reference: Which Advanced Policy Should You Use?

The Cardano CLI Advanced Workflow: Multi-Asset Transactions

Once you move past single-key minting, the CLI transaction build process involves a few extra steps. The good news is that the logic is consistent — you are always working with the same three-phase cycle of building, signing, and submitting. What changes is the complexity of the value expressions and the number of witness files.

Building a Multi-Asset Transaction with the CLI

The cardano-cli conway transaction build-raw command is your workhorse for advanced minting.¹ The key flags are --tx-out, which specifies where tokens go (as address + lovelace + multi-asset bundle), and --mint, which specifies what is being created or destroyed. Every UTXO output on Cardano must carry a minimum ADA amount — typically around 1.5 ADA — to prevent ledger spam. Plan for this in your transaction math.³

A multi-asset mint value expression in the CLI looks like this:

--mint "1000 $POLICYID.TokenA + 500 $POLICYID.TokenB"

That single --mint flag handles two separate token types in one transaction. The matching --tx-out must include the same bundle in the output value. Cardano’s multi-asset accounting means you can bundle completely different tokens — even under different policies — in the same transaction output.

Minting and Burning in a Single Transaction

One of the more powerful and underused features of the Cardano multi-asset ledger is the ability to mint and burn in the same transaction.² You express a burn using a negative quantity in the --mint field:

--mint "500 $POLICYID.TokenA + -100 $POLICYID.TokenB"

This mints 500 of TokenA and burns 100 of TokenB atomically. Both operations are governed by the same policy validation check. The UTXOs being spent must contain the tokens to be burned, and the policy script must validate for the entire transaction to pass. This pattern is essential for token lifecycle management — for example, redeeming loyalty tokens for rewards while issuing new ones in a single settlement transaction.

Hardware Wallet Co-Signing for Production Minting

For production tokens, requiring a hardware wallet signature adds a physical security layer that pure software key management cannot match. The cardano-hw-cli tool lets you generate a minting verification key derived from a hardware wallet using path 1855H/1815H/0H.⁵ You include that key’s hash in your multi-sig policy script alongside a software CLI key. To sign the transaction, the hardware wallet must be physically connected and the signer must approve on the device screen. This means an attacker who steals your server’s signing key still cannot mint tokens — they also need your physical hardware wallet.

CIP-25 vs. CIP-68: Choosing the Right Metadata Standard

Token metadata is what turns a raw on-chain asset into something wallets, marketplaces, and users can actually read and display. Cardano has two active community standards for this, and your choice has real long-term consequences for how your token can evolve.⁶

CIP-25 attaches metadata to the minting transaction under label 721. Once that transaction is confirmed, the metadata is frozen in blockchain history. If you need to update anything — a broken image link, a new attribute, a corrected name — you must burn the existing token and re-mint it with new metadata attached to the new minting transaction. For large collections, this is expensive and disruptive.

CIP-68 solves this with a dual-token architecture.⁷ Instead of embedding metadata in the minting transaction, it stores metadata in an on-chain datum attached to a separate Reference Token (labeled 100). The token that lives in a user’s wallet is the User Token (labeled 222). To update the metadata, you spend and recreate the Reference Token’s UTXO with a new datum — the user’s token never moves. Wallets and dApps read the metadata by looking up the Reference Token’s UTXO, not by scanning transaction history.

For most new projects launching in 2025, CIP-68 is the forward-looking choice. The ability to update metadata on-chain without touching the user’s token opens up use cases like gaming items whose stats change, real-world asset tokens with updated valuations, and credential NFTs with revocation mechanics.⁸ The tradeoff is higher per-asset cost (roughly double the ADA locked compared to CIP-25) and slightly more complex tooling setup. If your token is static and simple, CIP-25 still works fine.

Real-World Applications of the Advanced Cardano Native Token Tutorial

These policy patterns are not just academic. They map directly to real token launch scenarios that developers face.

A project that launched a limited NFT collection of 10,000 items used a time-locked, single-signature policy — setting the lock slot to approximately 48 hours after the mint began. Once that window closed, the policy ID was verifiably frozen. Holders could check the explorer and confirm no additional tokens could ever be issued under that policy ID. This on-chain verifiability is a meaningful trust signal that off-chain promises simply cannot replicate.

A DAO treasury token used a 2-of-3 multi-sig policy where three founding members each held one key. Any new token issuance required two of the three to co-sign, preventing a single founder from unilaterally inflating the supply. When one founder left the project, the team executed a coordinated burn of all existing tokens and re-minted under a new 2-of-3 policy with updated signers — a clean governance transition handled entirely through the native token mechanics, with no smart contract migration required.

Cardano’s multi-asset ledger lets you mint, transfer, and burn multiple token types atomically in a single transaction — a design advantage that directly reduces operational costs and settlement complexity for advanced token systems.

Conclusion

The advanced Cardano native token tutorial path is about taking ownership of the policy layer. You now have the building blocks: multi-signature policies for team security, time-locks for credible supply caps, one-time minting for immutable token creation, multi-asset transaction bundling for operational efficiency, and CIP-68 for metadata that can evolve with your project. Each of these tools is available without Plutus smart contracts, which means lower complexity, lower fees, and fewer attack surfaces than comparable setups on account-based chains. The next step is to practice these patterns on the Cardano pre-production testnet — where test ADA is free and mistakes cost nothing. Build your policy scripts, test your CLI workflow end-to-end, and confirm your policy ID behavior before you touch mainnet. Start with one advanced pattern at a time, and the rest will follow naturally.

Cardano native token tutorial advanced FAQs

What is the difference between a native script policy and a Plutus policy on Cardano?

A native script policy is a JSON-defined set of signature and time conditions checked by the ledger — no code execution required, making it fast and low-cost. A Plutus policy runs compiled Haskell code during transaction validation and can enforce arbitrary logic, but it adds execution complexity and higher transaction fees. For most advanced token use cases, native scripts handle the job without Plutus.

How do I follow a Cardano native token tutorial advanced enough to cover multi-sig without a hardware wallet?

Following a Cardano native token tutorial advanced enough for multi-sig without hardware is fully possible using two sets of cardano-cli-generated keys — one per signer. You define the policy script with both key hashes under type: "all", then provide two signing key files when submitting the transaction. Hardware wallets add physical security but are not required for the multi-sig mechanics to function.

Can I update Cardano native token metadata after minting?

Under CIP-25, metadata is embedded in the minting transaction and cannot be changed — you would need to burn and remint. Under CIP-68, metadata lives in a Reference Token datum and can be updated by spending and recreating that UTXO, so the user’s token never moves and no reminting is needed.

What happens to my Cardano native token if the policy key is lost?

Losing the policy key means you can no longer mint or burn tokens under that policy — but existing tokens are unaffected and remain fully usable by holders. The tokens live in wallets tracked by the ledger, independent of whether the policy keys still exist. This is actually a desirable outcome for one-time minting policies where key loss proves no future supply can be created.

What is the minimum ADA required when minting advanced Cardano native tokens?

Every UTXO output on Cardano that carries tokens must also include a minimum ADA amount calculated by the protocol based on output size — typically around 1.5 ADA per output for standard token bundles. This minimum ADA is not a fee and is not burned; it stays locked in the UTXO and returns to the sender when the tokens are eventually spent or burned.

Cardano native token tutorial advanced Citations

1. Cardano Developer Portal — Minting Native Assets
2. Cardano Docs — Getting Started with Native Tokens
3. Cardano Developer Portal — Native Assets & Tokens
4. Cardano Docs — Native Tokens Overview
5. Vacuumlabs — cardano-hw-cli Token Minting Guide
6. CIP-68 — Datum Metadata Standard (Official Specification)
7. Cardano Developer Portal — CIP-68 Token Registry
8. OneKey — CIP-68: Cardano’s Approach to Native Asset Design
9. Cardano Developer Portal — Minting NFTs
10. Anvil Development Agency — Mint NFTs (CIP-68)
11. ChiaTribe — Celestia TIA Token and the Modular Blockchain Revolution