Token Pools (Canton)

CCIP supports the CIP-56 Token Standard. Making tokens transferable via CCIP is unpermissioned: the owner of a token or asset can deploy and configure a token pool to allow users to transfer the underlying asset to and from Canton.

A token pool deployment consists of:

On-ledger: Token pool contract and Token Admin Registry (TAR) entry.
Off-ledger: Explicit Disclosure Service for the pool so users can obtain contract disclosures during send and execute flows.

Token pool types

BurnMint Token Pool

Designed for tokens whose supply can vary across chains. Requires the optional BurnMintFactory interface on the underlying token.

Direction	Behavior
Send (source)	Sender tokens are burned; supply decreases on the source chain.
Receive (destination)	New tokens are minted for the receiver; supply increases on the destination chain.

Characteristics:

No pool liquidity required — mints on demand on receive.
Underlying token must support BurnMintFactory.
Pool owner must be the instrument admin (instrumentId.admin == poolOwner).

Deploy a BurnMint pool →

LockRelease Token Pool

Designed for fixed-supply tokens where cross-chain transfers are backed by locked liquidity. Uses the CIP-56 TransferFactory interface.

Direction	Behavior
Send (source)	Sender tokens are locked (transferred to the pool owner via pre-approval).
Receive (destination)	Tokens are released from pool holdings to the receiver — immediately or via a pending `TransferInstruction`.

Characteristics:

Pool must hold sufficient liquidity for inbound releases.
Total supply remains constant; tokens move between pool and users.
Token must support transfer pre-approvals.
Pool owner is not enforced to be instrument admin, but strongly recommended (see trust model below).
Caller must provide pool holdings via extraContext on execute.

Deploy a LockRelease pool →

Token pool owner trust model

Recommendations:

Use the same party for pool owner and instrument admin.
Decentralize the party across multiple nodes so no single node is a point of failure. See Digital Asset decentralization docs and Canton Foundation validators.

Registering on the Token Admin Registry

The Token Admin Registry maps each instrument to a single token pool. Registration is a three-step flow:

Propose an administrator — Instrument admin or CCIP owner calls ProposeAdministrator with a proposed admin party.
Accept the admin role — Proposed admin calls AcceptAdminRole.
Set the pool — Admin calls SetPool to link the instrument to the pool.

The admin role can be transferred via TransferAdminRole followed by AcceptAdminRole.

Deployment guides walk through TAR registration step by step:

BurnMint Token Pool Deployment
LockRelease Token Pool Deployment
Registry Issuer Guide (includes SetBurnMintFactory for Registry instruments)