Architecture and trust boundaries
Architecture at a glance
CBTC connects Bitcoin custody and event verification with private Canton contract workflows. This page owns the component map and trust boundaries. Lifecycle steps belong in How CBTC works; control requirements belong in CBTC security.
Component map
Bitcoin addresses and transactions
Receive eligible deposits and deliver approved redemptions
Bitcoin transaction, fee, and confirmation behavior
Attestor Network
Verify eligible events and participate in threshold authorization
Independent operation, policy, and signing shares
CBTC workflow services
Associate accounts and events, coordinate workflows, and reconcile state
Authentication, availability, and correct state handling
Canton participants and parties
Host parties, contracts, and authorized commands
Canton identity, rights, topology, and privacy
CBTC Daml packages
Define holdings, transfers, accounts, credentials, and administrative behavior
Approved package versions and contract authorization
Client libraries and applications
Expose supported workflows and submit authorized requests
Pinned releases, credentials, validation, and retries
Proof of Reserve and reconciliation
Provide scoped evidence about reserves and system state
Completeness, freshness, source integrity, and stated limitations
Trust boundaries
Bitcoin custody
Underlying Bitcoin uses FROST threshold signing across independent Attestor Network operators. The threshold is configurable, and the operator set can change. Verify current operating details through the maintained security reference.
Attestor Network
Event verification and signing authorization are separate responsibilities. No single operator should be presented as sufficient to authorize a custody action. The detailed signing model belongs in CBTC Attestor Network and FROST.
Canton
Canton records CBTC contract state and applies authorization through parties, participant rights, package logic, and topology. Configurable sub-transaction privacy limits contract visibility to entitled parties; it does not hide Bitcoin transactions.
Integration services
Clients authenticate separately to Canton and approved CBTC services. They must validate networks, parties, addresses, package compatibility, and authoritative state before retrying an ambiguous request.
Evidence
Proof of Reserve demonstrates only the evidence and observation scope documented on CBTC Proof of Reserve. It does not prove every application, custody, operational, or redemption property.
Architecture limits
This architecture does not by itself guarantee instant Bitcoin confirmation, every external service’s availability, correct integrator configuration, protection from an authorized request containing the wrong destination, or complete coverage by one evidence source.
Technical sources
Related pages
Next step
👉 Review the control model: CBTC security.
Last updated