CIP-0113 Explained: How Cardano Programmable Tokens Could Shape Institutional Finance

Cardano's CIP-0113 programmable token standard introduces a new approach to one of the biggest challenges in institutional blockchain adoption: how to tokenize financial assets while maintaining the controls required by regulated markets.

For banks, asset managers, stablecoin issuers, and other financial institutions, tokenization involves more than representing an asset on a blockchain. It also requires clear rules governing ownership, investor eligibility, transfers, compliance, and intervention by authorized parties.

CIP-0113 addresses part of this challenge by allowing token-specific rules to be enforced through Cardano's transaction validation process.

On October 7, 2026, the Cardano Foundation announced that CIP-0113 programmable tokens were live on Cardano mainnet, following development work and independent security audits. The announcement marked an important milestone for programmable assets on the network.

However, institutions should distinguish between a live implementation and the formal status of the specification. As of October 9, 2026, the official CIP-0113 page still lists the proposal as "Proposed."

The distinction matters. Mainnet availability demonstrates that technology has been deployed, but it does not automatically establish production readiness for every financial use case.

So, what exactly does CIP-0113 enable, how does it work, and what should financial institutions consider before adopting it?

What Is CIP-0113?

CIP-0113 is a Cardano Improvement Proposal that defines a standard for programmable token-like assets.

Unlike conventional Cardano native tokens, which can generally be transferred without token-specific transfer restrictions after issuance, programmable tokens require additional validation before ownership can change.

Consider the difference.

A conventional native token establishes that an asset exists and belongs to a particular address.

A programmable token adds another condition: the asset can change hands only when the rules governing that specific token are satisfied.

These rules may include:

• Investor eligibility: restricting ownership or transfers to approved participants.

• Allowlist and denylist controls: permitting or blocking transactions based on predefined criteria.

• Transfer restrictions: enforcing conditions based on the asset's intended use.

• Issuance and burning controls: specifying who can create or destroy tokens and under what circumstances.

• Authorized third-party actions: allowing interventions such as freezes, seizures, or forced transfers when explicitly supported by the token's policy.

Not every CIP-0113 token needs all these capabilities. The standard provides an architecture in which different assets can implement different policies.

That flexibility is particularly relevant to institutional finance, where a regulated stablecoin, a tokenized bond, and a fund share may operate under very different legal and operational requirements.

Why CIP-0113 Matters for Institutional Tokenization

Tokenization has become an increasingly important topic across traditional finance.

Banks and financial institutions are exploring how bonds, securities, investment funds, deposits, and other real-world assets (RWAs) can be represented and transferred using blockchain infrastructure.

But issuing a token is only the beginning.

The real challenge is determining how that token behaves after issuance.

Imagine a tokenized investment fund that can only be held by eligible investors. Before accepting a transfer, the issuer may need assurance that the recipient has completed the required onboarding process and meets the relevant investment criteria.

Similarly, a tokenized security may be subject to restrictions based on jurisdiction, investor classification, or applicable securities regulations.

A regulated stablecoin issuer might also need mechanisms to restrict certain transactions or respond to legally authorized interventions.

These requirements are difficult to address through unrestricted token transfers alone.

CIP-0113 makes it possible for asset-specific conditions to become part of the transaction validation process.

Instead of relying entirely on external applications to manage transfer restrictions, an implementation can enforce certain conditions whenever the token moves.

For financial institutions, this introduces a potentially valuable connection between public blockchain infrastructure and the controls that regulated financial products require.

It does not eliminate compliance obligations. It creates another technical way to enforce some of the decisions made by compliance systems.

How CIP-0113 Works on Cardano

One of CIP-0113's defining characteristics is its relationship with Cardano's existing architecture.

Programmable tokens remain native Cardano assets from the ledger's perspective. The standard uses existing Cardano primitives rather than introducing a separate wrapped-asset model.

The official specification also describes an approach that does not require a Cardano hard fork.

At a high level, the architecture separates shared infrastructure from the rules governing individual tokens.

Shared Infrastructure and Token-Specific Policies

CIP-0113 uses three main architectural layers.

1. Registry infrastructure

An on-chain registry identifies programmable tokens and records the configurations associated with them.

This allows the protocol and supporting tools to identify the validation logic relevant to a particular asset.

2. Shared validation infrastructure

