As of this writing, CIP-143 and CIP-113 have been merged, and CIP-113’s merger is not yet final. The following document is based on the assumption that CIP-143’s content will be integrated into CIP-113 without significant changes.

Cardano's native token model (eUTxO) provides security and robustness, but lacks built-in account-based functionalities commonly found in Ethereum’s ERC-20 standard. This gap is particularly noticeable in use cases that require token programmability, such as regulated assets that necessitate administrative controls (e.g., freezing, conditional transfers). The CIP-143 standard (“Interoperable Programmable Tokens”) was proposed to bridge this gap by introducing interoperable programmable tokens, enabling controlled transfers and advanced token functionalities while maintaining compatibility with the existing UTxO model. Now, CIP-143 and CIP-113 (“Programmable token-like assets”) have been merged to create a unified standard, with CIP-143 addressing the questions and limitations left by the initial CIP-113 draft.

As CIP-113 advances toward finalization, CertiK is closely tracking its progress—a milestone that could reshape how developers build and enterprises engage with Cardano. This article explores the specification in depth, covering its background, the problems it addresses, its implementation, its impact on the Cardano ecosystem, comparisons with ERC-20, and security considerations.

Background

Unlike Ethereum’s ERC-20 standard, Cardano's native token model lacks an easy method to implement "account-like" token behavior. In Ethereum, tokens are managed by smart contracts in an account-based model, enabling features like freezing, conditional transfers, and other complex logic. In its early stages, CIP-113 existed as a draft proposal to bring ERC-20 style tokens to Cardano. At that time (early 2023), Cardano’s native tokens were simple UTxO-based assets and controlled by minting policies, which made global token controls, such as freezing a malicious actor’s funds, challenging without a standardized approach. The initial goal of CIP-113 was to emulate account-based token behavior on Cardano, but it left open questions about wallet support and interoperability. This gap became apparent as Cardano began supporting regulated assets (e.g. stablecoins or RWAs) that require features such as freeze-and-seize by an issuer or compliance checks on transfers.

Cardano Improvement Proposal 143 (CIP-143), also known as Interoperable Programmable Tokens, was proposed to bridge this gap. In particular, CIP-143 introduces a standardized way to handle tokens that have custom on-chain transfer logic (smart tokens or programmable tokens). This standard allows issuers to enforce rules like freezing tokens or checking permissions on each transfer, which was difficult to do in a unified manner before CIP-143. Prior to CIP-143, any project needing such functionality had to develop a custom Plutus contract and a unique address for their token, making wallet integration and interoperability difficult.

As development progressed, it became clear that CIP-113 and CIP-143 were two parts of the same overarching standard, with CIP-143 addressing the questions and limitations left by the initial CIP-113 draft. Rather than proceed as separate competing proposals, the authors decided to merge CIP-143 into CIP-113 for a unified standard. The result is that CIP-113 now encompasses all the innovations from CIP-143, essentially becoming the final specification for interoperable programmable tokens on Cardano.

Comparison with ERC-20

CIP-113 draws inspiration from ERC-20 and similar Ethereum token standards, but adapts them to Cardano’s eUTxO paradigm. Here are some key points of comparison:

• Account vs UTxO: ERC-20 tokens live in a contract and their balances are tracked in a mapping of addresses to amounts. CIP-113 tokens live as UTxOs on-chain, each output guarded by scripts. This means that CIP-113 doesn’t require a centralized contract storage for balances — balances are simply the sum of UTxOs belonging to a user. However, CIP-113 provides an account-like abstraction by using a consistent address scheme (each user has one script address for a given token or even one for all CIP tokens) so that from a wallet perspective, the user’s balance can be treated similarly to an account. It achieves the convenience of the account model while leveraging the parallelism and security of UTxOs.
• Standard Interface: ERC-20 defines a standard set of functions (transfer, approve, transferFrom, etc.) to which wallets and dApps must adhere. CIP-113 similarly defines standard behaviors: e.g., how a transfer is structured (by including certain scripts and redeemers) and how a wallet can recognize a token as CIP-113 (via the registry and address format). One notable divergence is CIP-113’s omission of the problematic “approve/allowance” pattern. In Ethereum, approve allows a user to authorize a third-party spend (which led to many exploits when dApps didn’t manage allowances properly). In CIP-113, such delegated transfers can be achieved by having the delegate simply co-sign the transaction (Cardano allows multiple signers natively), or by custom logic in the token script if necessary. Consequently, CIP-113 can simplify to just a “transfer” action in most cases, with less room for user error in approving rogue spenders.
• Security: ERC-20 tokens run inside the Ethereum VM and have historically suffered from reentrancy and integer overflow issues. CIP-113 tokens run as Plutus validators — so while reentrancy is not a concern (UTxOs can be consumed at most once per transaction), developers must be cautious about other things like ensuring that the correct scripts are present and that no bypass exists. Both standards rely on correct implementation of the token logic, but CIP-113 offers a blueprint and templates which should be rigorously audited. One might say CIP-113’s design avoids some known ERC-20 pitfalls (like the allowance race condition by design), but it introduces new complexity in transaction assembly.
• User Experience and Wallet Integration: For end users, using a CIP-113 token could be as simple as using an ERC-20 token in an Ethereum wallet. The wallet will display the token balance and allow sending it to another address. Under the hood, an Ethereum wallet calls the token contract’s transfer function, whereas a Cardano wallet will construct a transaction with CIP-113 scripts. The user experience goal is parity: CIP-113 was explicitly designed so that Cardano wallets and applications automatically recognize these tokens and treat them as first-class assets. For instance, a wallet can detect that an incoming UTxO at a CIP-113 script address corresponds to a known CIP-113 token and then show it in the user’s account. The unified address scheme means a user doesn’t have to manage a different address for each token (unlike some protocols where each token might have its own contract address to interact with).

Overall, CIP-113’s introduction could be analogized to Ethereum’s ERC-20 in terms of impact: It standardizes how advanced tokens are implemented, fostering an ecosystem of interoperable tools and reducing duplication of effort. It also potentially opens the door for cross-chain interoperability, as having an ERC-20 equivalent standard on Cardano makes mapping assets from Ethereum or other chains more straightforward (indeed, projects could issue tokens on Cardano that mirror ERC-20 behavior, easing migration or bridging).

Detailed implementation Walkthrough

At the time of this writing, CIP-113 has not been fully finalized. Some of the following analysis is based on the CIP-143 Proof of concept implementation. However, we expect that CIP-113 would follow a similar standard.

CIP-143 brings significant improvements that have since been incorporated into CIP-113. It introduces a flexible, Plutus-based framework, enabling truly programmable tokens while ensuring they work smoothly with existing Cardano infrastructure. The design proposes a novel address format and a registry mechanism, along with multiple validator scripts. In particular, it follows the stake-validator design pattern (also known as “withdrawal zero trick” pattern) to minimize per-UTxO execution costs by shifting complex logic to a single execution per transaction. Key improvements include the following:

Programmable Token Logic Framework: CIP-113 divides the behavior of programmable tokens into several types of scripts, and develops a standardized on-chain script architecture for tokens that require script validation to transfer. Each programmable token is governed by several Plutus scripts, each with a distinct role:

• Base Script (programmableLogicBase): This is a single global spending script that acts as the common holding contract for all CIP-113 tokens. All UTxOs containing programmable tokens live at this script address. Its primary job is to defer validation to the CIP-113 system rather than enforce token-specific rules itself. In other words, the base script runs when a user tries to spend a UTxO holding a CIP-113 token. It checks for the presence of the CIP-113 global logic in the same transaction and essentially forwards all further checks to that global logic. The base validator is parameterized by a stake credential, which, in this context, is used to identify the intended controller of the tokens. In CIP-113’s standard convention, that stake credential is the user’s own key (so that the token is associated with their identity). However, internally, the base script treats it abstractly: “if the designated global logic (at the stake credential) approves, then the spend is allowed.” The base validator itself does minimal work; it simply enforces that tokens can only be spent if the appropriate token-specific logic is also satisfied.
• Transfer Logic Script (transferLogicScript): A stake validator (Plutus withdraw script) that defines the custom transfer rules for that token, such as daily transfer limits or blacklist checks. During a transaction, this script verifies if token transfers between sender and receiver addresses meet custom conditions. The token creator can implement any policy here.
• Third-Party Transfer Logic Script (thirdPartyTransferLogicScript): Another token-specific validator that manages administrative actions such as freezing, unfreezing, or seizing tokens. It is also implemented as a stake script. These administrative actions do not require the token owner's signature. If the token supports administrative actions, the hash of this script is listed in the registry; otherwise, this field is empty (meaning no one besides the owner can transfer their tokens). The script specifies which public keys have administrative privileges and their allowable actions. For example, a transaction can invoke this script to let an admin address forcibly transfer CIP-113 tokens out of a blacklisted address.
• Issuance Policy & Issuance Logic Script (issuancePolicy & issuanceLogicScript): Together, these control token minting and burning, specifying who can perform these actions and under which conditions (e.g., multisig or time locks). The Issuance Policy is a generic minting policy script which is parameterized by an Issuance Logic Script hash. The Issuance Logic is a token-specific validator that sets the rules for minting or burning. For example, it might allow only a designated issuer’s signature to mint new tokens or enforce a cap on total supply. By having an issuance script, CIP-113 tokens can support complex supply controls . The registry entry ensures the issuance policy used for the token is indeed one that is bound to the correct logic script, preventing unauthorized minting.
• Global State UTxO (globalState): An optional UTxO recording global token state such as a freeze flag or a list of blacklisted addresses. This provides a place to store token-wide settings (for example, toggling a freeze on all transfers, or other stateful controls) on-chain in a standardized way. This state is managed by admin scripts, functioning as a token-level state register.

Each programmable token uses these components to define its behavior. This structured approach enables complex token logic to be expressed with a predictable, interoperable set of scripts. It’s flexible enough to cover scenarios like NFT royalties, regulated securities, or stablecoins with freeze controls — all using the same template of scripts. Because CIP-113 tokens still use normal Plutus V2 scripts and the existing ledger, no hard fork is required to deploy these features. All logic lives in Layer 2 contracts, making it easier to iterate and implement immediately.

By introducing a standard pattern, CIP-113 allows wallets and dApps to recognize and interact with any compliant token automatically. In other words, if a new token follows the CIP-113 standard, any wallet implementing the standard knows exactly how to handle that token. This is similar to how ERC-20 tokens on Ethereum are immediately usable in any ERC-20-compatible wallet. CIP-113’s design achieves similar interoperability for Cardano tokens, despite the UTxO complexity. It defines an on-chain registry and a unified address scheme so that the presence of a token’s policy in the registry signals wallets to apply the token’s script logic. This means users won’t need separate custom-built contracts for each token type. They all adhere to the same interface and lifecycle, greatly improving cross-platform and cross-project compatibility.

Smart Wallet Address Deviation

Unified address format (Smart Accounts): Every normal Cardano address (which typically consists of a payment credential, and optionally a stake credential) gets an associated programmable token address under CIP-113. This special address uses fixed CIP-113 base script hash as the payment credential and the user’s payment key as the stake credential. Consequently, all compliant addresses are controlled by the same Plutus script but uniquely associated with the users’ keys. The result is that each wallet address has a corresponding CIP-113 address where it can receive any CIP-113 compliant token — no need for a new address per token. For example, if a user’s regular address is based on key K, the CIP-113 address for that user is like (CIPbaseScriptHash,stake). This design ensures that all of a user’s CIP-113 tokens can live at one address, which simplifies wallet tracking and avoids scattering tokens across many script addresses.

Token Registration

