How CBTC works

CBTC overview

The short version

CBTC represents Bitcoin on Canton Network. A mint starts with Bitcoin sent to a deposit address. The system verifies the deposit and creates the corresponding CBTC for the intended Canton party. A redemption consumes CBTC and releases Bitcoin to an approved destination. Transfers between Canton parties use Canton contracts and do not move the underlying Bitcoin for each transfer.

The system has two connected ledgers

• Bitcoin: holds the Bitcoin that backs CBTC and records deposits and redemption transactions.
• Canton Network: records CBTC holdings, transfers, account workflows, and the parties authorized to act.

The integration layer links a Bitcoin event to its corresponding Canton workflow. It must prevent duplicate processing and preserve enough identifiers for reconciliation.

Mint lifecycle

1. The Canton party obtains the required credential and current deposit-account rules.
2. The party creates a deposit account.
3. The approved service returns a Bitcoin deposit address associated with that account.
4. The depositor verifies the network and sends Bitcoin to the address.
5. The system detects the transaction and waits for the approved confirmation state.
6. Independent Attestor Network participants verify the eligible Bitcoin event.
7. The approved threshold authorizes the mint workflow.
8. CBTC is created for the intended Canton party.
9. The Bitcoin transaction, account, attestation, Canton update, and resulting holding are reconciled.

Transfer lifecycle

A Canton transfer does not redeem Bitcoin. The sender creates a transfer offer for a receiver. The receiver inspects and accepts the intended offer unless an approved preapproval flow applies. Canton archives or updates the relevant contracts and creates the receiver’s new holding state.

Redemption lifecycle

1. The party validates a Bitcoin destination.
2. The party creates or selects a withdrawal account using current rules.
3. The application selects sufficient CBTC holdings.
4. The party submits the redemption.
5. The Canton contract flow consumes the applicable CBTC state.
6. The approved Bitcoin signing workflow creates and broadcasts the redemption transaction.
7. The application tracks completion on Bitcoin and Canton.
8. The records are reconciled to one request.

Who does what

Role	Responsibility	Boundary
CBTC holder	Owns Canton holdings and initiates supported actions	Can act only with the party’s authorization
BitSafe services	Coordinate account and integration workflows	Cannot be described as able to move reserves unilaterally
Attestor Network	Verifies eligible Bitcoin events and participates in threshold authorization	No single operator is sufficient
Canton participant	Hosts the party and submits or observes authorized Canton actions	Visibility follows Canton entitlements
Bitcoin network	Records deposits and redemption transactions	Confirmation and fee behavior are external to Canton

Backing and verification

CBTC is intended to remain backed 1:1 by Bitcoin. Public documentation should distinguish:

• Bitcoin reserves visible on Bitcoin.
• CBTC supply and contract state visible to entitled Canton parties.
• Proof of Reserve evidence and its exact coverage.
• Operational reconciliation performed by the system.

Failure boundaries

A workflow can pause because of Bitcoin confirmation delays, service availability, Canton connectivity, authentication, incompatible packages, insufficient approvals, or an ambiguous prior submission. Clients must query authoritative state before retrying.

Related guides

• Mint CBTC
• Redeem CBTC
• Transfer and receive CBTC
• CBTC architecture and trust boundaries

Technical sources

• cbtc-lib repository
• canton-lib repository

Next step

👉 Choose an operation: Choose a CBTC path.