Common scripts provide the framework for handling programmable-token operations and directing transactions to the appropriate validation logic.

3. Token-specific logic

Individual tokens define their own rules through scripts that govern transfers, issuance, burning, and permitted third-party actions.

For example, a tokenized fund may require recipient eligibility checks, while a stablecoin issuer may implement different transfer restrictions and administrative controls.

The important point is that CIP-0113 does not impose one universal compliance policy on every programmable token.

It provides the infrastructure through which individual policies can be implemented.

For institutional technology teams, this means that understanding the standard is only the first step. The behavior of the specific token matters just as much.

What Happens During a CIP-0113 Token Transfer?

Consider a financial institution that wants to issue tokenized fund shares to a restricted group of investors.

A simplified transaction flow might look like this:

1. The issuer defines the token policy. The policy specifies the conditions under which the asset can be issued, held, transferred, or subject to authorized interventions.

2. Investor eligibility is established. An external onboarding or compliance system verifies the investor's status and makes relevant eligibility information available to the transaction process.

3. The holder initiates a transfer. A compatible wallet or transaction-building service prepares the operation using the required Cardano transaction structure.

4. The relevant scripts validate the transaction. The token-specific logic evaluates the applicable conditions, using the information and proofs required by that implementation.

5. The transaction succeeds or fails. If the transaction satisfies the applicable rules and Cardano ledger requirements, it can be accepted by the network. Otherwise, it fails validation.

The precise data flow, transaction-building requirements, and error handling depend on the token implementation.

From a bank's perspective, that variability matters.

A proof of concept should therefore test not only successful transfers but also rejected transactions, expired eligibility information, service outages, and exceptional interventions.

Does CIP-0113 Perform KYC and AML Checks?

No. CIP-0113 does not independently perform Know Your Customer (KYC) verification, Anti-Money Laundering (AML) screening, or sanctions checks.

This is an important distinction when discussing on-chain compliance.

A blockchain cannot independently establish someone's legal identity, determine whether an investor meets a jurisdiction's requirements, or guarantee that a transaction complies with financial regulations.

Those decisions may still rely on existing financial infrastructure, including identity providers, screening services, compliance departments, and external databases.

CIP-0113 provides a mechanism through which a token implementation can enforce rules based on relevant information from those systems.

For example, an institution could verify a customer's eligibility through its existing onboarding process. The programmable token's transfer logic could then use an approved eligibility status when evaluating a transaction.

This does not inherently require publishing identity documents or other sensitive personal information on a public blockchain.

However, the actual privacy characteristics depend on the implementation, including what data is exposed, how eligibility status is represented, and how that information is updated.

For institutions, a sound integration design must answer several questions:

• Which compliance decisions are made off-chain?

• How does the transaction receive the information needed to enforce those decisions?

• What happens when eligibility changes or expires?

• How are errors and exceptions reviewed?

• What happens if an external compliance service becomes unavailable?

The key architectural benefit is the potential separation between compliance decision-making and transaction-level enforcement.

That separation may allow financial institutions to retain existing identity and compliance systems while incorporating blockchain into their asset infrastructure.

Can Public Blockchains Support Regulated Financial Assets?

Public blockchains are often associated with permissionless transactions, where participants can transfer assets without approval from a central authority.

Regulated financial markets operate differently.

Depending on the product and jurisdiction, an issuer may need to restrict ownership, prevent unauthorized transfers, or intervene under legally defined circumstances.

These requirements can conflict with the expectation that holding a blockchain asset always provides unrestricted transferability.

Programmable tokens introduce a different model.

The underlying blockchain can remain public while individual assets operate under specific transfer rules.

For some decentralized finance users, this may represent an undesirable limitation on financial autonomy.

For institutional issuers, those same restrictions may be necessary to make public blockchain infrastructure usable for regulated products.

CIP-0113 therefore raises a broader question about the future of tokenization:

Can open blockchain infrastructure coexist with asset-level permissions and institutional accountability?

Cardano's programmable token architecture provides one approach to that challenge.

The Trade-Off: Programmable Compliance and Asset Control

Programmability introduces capabilities, but it also creates dependencies and risks.

If a token's policy allows an issuer or another authorized party to restrict transfers, holding the token does not necessarily guarantee unrestricted control over its movement.

