Programmable Tokens on Cardano: How a Token Learns to Follow Rules

A simple question that was hard to answer

Imagine a bank wants to issue a digital dollar on a public blockchain. The law says the bank must be able to refuse sanctioned buyers, follow anti-money laundering rules, and freeze an account if a court orders it.

On most blockchains, once a token is out in the world, the issuer has little say over where it goes next. So the bank faces an awkward choice: give up the public blockchain, or give up compliance.

Cardano's answer is a standard called CIP-0113, better known as programmable tokens. To understand it, we first need to understand what a token is on Cardano.

First, what is a token on Cardano?

A token is a digital asset that lives on a blockchain, such as a stablecoin (a token designed to hold a steady value, like one US dollar), a share in a fund, or a ticket.

On Cardano, tokens are special in one way. They are called native assets, which means the Cardano ledger itself keeps track of who owns them, the same way it tracks the network's main coin, ADA. Cardano's developer documentation explains that on Ethereum a token is a smart contract, while on Cardano a token is part of the ledger, and once minted it moves in ordinary transactions without running a script [Assets, Cardano developer documentation].

Two terms are worth knowing here:

• Minting means creating new units of a token. Burning means destroying them.

• A minting policy is the rule that decides who is allowed to mint or burn a given token. Every native asset has one, and it can never change [Assets, Cardano developer documentation][Native tokens, Cardano documentation].

This design is simple and cheap, and wallets and explorers handle these tokens the same way they handle ADA. But it has a trade-off that the Cardano Foundation spells out plainly. Once a native asset is minted, it is free to transfer, and the issuer no longer has a way to enforce rules on how it behaves. They cannot limit transfers to verified holders, freeze assets after a legal order, or make sure transactions follow regulations [Programmable Tokens for Cardano].

The gap that programmable tokens fill

Regulated assets come with obligations that do not disappear after issuance. Stablecoins must respect sanctions lists. Tokenized securities (digital versions of things like stocks or bonds) must follow transfer restrictions that depend on jurisdiction and investor status. These duties are usually described with two abbreviations: KYC (know your customer, meaning verifying who someone is) and AML (anti-money laundering, meaning preventing illegal funds from moving through the system) [Programmable Tokens for Cardano][Introduction to Programmable Tokens].

Before CIP-0113, projects could build their own custom solutions on Cardano, but without a shared standard every wallet, explorer and app had to integrate each token one by one. The Foundation says this slowed adoption and held back institutional confidence [Programmable Tokens for Cardano].

The project's own documentation lists the usual workarounds and why each falls short [Introduction to Programmable Tokens]:

• Centralized custodians bring back middlemen and counterparty risk.

• Off-chain enforcement cannot stop an unauthorized transfer at the protocol level.

• Smart contract wrappers break compatibility with standard wallets and infrastructure.

• Separate blockchains split liquidity and interoperability.

What was missing was a way to add rules to a token while keeping it a normal Cardano asset.

What CIP-0113 actually is

A CIP is a Cardano Improvement Proposal, a public document that describes a change or a standard for the ecosystem. CIP-0113 defines programmable tokens: native Cardano assets with an extra layer of validation logic that runs on every transfer, mint or burn [Programmable Tokens for Cardano][Introduction to Programmable Tokens].

In everyday terms, a normal token is like cash. It passes from hand to hand and nobody checks anything. A programmable token is like cash that carries its own rulebook, and a checkpoint reads that rulebook every single time the cash changes hands.

The important detail is that the checkpoint is the network itself. Rules such as "check that the sender is not on a sanctions list" or "only allow transfers between verified accounts" run automatically on-chain [Programmable Tokens for Cardano]. The Cardano Foundation adds that the standard needed no hard fork, meaning the network's core software did not have to change [Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets].

One of the standard's contributors, Phil DiSarro, summed up the idea this way: think of programmable tokens as "a mini ledger within Cardano" [Introduction to Programmable Tokens].

Tokens made under the standard are still native Cardano assets. Once wallets, explorers and apps have added support, they can handle these tokens like any other Cardano asset [Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets].

How it works: four simple pieces

The technical design is detailed, but the main idea fits in four pieces. The descriptions below follow the project's own architecture documentation [Introduction to Programmable Tokens][CIP-113 Programmable Tokens, Aiken implementation].