On-Chain Registry of Token Policies: CIP-113 defines a Token Registry contract where each programmable token policy must be registered along with references to its custom scripts. This registry is an on-chain linked list of entries (each entry is a registryNode UTxO) that maps a token’s policy ID to the hashes of its validator scripts. The registry is established by minting a one-time NFT (using a ProtocolParametersMinting policy script) that tags this UTxO. Token issuers who want to adopt CIP-113 will register their token’s policy script hash in this on-chain registry. By looking up a policy in this registry, transactions can automatically discover if a token is “programmable” and retrieve its script requirements. This enables wallets and dApps to interoperate with programmable tokens without hard-coding token-specific logic — the registry serves as a source of truth. For instance, when you include a programmable token in a transaction, the wallet can fetch the registry entry and forward all checks to the token’s specific script. dApps don’t need to be rewritten for each token; they just ensure that, if an asset is in the registry, its script is executed for transfers.

Architecture of CIP-113/143 programmable tokens

CIP–113 Token Lifecycle

The above components operate together for programmable token lifecycle management. The workflow involves:

1. Registration and Issuance: First, developers write three Plutus scripts (transfer, administrator, issuance), defining specific rules required for the token. Then, they deploy a minting policy, referencing the issuance logic script hash, and register it on-chain. A new entry is added to the token registry, verified for uniqueness. Upon successful registration, a registration NFT is minted to represent this new entry. Subsequently, developers can mint tokens using the minting policy, which must immediately be sent to a smart wallet script address, controlled by the base logic script. Typically, the issuer first sends initial tokens to their smart wallet address before distributing them to users. The token registry should be already deployed on-chain, and the base logic script is fixed for every CIP-113 token.
2. User Holdings and Balance Queries: When users receive CIP-113 tokens, these tokens reside in a user’s smart wallet UTxO, derived from users’ stake credentials combined with the base logic script. Each UTxO can contain one or more token assets, along with Datum, if needed. Since all such UTxO addresses share a common prefix, wallets can easily query and find all UTxOs with Payment Credential equal to the base script and Stake Credential equal to a particular user, thus determining that user's entire programmable token balance. Tokens in these UTxOs are displayed similarly to regular assets within wallets, though they can't be freely spent and must adhere to script rules.
3. Token Transfer Execution Process: When a user wants to transfer a certain amount of tokens to another user, a complex Plutus script interaction occurs. However, wallets handle this interaction automatically:

• Input selection: The wallet selects one or more smart wallet UTxOs from the sender containing the tokens to be transferred. The transaction also includes regular ADA inputs to cover fees.
• Output construction: The wallet creates an output UTxO locked by the base script with the stake credential set to the recipient, containing the transferred token amount. If the sender has leftover tokens, the changed output returns tokens to their smart wallet address.
• Reference data inclusion: To meet programmable validation logic, the wallet must include extra data in the transaction. This typically includes the token registration information, provided through a Reference Input from the token registry node UTxO. This allows validation scripts to access transfer script hashes and other necessary details. With Cardano supporting Reference Scripts, a standard implementation often stores each token's transfer logic script in registry nodes or provided by issuers. Consequently, wallets can directly include the reference script in the transaction without transferring the entire script each time. If transfer logic requires global state checks (such as freezing flags) or other data, corresponding Reference UTxOs or Datum must also be provided.
• Stake credential triggering: In Cardano, a stake validator script executes under a Rewarding purpose when a withdrawal from a reward account is made. CIP-113 cleverly implements transfer logic and administrator logic as Stake scripts, triggered by including a virtual reward withdrawal tied in the transaction (often a zero-ADA withdrawal, known as the “withdraw 0” trick). The base script verifies the execution and success of these Stake scripts before permitting UTxO spending. This approach ensures that both scripts get validated within the same transaction: The base script guarantees process integrity, and Stake scripts perform specific business validations.
• Signature and submission: After constructing these elements, the transaction requires signatures from involved parties. For typical user transfers, at least the sender must sign, verifying authorization to spend their smart wallet UTxO. Finally, the transaction is submitted to the blockchain. During verification, validators sequentially execute the base script validation and call the Stake script to verify token transfer rules. If all validations pass, the transaction is considered valid. The recipient’s smart wallet address generates a new UTxO, completing the token transfer.