This distinction affects several aspects of institutional asset management.

Custody and Transferability

A wallet may display a token balance even when the token cannot currently be transferred under its applicable policy.

For institutional custodians, simply displaying or safeguarding an asset is therefore not sufficient.

Custody systems also need to understand the transaction rules, the authorized parties, and the operational conditions affecting the asset.

Liquidity and Collateral Management

Transfer restrictions may become especially important when programmable assets are used as collateral.

Consider a lending platform that accepts a programmable token as security for a loan.

If that token becomes restricted when the lender needs to liquidate the position, the liquidation process may be delayed or prevented.

This creates risks that cannot be assessed through market value and smart-contract security alone.

Financial institutions must also evaluate who controls the token's transferability, when restrictions can be activated, and how those restrictions affect enforcement rights.

These questions are familiar in traditional finance. Programmable assets bring them directly into blockchain transaction infrastructure.

Why Cardano's eUTXO Model Matters for Programmable Tokens

CIP-0113 also introduces operational considerations related to Cardano's extended Unspent Transaction Output (eUTXO) model.

In Cardano, a single transaction output can contain ADA alongside multiple native assets.

This creates an important issue when programmable tokens with different transfer rules share the same output.

Suppose an output contains ADA, a conventional native token, and a programmable token that is currently restricted.

If a transaction attempts to spend that output and cannot satisfy the programmable token's validation requirements, the transaction may fail even if the intention was to move the other assets.

This does not mean the programmable token's issuer has independently frozen every asset in the output.

The constraint arises from the way the assets are grouped and the requirements for validating the transaction.

How Does CIP-0113 Address Shared Outputs?

The CIP-0113 specification describes an unfracking mechanism intended to support the separation of assets into different outputs while preserving ownership.

However, this mechanism is subject to token-specific conditions and is not automatically available for every programmable asset.

Its behavior depends on the relevant policy and transaction structure.

For banks, wallet developers, and institutional custodians, this makes asset segregation an operational design consideration rather than a minor technical detail.

Infrastructure teams should examine how programmable-token UTXOs are created, managed, separated, and transferred, particularly when different assets have different restrictions.

What CIP-0113 Means for Institutional Custody and Wallets

The introduction of programmable tokens also changes what meaningful wallet support looks like.

A wallet or custody platform may be able to recognize a token without supporting all the operations required by its policy.

Institutional users may need capabilities such as:

• Constructing and signing transactions that satisfy the token's rules.

• Identifying applicable transfer restrictions.

• Explaining why transactions fail validation.

• Supporting authorized issuance, burning, or exceptional operations where relevant.

• Managing outputs containing multiple assets with different restrictions.

• Maintaining reliable audit and operational records.

The Cardano Foundation's October 7, 2026 announcement identified ecosystem participants including Eternl, GeroWallet, CardanoScan, and BloxBean.

This is an encouraging development for ecosystem integration, but the presence of supporting tools should not be confused with universal institutional production readiness.

A bank must independently verify the capabilities of its selected wallets, custodians, transaction services, and policy implementations.

The relevant questions concern not only whether a platform supports CIP-0113, but which operations it supports, which versions have been tested, and what operational guarantees are available.

Governance: Who Controls a Programmable Token?

Technical programmability is only one part of the institutional assessment.

Governance may be even more important.

If an asset can be frozen, seized, transferred through authorized third-party intervention, or managed through configurable policies, the institution needs a clear understanding of who holds those powers.

Relevant governance questions include:

• Who can authorize restrictions or exceptional transfers?

• Who controls the keys required to execute those actions?

• Who can modify the token's policy or related configuration?

• What approval procedures govern sensitive operations?

• What happens if an asset is restricted by mistake?

• What legal remedies are available to the token holder?

• How are administrative actions documented and audited?

• What happens if an external identity or compliance system fails?

CIP-0113 does not establish a universal governance model for all token issuers.

The authority assigned to third parties and the actions they can perform depend on the token-specific implementation.

A programmable token may therefore provide strong technical controls without necessarily offering an acceptable governance framework for a particular financial institution.

The two must be evaluated separately.

Giovanni Gargiulo and the Development of CIP-0113

The development of Cardano programmable tokens also has a connection to BitDiver.