1. A shared home. All programmable tokens are held at one shared smart contract address. Think of it as a single secure building that every programmable token lives in. Ownership inside the building is tracked by each holder's stake credential, which is the key (or script) that proves who the owner is. So everyone shares the same building, and each person has their own labeled locker [Introduction to Programmable Tokens][CIP-113 Programmable Tokens, Aiken implementation].

2. A directory. The standard includes an on-chain registry, a public directory of registered programmable tokens. Each entry points to the scripts that hold that token's rules. If a token is not in the directory, it is treated as a regular native token [CIP-113 Programmable Tokens, Aiken implementation].

3. Rulebooks. The actual rules live in modules. A module is a set of smart contracts written by the token's issuer that says how the token may be minted, burned and transferred. Different tokens can use different modules. The standard ships with reference modules, such as a simple permissioned transfer and a freeze-and-seize design with a denylist, and anyone can write new ones [Programmable Tokens for Cardano][Introduction to Programmable Tokens][CIP-113 Programmable Tokens, Aiken implementation]. Note that the Foundation's March 2026 article called these "substandards", while the current documentation and the October announcement use the word "modules". They are the same idea.

4. A checkpoint on every move. Whenever a programmable token is spent, the shared custody contract requires the right checks to run first. The standard does this through a technique called the withdraw-zero pattern, where a rule script is triggered by a withdrawal of zero ADA. You do not need to remember the name. What matters is that the rules cannot be skipped, because the transaction fails without them [Introduction to Programmable Tokens].

A walk through a transfer

Say Alice wants to send 100 units of a regulated stablecoin to Bob [Introduction to Programmable Tokens]:

1. Alice builds a transaction that moves her tokens to Bob and signs it with her key.

2. The shared custody contract sees that a programmable token is being spent and calls the transfer checks.

3. The checks look up the token in the registry and run that token's module. For a stablecoin, that might mean confirming neither Alice nor Bob is on a denylist.

4. If everything passes, the tokens land in the same shared building, now under Bob's name. If anything fails, the whole transaction is rejected.

Alice never talks to the issuer, and the issuer never has to approve each payment by hand. The rules do that work on their own.

What issuers can do, and what they cannot

Programmable tokens give issuers real powers, so it is worth being precise about their limits. The project's "Control Scope and Admin Authority" document is the clearest source on this [Control Scope and Admin Authority].

What issuers can do. A module can allow a freeze, which blocks a token from being spent, and a seize, which forces tokens to move, for example after a court order. The Foundation's reference design for a regulated stablecoin includes an on-chain denylist and these issuer controls [Programmable Tokens for Cardano][CIP-113 Programmable Tokens, Aiken implementation].

What the standard limits.

• A freeze is the simple power. A module can always refuse to authorize a transfer. Seizing is the more restricted power, and each module decides who can be seized from [Control Scope and Admin Authority].

• A seizure transaction acts on one token policy at a time. It cannot seize across two different policies in a single transaction [Control Scope and Admin Authority].

• Issuers can mark certain asset-name prefixes as protected. Once declared, protection can only be added to, never removed, and protected tokens such as metadata or royalty tokens cannot be seized or burned by administrators [Control Scope and Admin Authority].

• Control happens at the level of registered token policies. A token is only subject to these rules if its issuer registered it under the standard [CIP-113 Programmable Tokens, Aiken implementation][Control Scope and Admin Authority].

Rules can change, but in the open. The rules attached to a token can be updated by the token's authority, and updates apply to all existing holders on their next spend. The policy ID and the authority itself cannot be changed. Because every update is recorded on-chain, anyone can read the current rules by looking at the token's live registry entry, which is why the documentation tells wallets and apps to read it fresh and never cache it [Introduction to Programmable Tokens][Control Scope and Admin Authority].

What this means for different people

If you hold a programmable token. You get the benefits of a native Cardano asset, but you accept that the issuer's rules apply to it. The project's documentation says plainly that by using CIP-0113 tokens, a holder accepts the authority of the module attached to them [Control Scope and Admin Authority]. The practical advice is simple: before you hold a programmable token, read its rules in the registry.

If you issue one. You can build compliance checks into the token itself and adjust them as regulations evolve, without changing the core standard. The Cardano Foundation also says execution costs stay predictable no matter how many inputs a transaction contains [Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets].

