The hub, Decentralized custody and governance on Canton, sets out what the model is and why it matters. Part 3, Inside CBTC: The First Decentralized Party in Production on Canton, walks through how those three layers are instantiated for cbtc-network on Mainnet today. This piece zooms in on the day-to-day governance flow: how members exercise choices on CBTCGovernanceRules without re-running the threshold signing dance from Part 3, and why the hosting quorum keeps enforcing the party's authority on every transaction even when the signing keys are not consulted.
When you first look at how the CBTC governance system works, something seems off.
attestor1 is a distinct party on Canton. cbtc-network, the decentralized party that governs CBTC, is a different party entirely, with its authority distributed across four independent Canton participants and gated by a 2-of-4 threshold of ProtocolOnly signing keys held by those participants. And yet, when attestor1 exercises a governance choice on the CBTCGovernanceRules contract, the resulting transaction carries cbtc-network's authority. Sub-contracts get created. State transitions happen. The decentralized party's consent is present, but no threshold signature was produced at exercise time.
So where does that authority actually come from?
The answer is one of the more elegant patterns in Canton's authorization model, and understanding it matters for anyone building multi-party applications on the network.
The setup: a quorum-governed decentralized party
The configuration this piece refers to is the production one for cbtc-network: four independent operators, each running their own Canton participant node, with 2-of-4 thresholds at every topology layer. Part 3 walks through how those layers are mapped, the keys behind each layer, and the prepare/sign/execute flow. The short version is enough to follow what comes next.
Note that the threshold scheme discussed throughout this guide is the Canton-side ProtocolOnly signing scheme that authorizes transactions on Canton, not the Bitcoin-side FROST multisig that secures the CBTC reserve on Bitcoin. Those are two separate cryptographic systems that often get conflated.
cbtc-network is decentralized across four operators, each running their own Canton participant node. Every one of Canton's three identity layers is quorum-based:
Identity: a
DecentralizedNamespaceDefinitionover four component namespaces, each with its own namespace-only root key. Any topology change requires 2-of-4 component namespaces to sign.Authorization: a
PartyToKeyMappingregistering fourProtocolOnlysigning keys (one per host) tocbtc-network. Direct submissions bycbtc-networkitself, for example topology changes or other actions submitted on its own behalf, require 2-of-4 of these signatures via the interactive submission flow.Hosting: a
PartyToParticipantmapping where all four participants hostcbtc-networkwithConfirmationPermission. No single host holdsSubmission, so no one can issue ledger commands oncbtc-network's behalf unilaterally; direct submissions must go through the threshold-signed interactive submission flow.
When cbtc-network needs to act directly, for example during bootstrap or for topology changes like rotating hosts or adjusting thresholds, the flow is explicit: prepare a transaction, collect 2-of-4 threshold signatures via signBytes on each host's ProtocolOnly key, then execute via interactive_submission. Canton verifies the threshold, routes to the four confirmation hosts, and the mediator issues a positive verdict once the 2-of-4 hosting quorum is satisfied.
That works. But it's not how day-to-day governance actually operates.
The puzzle
Once the system is live, attestor1 can exercise choices like CBTCGovernanceRules_CreateProviderServiceRequest directly, without triggering that threshold signing dance. The transaction still produces effects that are authorized as if cbtc-network consented. No ProtocolOnly key was consulted.
If cbtc-network ordinarily needs 2-of-4 ProtocolOnly signatures to authorize anything it submits on its own behalf, how can a transaction that depends on its authority be committed without those signatures?
The mechanism: DAML signatories as standing delegation
The answer lies in how DAML's authorization model handles contract signatories.
When CBTCGovernanceRules was created, cbtc-network was included as a signatory. That required the full 2-of-4 threshold signing at creation time: the interactive submission dance, the required 2-of-4 ProtocolOnly key signatures, the mediator quorum, everything. The decentralized party gave its explicit, cryptographically verified consent to exist as a signatory on this contract.
Once that contract is on-ledger, something important changes. DAML's authorization rules allow choices on a contract to be controlled by parties other than the signatories. Any non-signatory party that the template designates as a controller of a choice can exercise that choice. When such a party does so, the resulting sub-transactions inherit the authority of the contract's signatories because the signatories already consented by being on the contract.
The CBTCGovernanceRules contract is, in effect, a standing delegation of cbtc-network's authority to the member parties who can exercise its choices. The decentralized party's consent isn't absent. It was given once, at creation, and is now embedded in the ledger state itself.
This is on-chain indirection: the decentralized party's authority is routed through the contract rather than through a fresh signature on every action.
What each Canton identity primitive actually does here
It helps to map exactly which primitives are active at which point:
Primitive | At contract creation | At choice exercise | Why |
|---|---|---|---|
| Indirectly: authorizes the | No | Topology keys never touch ledger transactions |
| Yes: 2-of-4 threshold signing produced | No: the member's own credentials are used; the decentralized party's consent is already on-ledger | Keys authorize fresh top-level submissions the party makes on its own behalf; a signatory is an existing ledger commitment |
| Yes: the creation transaction was confirmed by | Yes, every time | Any transaction where |
The short version: after the governance contract is created, the ProtocolOnly signing keys are no longer consulted for member-driven choices on it. The hosting quorum, by contrast, must confirm every transaction in which cbtc-network is a stakeholder.
Why confirmation is not optional
Even though no fresh ProtocolOnly signature is needed when a member exercises a governance choice, Canton's synchronizer still treats cbtc-network as a stakeholder of the governance contract. That has concrete consequences for every transaction that touches the contract or its sub-contracts.
The flow looks like this:
Routing. The submitting participant, whichever node hosts the exercising member, blinds the transaction and distributes the relevant views to each of
cbtc-network's four hosts.Validation. Each decentralized party host independently validates: does the choice exist on this contract, are the arguments well-formed, do DAML's authorization rules hold, does the resulting state transition make sense given its local ledger state?
Verdict. Each host sends its confirmation or rejection to the mediator.
Finalization. The mediator requires at least 2 approvals, the threshold set in the
PartyToParticipantmapping, before the transaction is committed.
If fewer than 2 decentralized party hosts confirm, the transaction is rejected. It doesn't matter that the member's own participant submitted it and would have been happy to proceed. The decentralized party's hosting quorum is the enforcement mechanism for its on-ledger commitments, and it applies universally. No exceptions.
It's worth keeping these distinct, because conflating them causes confusion:
Layer | Who authorizes | What it authorizes |
|---|---|---|
DAML (logical) | Signatories, controllers, as declared in the template | What ledger state transitions are permissible under the contract's rules |
Canton (physical) | Hosts (via the | Whether a permissible transition is actually committed to the ledger |
The governance contract handles the first layer: it defines what members can do and routes their actions through the decentralized party's standing authority. The hosting quorum handles the second: it ensures that no transition is committed without the decentralized party's nodes reaching consensus. Neither is sufficient on its own.
What this means in practice
Losing the ProtocolOnly signing keys does not break deployed governance contracts. Members can continue exercising existing choices; the decentralized party's signatory consent is already embedded in the ledger. What it does block is anything that requires cbtc-network to directly authorize the root action on its own behalf: creating new contracts where cbtc-network must authorize that root action, rotating hosts, adjusting thresholds, or any other topology change. All of these need fresh threshold signatures.
Losing one or two decentralized party hosts does not halt governance, because 2-of-4 still clears with two remaining hosts. Governance exercises proceed normally.
Losing three decentralized party hosts halts all governance activity. Not because authorization fails at the DAML level (the member's credentials are still valid and the contract's rules still hold), but because Canton cannot reach the confirmation threshold. The physical enforcement layer is the binding constraint.
Why this architecture matters for builders on Canton
The pattern described here, a signatory-based standing delegation enforced by a decentralized hosting quorum, is not specific to CBTC. It is a general approach to multi-party authorization on Canton, and it is reusable.
Any Canton application that needs multiple independent parties to govern shared state faces the same challenge: you want those parties to authorize the creation of a governance framework once, not re-sign every action the framework enables. On-chain indirection solves this cleanly. The decentralized party gives its consent at contract creation. From that point on, the hosting quorum is the enforcement mechanism: always present, never requiring fresh key material from the party itself.
For builders deploying on Canton who want to eliminate single points of control without sacrificing operational continuity, this is the model. The governance contract defines what is permitted. The hosting quorum decides what gets committed. Both layers operate on every transaction once they are in place, which is why they need to be designed in from the start.
Building something on Canton? Book a call with the BitSafe team and we'll walk through your use case, the decentralized party patterns we operate in production for CBTC, and how our DecParty tooling could fit your stack.
BitSafe builds decentralized, privacy-enabled infrastructure and compliant digital asset products on the Canton Network. As the team who brought Bitcoin to Canton, BitSafe's threshold-governed multi-sig infrastructure distributes custody and governance, eliminates single points of failure, and enables institutions and developers to launch trading venues, deploy vaults, and build compliant financial products across the ecosystem.