Giovanni Gargiulo, Senior Blockchain Architect at the Cardano Foundation, is among the authors of CIP-0113, alongside Michele Nuzzi, Matteo Coppola, and Philip DiSarro.

At BitDiver, we also had the opportunity to meet Gargiulo personally at Blockchain Beach, making the evolution of this initiative particularly interesting to follow.

In March 2026, Gargiulo presented the Cardano Programmable Tokens Platform, outlining the Foundation's work on programmable assets and the infrastructure intended to support their adoption.

That work included the consolidation of earlier programmable-token initiatives, implementation development using Aiken, and reference integrations for wallets, explorers, indexers, and decentralized applications.

This development history highlights an essential requirement for institutional blockchain adoption.

A technical standard is not enough by itself.

Developers need documentation and reference implementations. Wallets need practical integration paths. Custodians need predictable transaction behavior. Financial institutions need mature tooling, operational procedures, and reliable support.

The transition from a proof of concept to a production financial system depends on the quality of that entire ecosystem.

CIP-0113 vs. ERC-3643: Different Approaches to Regulated Tokenization

Cardano is not the first blockchain ecosystem to explore programmable compliance for digital assets.

On Ethereum and compatible networks, ERC-3643 provides an established approach to permissioned token transfers and identity-aware tokenization.

Both CIP-0113 and ERC-3643 address an important requirement: enabling digital assets to operate under rules that may be necessary for regulated financial products.

However, the two approaches are built around different blockchain architectures.

ERC-3643 operates through an Ethereum smart-contract-based token framework, while CIP-0113 uses Cardano's native assets and eUTXO-based infrastructure.

For institutional buyers, the comparison should extend beyond supported compliance features.

Relevant evaluation criteria include identity integration, custody architecture, asset behavior, governance, transaction construction, auditability, tooling, operational maturity, and legal requirements.

The most appropriate solution depends on the financial product and the institution's operating model.

CIP-0113 should not be interpreted as Cardano having solved every challenge of regulated tokenization.

Instead, it offers another technical architecture for connecting public blockchain infrastructure with the requirements of controlled financial assets.

CMTA Recognition: What It Means for Cardano Tokenized Securities

Another important development was announced on October 7, 2026.

The Capital Markets and Technology Association (CMTA) confirmed that a specific Cardano CIP-0113 Programmable Asset Tokens implementation, known as the Cardano CMTA smart contract, had been recognized as equivalent to the CMTAT under the CMTA Tokenized Shares certification scheme.

The recognition relates to an implementation designed to meet the relevant equity-tokenization requirements of the CMTAT Framework.

It allows qualifying issuers to use that implementation for ledger-based equity securities within the scope and conditions of the certification scheme.

This represents meaningful institutional recognition for Cardano's programmable-token infrastructure.

However, its scope is important.

The recognition does not mean that every CIP-0113 token automatically meets the CMTAT Framework, has received regulatory approval, or complies with securities laws in every jurisdiction.

Nor does it remove the issuer's responsibility to address the legal structure, investor eligibility, disclosures, custody arrangements, privacy obligations, and other regulatory requirements of the financial product.

For banks, the lesson is straightforward: technical compliance capabilities and legal compliance are related, but they are not interchangeable.

What Bank CTOs Should Evaluate Before Adopting CIP-0113

For a bank's CTO, digital asset team, or technology risk function, the value of CIP-0113 ultimately depends on whether its capabilities can be translated into a secure and manageable operating model.

Before adopting a programmable asset, institutions should evaluate several areas.

1. Token Policy and Control Rights

Determine exactly which restrictions apply to the asset and who can exercise the relevant powers.

Review whether policies can change, who can authorize changes, and how exceptional operations are handled.

2. Identity and Compliance Integration

Identify the systems responsible for KYC, AML, sanctions screening, and investor eligibility.

Understand how relevant information reaches the transaction validation process and what happens when it is unavailable or outdated.

3. Custody and Transaction Infrastructure

Verify that the chosen custodian and wallet stack can construct, sign, and process the necessary transactions.

Assess how transaction failures, multi-asset outputs, and segregation requirements are managed.

4. Liquidity and Operational Resilience

Evaluate whether restrictions could prevent transfers, settlement, collateral liquidation, or other critical operations.

Test scenarios involving service interruptions, policy changes, and exceptional market conditions.

5. Governance, Auditability, and Legal Accountability