If you build wallets, explorers or apps. Because tokens sit at a shared address and ownership is tracked by stake credentials, the documentation notes that wallets need to resolve that ownership to show balances, explorers need to attribute tokens to holders instead of the shared address, and decentralized exchange contracts need to work with the rule scripts [Introduction to Programmable Tokens][CIP-113 Programmable Tokens, Aiken implementation]. The Foundation's integration guide covers this, and the standard launched with support from Eternl, GeroWallet, CardanoScan and BloxBean [Programmable Tokens for Cardano][Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets].

Where things stand today

The story has moved quickly, so here is the timeline as published by the Cardano Foundation and the project repository:

• Origins. CIP-0113 builds on an earlier specification, CIP-0143, developed by Philip DiSarro and Jann Müller at IOG. Before them, Michele Nuzzi of Harmonic Labs explored early programmable token implementations, and Matteo Coppola Mazzetti of FluidTokens is an active collaborator. The Foundation migrated the work to Aiken, a programming language for Cardano smart contracts, to make it accessible to more developers [Programmable Tokens for Cardano][CIP-113 Programmable Tokens, Aiken implementation][CIP-0143: Interoperable Programmable Tokens].

• 9 March 2026. The Foundation released the Programmable Tokens Platform: an open-source implementation, reference integrations, and a live preview environment on Cardano's Preview testnet, where anyone can issue and transfer test tokens with no real funds [Programmable Tokens for Cardano][Programmable tokens live preview environment].

• 7 October 2026. At TOKEN2049, the Foundation announced that CIP-0113 is live on Cardano mainnet, after multiple independent security audits and without a hard fork. On the same day, the Swiss Capital Markets and Technology Association (CMTA) announced it recognizes CIP-113 programmable asset tokens as a smart contract equivalent to its CMTAT framework, for the purpose of its certification scheme [Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets].

The Foundation says it will keep working with projects building on the standard, including further development of a securities module for regulated financial instruments [Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets].

A note on caution

If you plan to use programmable tokens with real assets, do your own checking. The Foundation's announcement links to the independent security audits [Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets]. At the time of writing, the project repository's main page still carried an older disclaimer saying the final audit report was pending and that the code should not yet be treated as production-ready [CIP-113 Programmable Tokens, Aiken implementation]. Announcements and repository notes can fall out of step with each other, so read the audit reports and the repository's current status yourself before relying on any of this.

An audit also does not by itself guarantee safety. The project's own documentation says so [Introduction to Programmable Tokens].

Terms in plain words

• Token: a digital asset recorded on a blockchain.

• Native asset: a token tracked directly by the Cardano ledger, with no smart contract needed for basic transfers.

• Smart contract: a program that runs on the blockchain and enforces rules automatically.

• Issuer: the organization that creates a token and defines its rules.

• Registry: the on-chain directory of programmable tokens and where to find their rules.

• Module: a pluggable set of smart contracts holding the rules of a specific token.

• Freeze and seize: blocking a token from moving, and forcing tokens to move, under rules the issuer has built in.

• Mainnet: the live Cardano network. A testnet is a practice network where tokens have no real value.

Final thought

Programmable tokens do not make Cardano permissioned, and they do not change what an ordinary native token is. They add an optional layer that an issuer can choose, for assets that the law says must follow rules. The design question this standard answers is a practical one: can a regulated asset live on a public blockchain without leaving the ecosystem around it? On Cardano, the answer now has a standard, an open-source implementation, and a mainnet launch to look at.

Sources

1. Assets, Cardano developer documentation: how native tokens work and how they differ from smart contract tokens

2. Native tokens, Cardano documentation: minting policies and the native token ledger feature

3. Programmable Tokens for Cardano, Giovanni Gargiulo, Cardano Foundation, 9 March 2026

4. Introduction to Programmable Tokens, project documentation, Cardano Foundation

5. Cardano Foundation launches programmable token standard, bringing ledger-enforced compliance to tokenized assets, Cardano Foundation press release, 7 October 2026

6. CIP-113 Programmable Tokens, Aiken implementation, project repository README, Cardano Foundation

7. Control Scope and Admin Authority, project documentation, Cardano Foundation

8. CIP-0143: Interoperable Programmable Tokens, the earlier specification CIP-0113 builds on

9. Programmable tokens live preview environment, connected to the Cardano Preview testnet

To follow the standard's formal status, see the CIP-113 proposal. Standards, parameters and audit status can change, so check the sources above for current details.