Example Transaction Flow

With all pieces in place, we will now look at an example of a CIP-143 transaction flow. Consider a simple token transfer from Alice to Bob of a CIP-143 token:

1. Setup: Alice has 100 tokens locked at her CIP-143 address (payment cred = CIP-143 base script, stake cred = Alice’s key). Bob has an empty CIP-143 address (stake cred = Bob’s key) ready to receive. The CIP-143 registry knows that this token’s policy ID corresponds to the ACP stake script (blacklist logic).
2. Transaction Construction: Alice (or a dApp) builds a transaction with:

• Input: the UTxO from Alice’s CIP-143 address containing 100 tokens (this will invoke the CIP-143 base spending script).
• Output: a UTxO at Bob’s CIP-143 address containing 100 tokens.
• A minimal Input: one of Alice’s normal ADA UTxOs to pay fees.
• No explicit datum is needed on the token UTxOs in this design; the logic is entirely in validators.
• To satisfy CIP-143, the transaction must also include the scripts’ execution contexts. The first is a withdrawal using the CIP-143 global stake credential. This triggers the CIP-143 global validator script with a redeemer indicating a transfer action. The second component involves a withdrawal using the token’s stake credential. This triggers the ACP script with a redeemer carrying, for instance, the blacklist Merkle proofs and indicating a normal transfer.
• The redeemers are set such that the CIP-143 global script knows it’s handling a transfer, and the ACP script is provided with any necessary data.
• Witnesses: Alice signs the transaction with her payment key, since she’s spending her tokens and her ADA for fees. The issuer of this CIP-143 token does not sign, because this is a normal transfer.

3. Validation: During phase-2 validation on chain, the following happens:

• The CIP-143 base validator runs for Alice’s token UTxO input for the purpose of Spending. It finds the CIP-143 global stake script’s redeemer in the transaction, and thus succeeds, consuming virtually no resources itself.
• The global stake validator runs as a purpose of Rewarding for the CIP-143 stake cred. It inspects the transaction and sees that token policy ID XYZ is being transferred. Using the registry, it determines that it needs the ACP script. It finds that a Rewarding CredXYZ redeemer is in fact present for the ACP script in this transaction, so it passes that check. (otherwise, it would have aborted here.) The global script might also enforce any system-wide rules (none in this simple case).
• The token policy stake validator (ACP) runs as a purpose of Rewarding for stake cred CredXYZ. It checks the transaction’s signers against the blacklist UTxO data. Since Alice’s key is not blacklisted in this scenario, and all other conditions are met, the ACP script succeeds, allowing the transfer.
• All scripts have succeeded; therefore, the transaction is valid. It outputs 100 tokens at Bob’s CIP-143 address. Bob’s wallet will now “see” those tokens.

4. Result: Bob effectively controls the 100 tokens at his CIP-143 address. If Bob later wants to send them, a similar process will occur with Bob’s signature and so on.

This flow demonstrates how CIP-143 leverages the UTxO model’s script paradigm to mimic an account-like token transfer: Even though tokens move UTxO-to-UTxO, the user experience can be similar to ERC-20 (balance moves from Alice to Bob with checks in between). The important difference is that every CIP-143 token transfer is an on-chain validated event checking custom rules, rather than just updating balances in a contract ledger. This can add some overhead (multiple scripts running per transfer), but CIP-143’s design keeps it efficient by using the stake-validator pattern — notice that, no matter how many CIP-143 UTxOs Alice spends at once, the heavy logic (global and token script) runs only once for the whole transaction, rather than once per UTxO. This batched validation can significantly reduce computation and fees for large transfers or multi-UTxO consolidations.

Impact to the Cardano Ecosystem