Document administrative privileges, approval processes, key management responsibilities, audit trails, and procedures for resolving disputes or mistakes.

Confirm that the technical implementation supports the legal and operational structure of the asset.

6. Implementation Maturity

Review the exact software versions, security-audit scope, known limitations, and integration support offered by the relevant providers.

Do not assume that a mainnet deployment, a published specification, or ecosystem support is sufficient evidence of production readiness.

These questions help determine whether token programmability reduces institutional complexity or merely relocates that complexity into a different technology layer.

From Tokenization to Policy-Aware Financial Infrastructure

The first major question in financial tokenization was whether assets could be represented on a blockchain.

Could a bond be issued as a token? Could fund shares exist on-chain? Could a stablecoin move across a public network?

Increasingly, the more important question concerns what happens next.

Financial institutions need tokenized assets that can operate within established frameworks of permissions, custody, compliance, governance, and legal accountability.

CIP-0113 contributes to this shift by making asset-specific transaction rules possible within Cardano's native-token architecture.

It does not replace compliance departments, KYC providers, legal frameworks, custodians, or governance procedures.

Nor does it guarantee that a particular token is suitable for institutional use.

What it provides is a mechanism through which certain rules defined by those surrounding systems can be enforced when an asset changes hands.

For banks evaluating public blockchain infrastructure, that represents a meaningful architectural development.

The question is no longer simply whether an asset can be tokenized.

It is whether that asset can operate on-chain while meeting the practical requirements of regulated finance.

CIP-0113 gives Cardano a concrete framework for addressing part of that challenge.

Whether it is sufficient for any particular institution will depend on the token's policy, implementation, governance, custody infrastructure, and applicable legal requirements.

At BitDiver, we believe that understanding these technical and operational distinctions is essential to evaluating how blockchain infrastructure can support real financial use cases.

As tokenization evolves, the institutions best positioned to benefit will be those that look beyond token issuance and examine how digital assets behave throughout their entire lifecycle.

Frequently Asked Questions About CIP-0113What is CIP-0113 on Cardano?

What is CIP-0113 on Cardano?

CIP-0113 is a Cardano Improvement Proposal defining a framework for programmable token-like assets. It enables token-specific transaction validation rules, which can support restricted transfers, controlled issuance, and certain authorized third-party actions depending on the implementation.Are CIP-0113 programmable tokens live on Cardano mainnet?

Are CIP-0113 programmable tokens live on Cardano mainnet?

Yes. On October 7, 2026, the Cardano Foundation announced that the programmable-token standard was live on Cardano mainnet. However, as of October 9, 2026, the formal CIP-0113 page still displayed the status "Proposed." The implementation announcement and formal proposal status describe different aspects of the standard's development.Does CIP-0113 perform KYC or AML checks?

Does CIP-0113 require a Cardano hard fork?

According to the official specification, CIP-0113 uses existing Cardano primitives and does not require a hard fork. Institutions should still verify the requirements and compatibility of the specific implementation they plan to deploy.

Can CIP-0113 tokens be frozen or seized?

Certain token policies can support freezes, seizures, forced transfers, or other authorized interventions. These functions are not mandatory features of every CIP-0113 token. Their availability and governance depend on the specific implementation.

What is the difference between CIP-0113 and regular Cardano native tokens?

Regular Cardano native tokens generally do not require asset-specific transfer validation after issuance. CIP-0113 programmable tokens can require additional scripts to validate changes in ownership while remaining native Cardano assets from the ledger's perspective.

Is CIP-0113 suitable for banks and financial institutions?

CIP-0113 provides capabilities that may be useful for institutional tokenization, including configurable transfer restrictions and transaction-level enforcement. Suitability depends on the specific token policy, custody support, security assessment, operational model, governance, and applicable legal requirements.

Does CIP-0113 make tokenized financial assets legally compliant?

No. A technical standard cannot independently guarantee legal or regulatory compliance. Financial institutions must assess the financial product, jurisdiction, issuer obligations, investor eligibility, governance structure, custody arrangements, and other relevant regulatory requirements.

Does CIP-0113 perform KYC or AML checks?

No. CIP-0113 is not an identity-verification or sanctions-screening service. External compliance systems can establish eligibility, while a token implementation may use relevant information from those systems to enforce transfer restrictions.