What is CIP-113?¶
CIP-113 is a proposed Cardano Improvement Proposal that introduces programmable tokens: native assets whose transfers are governed by on-chain validator logic, not just minting policies.
Status: Proposed (as of 2026). The spec is actively evolving toward Active.
The problem CIP-113 solves¶
Cardano native assets are simple: a minting policy controls who can mint or burn them, but once tokens exist they can be sent to any address freely. There is no hook that runs on every transfer.
CIP-113 adds that hook. It defines a protocol that requires every transfer of a registered token to satisfy a programmable logic validator. This enables:
- Restricted tokens that cannot leave an approved address set
- Regulated assets that require compliance checks on every move
- Tokens with automatic royalties or fees on transfer
- Third-party freeze and seize for risk management
Architecture¶
CIP-113 defines a family of on-chain validators and a registry that links them together.
Registry¶
A linked-list of registered token policies. Each node in the registry records:
- The policy ID of the registered token
- The hash of the
PPM(policy parameter mint) script that governs the node - The hash of the
PLG(programmable logic global) script - The hash of the
PLB(programmable logic base) script - A reference to the third-party transfer logic script
Smart wallets¶
Registered tokens must live at smart wallet addresses. A smart wallet address uses:
- Payment credential: the
PLBscript hash (controls spending) - Staking credential: any credential (controls staking rewards)
A plain key address or arbitrary script address is rejected by the PLG validator.
Validators¶
| Validator | Role |
|---|---|
PPM (policy_parameter_mint) |
Controls who can add or remove a token from the registry |
PLG (programmable_logic_global) |
Staking withdrawal script invoked on every transfer; validates the entire transaction |
PLB (programmable_logic_base) |
Spending script at smart wallet addresses; delegates validation to PLG |
registry_mint |
Mints/burns registry linked-list nodes |
registry_spend |
Manages registry node UTxOs |
issuance_mint |
Minting policy for the registered token itself |
always_fail |
Used as the staking credential of freeze lock addresses |
Transfer flow¶
Every transfer of a CIP-113 token must include a PLG withdrawal (amount 0) in the transaction. The withdrawal invokes the PLG validator, which checks:
- Every input containing registered tokens comes from a smart wallet address
- Every output containing registered tokens goes to a smart wallet address
- All substandard logic scripts (if any) are also present as withdrawals
Freeze and seize¶
The PLG ThirdParty redeemer enables a designated third-party script to override the standard transfer rules:
- Freeze: move tokens to a smart wallet whose staking credential is
always_fail. The tokens are locked — no future transfer is possible. - Seize: redirect tokens to a new smart wallet owner, bypassing the usual ownership check.
The third-party script proves its authority by including its own staking withdrawal in the same transaction.
Substandards¶
CIP-113 is designed to be extensible. A substandard is an additional transfer logic script that can be layered on top of the base protocol. Each registered token can declare which substandards apply, and the PLG validator checks that the required substandard withdrawals are present.
Substandards are identified by their staking withdrawal credential in the transaction. Adding a new substandard means:
- Writing a staking script that expresses the additional rule
- Registering its staking account on-chain
- Declaring it in the registry node for the relevant token
Relationship to ERC-20¶
CIP-113 serves a similar purpose to Ethereum's ERC-20 transfer hooks, but the mechanism is entirely different. There is no transferFrom call; the validation happens as a staking withdrawal side-effect. This keeps the UTXO model intact while adding programmable transfer semantics.