For Cardano’s ecosystem, CIP-113/143 represents a significant evolution in Cardano’s smart contract capabilities. By providing a standard for interoperable programmable tokens, it paves the way for a new class of assets on Cardano that behave more like Ethereum’s tokens (ERC-20, ERC-721, etc.) while still retaining UTxO advantages. It unlocks a host of new use cases that were previously difficult or impossible on Cardano, including stablecoins, securities, RWAs and other regulated assets.

• Regulated Stablecoins: With freeze and compliance logic, issuers like Circle (USDC) or others can more easily launch on Cardano, knowing they can meet regulatory requirements.
• Securities and Real-World Assets (RWAs): Tokenized stocks, bonds, or real estate often need transfer restrictions (e.g., only accredited investors, or lock-up periods). CIP-113 provides the foundation for security token standards on Cardano. It’s similar to Ethereum’s ERC-1400 security token standard, but baked into a unified platform standard. Security issuers can leverage CIP-113’s substandards to implement features like forced transfer (seizure) or trusted issuer whitelists. This could attract enterprise consortia or governments to build on Cardano for compliant asset tokenization.

In addition, The standard allows wallets, exchanges, and DeFi applications to add support for CIP-113 compliant tokens, and gain compatibility with all tokens following the standard all at once — instead of handling each project’s custom contract logic separately.

• Decentralized Finance (DeFi) enhancements: Although DeFi on Cardano could already use native tokens, CIP-113 tokens introduce new dynamics. For example, a lending platform might issue a loan in a CIP-113 stablecoin that can be frozen if collateral falls below a threshold (enforced by script), adding an automatic safety valve. DEXs and money markets will need to incorporate logic to handle failures gracefully — e.g., if a swap involving a frozen token fails, the UI should report why. Minswap, Fluid and others are actively working on supporting these tokens and adjusting their pools to be compatible.
• General token innovation: Programmable tokens mean developers can get creative beyond just freezing functionality. They could implement royalty-enforcing NFTs, where the TransferLogicScript checks if a royalty payment was made, similar to ERC-2981 but enforced on-chain, since CIP-113 can support that by reading a global state or a reference to a royalty address. They can create tokens that only transfer at certain times using slot checks in the script, or gaming tokens that only certain addresses (players) can hold. This expands Cardano’s expressiveness significantly.

Another benefit is that no changes to ADA or existing native tokens are required. CIP-113 tokens coexist with non-programmable tokens. Projects that don’t need these features can continue using simple native tokens or existing Plutus contracts. CIP-113 thus adds new functionality without deprecating or disrupting the old system — a very Cardano-esque approach of incremental, opt-in improvement.

It’s worth noting that CIP-113 standards do come with trade-offs. They sacrifice some of the absolute trustlessness of native tokens — for example, a native Cardano token without such scripts can never be frozen once minted (unless its policy allows minting a burn). However, a CIP-113 token explicitly gives some party the power to freeze or seize under certain conditions. This is a design choice to enable regulated use cases, but it means users and markets will treat such tokens differently than censorship-resistant assets. In other words, CIP-113 tokens reintroduce an element of trust for the sake of programmability. This is similar to how using an ERC-20 stablecoin (like USDC) means trusting the issuer not to freeze your funds arbitrarily. The key difference is that on Cardano, this capability is opt-in per token and transparently governed by an on-chain script whose hash is known (and possibly open-sourced for audit).

Conclusion

In summary, CIP-113 (with CIP-143 merged) is now a detailed and up-to-date standard that transforms Cardano’s token capabilities. It provides the needed infrastructure for secure, programmable value on Cardano, opening the door to assets that comply with legal requirements while retaining the benefits of decentralization. The standard is technical and complex under the hood, but its adoption is being smoothed out by Harmonic Labs and others via Project Catalyst, who have been working on implementations and by clear documentation. As the final pieces fall into place, Cardano will have an answer to Ethereum’s ERC-20 and beyond — one that’s arguably more secure and essentially interoperable across the ecosystem, thanks to the thoughtful design of CIP-113.