Cardano’s proposed programmable‑token standard would allow a freeze on one asset to temporarily block unrelated tokens held in the same transaction output.
CIP‑113, merged into Cardano’s improvement‑proposal repository on Sept. 29, adds issuer‑controlled transfer rules to native assets while preserving the network’s eUTXO model.
The Cardano Foundation presents programmable tokens as infrastructure for regulated financial assets—such as stablecoins, securities and real‑world assets—that may require transfer restrictions, freezes and other compliance controls.
This could broaden Cardano’s appeal to institutional issuers but also introduces new dependencies for wallets and DeFi applications when several assets share an output.
The milestone, however, is not yet complete. CIP‑113 remains “Proposed” until it is issued on Preview and mainnet, undergoes end‑to‑end testing, and gains support from a widely adopted wallet.
Matteo Coppola, CEO of Fluid Tokens and a contributor to CIP‑113, called the merge a years‑long development achievement that puts the framework into Cardano projects’ hands.
“The official standard for programmable tokens on Cardano, including securities, is now out,” Coppola said, noting that contributors worked to make it production‑ready.
Compliance rules can spill across a shared output
On Cardano, the rules governing one programmable token can affect other assets bundled with it in the same output.
Under the eUTXO model, a transaction output may contain multiple tokens and ADA. Spending that output consumes it as a unit, so a restriction attached to one programmable asset can determine whether the whole transaction goes through.
For example, if an output contains restricted token A, unrelated token B and ADA, a freeze or denylist rule on A can prevent the holder from moving B, even though B and ADA are not themselves frozen.
CIP‑113 provides a “unfracking” mechanism to break that dependency. The process lets one token policy be separated from the rest of an output without changing ownership. If permitted, A can be moved into its own output while B stays in another output controlled by the same holder. A remains restricted, and B is no longer subject to A’s transfer rule on a subsequent spend.
The holder does not automatically control this separation; it requires authorization and must satisfy the affected token’s registered rules.
An unfracking transaction needs the holder’s authorization and must also satisfy the affected token’s separation rules, which can require an extra signature, impose script‑based conditions, or block restructuring altogether.
Because a token’s policy may not allow separation, unrelated assets sharing an output can remain inaccessible until the relevant conditions change. The proposal distinguishes this kind of blockage from seizure; an issuer’s control over one token does not grant ownership of other assets in the same output, and the reference implementation is designed to preserve balances belonging to unrelated token policies during authorized third‑party actions.
For wallets and DeFi applications, the practical consequence is that asset ownership alone may no longer guarantee immediate spendability. How tokens are grouped inside an output, and what separation permissions each policy allows, can become part of the risk attached to holding or accepting them.
Wallets and DeFi protocols inherit the design risk
Avoiding that dependency may require changing how assets are packaged before any restriction is triggered. The CIP‑113 reference implementation recommends single‑policy outputs as the preferred construction, though developers are not forced to follow it. Keeping programmable assets separate reduces the chance that one issuer’s compliance action prevents an unrelated token from moving.
ADA is also exposed; outputs that contain tokens also carry ADA, so some of the native asset can become temporarily inaccessible when it shares an output with a restricted programmable token.
This adds complexity for wallets: a displayed balance may show what a user owns without revealing what can be spent immediately. Applications supporting CIP‑113 may need to track which policies share an output, the permissions attached to each asset, and whether a blocked token can be separated.
For lending protocols, the issue becomes a collateral‑management risk. A DeFi platform accepting a programmable token must assess whether its issuer can freeze transfers, whether the protocol can authorize separation, and whether those controls could interfere with withdrawals or liquidations. A restriction arriving during a market downturn could be especially consequential if a lender cannot move collateral when it needs to close an undersecured position.
As Cardano expands its stablecoin and tokenized‑asset market, solutions like USDCx—backed one‑for‑one by USDC through Circle’s xReserve—are already adding liquidity. CIP‑113 could widen that market by giving prospective issuers the compliance controls required for regulated stablecoins, securities and other tokenized assets while retaining Cardano’s native‑asset architecture.
The trade‑off is that wallets and DeFi protocols may have to treat an asset’s permission structure as an additional layer of financial risk.
Wallet developers could segregate programmable policies by default, while lending protocols might impose lower collateral values, tighter parameters, or reject tokens whose freeze and separation rules create uncertainty around liquidation.
The focus now is on the first production integrations. As projects adopt CIP‑113, their decisions on output construction and issuer permissions will help determine whether regulated assets can plug cleanly into Cardano’s DeFi markets or whether protocols must price the risk that compliance controls could restrict access to collateral when it is needed most.
