Programmable tokens (CIP-0113)
What it is
CIP-0113 is a token standard with embedded logic: tokens that carry rules which can change after issuance. Think RWA tokenization with compliance logic (whitelist and blacklist rules an issuer can update), sanctions screening, or regulatory reporting built into the token itself. The design has two layers: a core standard (custody model, on-chain registry, global validation coordinator, issuance) plus pluggable "substandards" for token-specific rules.
What you could build
Compliant RWA or tokenized-securities products with updatable transfer rules
Sanctions-screened transfer rails for regulated markets
Regulated stablecoin logic on top of a programmable-token base
What the pilot expects
Leveraging CIP-0113 means real compliance-governed token actions on mainnet: mints, transfers, and rule updates under your declared policy. Actions initiated from your own declared wallets never count (Standard §5.2), so design flows where third parties, not the issuer alone, generate the activity. Floors and target guidance for this category are in the Transaction Integrity Standard (§3.1, §3.3).
Get building
cardano-foundation/cip113-programmable-tokens: reference on-chain validators (Aiken) with docs: introduction · developing substandards
cip113-programmable-tokens-platform: end-to-end testnet environment
Community implementation: FluidTokens ft-cip-113
Background: CF blog explainer
Readiness & constraints
You'd be building on a moving standard, so go in with open eyes. The spec is still an open pull request (close to merge, but it may change before finalization). The reference implementation has been tested on the Preview testnet only, is not professionally audited, and describes itself as not production-ready. You can start development and adoption work on pre-production environments now; plan for the standard to evolve under you. The pilot's mainnet requirement still applies: your M1 plan should show how you get from pre-production to real mainnet transactions within the window, including how you handle the audit and risk gap. There are already a few substandards, if one of them fits your needs use them over writing a new one. Example of a substandard (in progress): https://github.com/FluidTokens/fn-bafin-cardano-sc.
A note on adoption and standard-level risk. The adoption leg of this grant depends on CIP-0113 being viable on mainnet. If the standard itself proves not feasible to run on mainnet within the program window, through no fault of your team, the adoption part of the grant may be delayed or, where delivery is impossible, cancelled; the build payment is not affected. Raise any standard-level blocker with the program as soon as you see it, not at the deadline.
And an opportunity alongside the risk: building on CIP-0113 now makes you an alpha user of the standard. You'll be exercising it against real requirements before most of the ecosystem touches it, which means you're better placed than anyone to find where it breaks. Separately from this pilot, a bug bounty program for CIP-0113 may be active during your build, run by the workstream that maintains the standard. Real bugs uncovered in the course of your own integration work may qualify for rewards there, under that program's own terms and on top of your grant. Watch the relevant channels for announcements, and report what you find either way.
Last updated