Cardano Proposal Seeks Shared Rules for Regulated Stablecoins
A new Cardano problem statement proposes a common technical framework for regulated stablecoins built with CIP-113. The goal is to let wallets, exchanges and DeFi protocols support multiple compliant assets without building a separate integration for each token.
By SongMarketCap
Updated:
Pull request #1266, titled “Standardisation of Regulatable Stablecoins,” was submitted to the Cardano CIPs repository on September 10 by Alex Moser.
The document does not introduce a stablecoin or an approved standard. It defines an interoperability problem that could affect regulated token issuers and infrastructure providers across the Cardano (ADA) ecosystem.
CIP-113 Tokens Can Require Separate Integrations
CIP-113 provides shared infrastructure for programmable tokens, including a registry, core validators and a common method for holding the assets. Individual token rules are handled through additional substandards selected by each issuer.
According to the new proposal, those differences can create substantial integration work. A transaction may need reference inputs, proofs and redeemers specific to the token’s rules and deployment.
One stablecoin could use a denylist, another could restrict transfers to approved users, while a third might require verification from an external KYC service. Wallets, exchanges, custodians and decentralized applications must understand those requirements before they can construct valid transactions.
The proposed shared substandard would give compliant stablecoins a consistent transaction structure. Issuers could retain different roles and configurations without requiring infrastructure providers to build entirely new transaction logic for every asset.
The Draft Covers Freezing, Seizure and Redemption
The CPS lists capabilities that a future standard may need to support. These include issuer-controlled minting and burning, a supply cap, account freezing and the ability to seize or destroy frozen balances.
It also proposes separate permissions for minting, administration and enforcement actions. Multisignature authorization and key rotation would be supported without requiring the issuer to migrate the token.
Freezes and seizures could carry standardized reason codes, allowing wallets and auditors to interpret the action without placing personal information on the blockchain. Basic token information, including the issuer and a reference to its terms or white paper, could also follow a common format.
The draft gives particular attention to redemption. It asks how transfers could be paused during an incident while still allowing an eligible holder to return tokens to the issuer for repayment.
These requirements are mapped against the European Union’s MiCAR framework and the United States GENIUS Act. The document uses those regulations as design references and explicitly states that it does not provide legal advice.
Technical and Regulatory Questions Remain Open
PR #1266 remains open, has no assigned CPS number and does not contain a finalized solution. Its current purpose is to collect feedback from stablecoin issuers and infrastructure providers before a technical standard is written.
Reviewers have requested closer alignment with the continuing development of CIP-113. They also warned that comparisons of existing implementations could quickly become outdated and should be separated from requirements intended to remain relevant over time.
Unresolved questions include whether denylist and allowlist systems can use the same transaction structure, how personal data should be excluded from permanent blockchain records and how protocols can identify changes to an issuer’s validation logic.
The proposal also asks whether an issuer should be able to freeze assets held inside a DEX pool or lending protocol, and how those applications could evaluate that risk before listing a token.
CIP-113 is marked as being in Last Check, but its pull request has not yet been merged into the main CIPs repository. The regulated stablecoin CPS therefore creates no new requirements for issuers or applications in the ADA ecosystem.
Its next steps depend on CIP triage, feedback from issuers and confirmation that the proposed requirements can be implemented without fragmenting CIP-113 into incompatible versions.