This is Part 3 in a series on Canton's three-layer model. The hub, Decentralized custody and governance on Canton, sets out what the model is and why it matters. Part 2, Canton's three topology layers, explained, walks through the topology mappings in the abstract: identity, authorization, hosting. This piece grounds those primitives in a production deployment. The subject is cbtc-network, the decentralized party that governs CBTC on Canton today. If you have not read the earlier pieces, start with the hub.
The party
cbtc-network is operated by four independent organizations on Mainnet today. Each runs its own Canton participant node, holds its own keys, and contributes one share of authority at each of the three topology layers.
No keystores are shared between operators. No participant runs with unilateral authority over the party. Every action that commits to the ledger reaches a 2-of-4 quorum at each layer that applies to it.
The three layers, instantiated
Layer | Topology mapping | How it is instantiated for | Threshold |
|---|---|---|---|
Identity |
| Four independent component namespaces, one per operator, each with its own | 2-of-4 component namespaces must sign any topology change |
Authorization |
| Four | 2-of-4 signatures required on every transaction submitted by the party itself |
Hosting |
| All four participants host | 2-of-4 confirmation quorum on every transaction in which |
The three rows describe the same party from three angles. The identity row says who the party is. The authorization row says which keys can speak for it. The hosting row says which nodes run it, what each is allowed to do, and how many must agree before a transaction commits.
The keys, by role
Key |
| What it signs | Where it lives |
|---|---|---|---|
Per-operator namespace keys (four total) |
| Topology transactions: onboarding, key rotation, host changes, threshold changes | One per operator, in its own participant's keystore |
Per-operator DAML signing keys (four total) |
| Ledger transactions submitted by | One per operator, in its own participant's keystore |
The SigningKeyUsage flag is enforced by the runtime, not by operator discipline. A NamespaceOnly key cannot sign a ledger transaction. A ProtocolOnly key cannot sign a topology change. Canton rejects the wrong combination at validation time, based on the metadata attached to the key.
The practical consequence: namespace material can be administered as cold material, with hardware isolation and offline approval workflows, without bottlenecking transaction throughput. The signing keys can stay warm on the participant without widening the blast radius of a compromise into the party's identity.
A transaction, end to end
When cbtc-network itself submits a transaction, for example during bootstrap, during a topology change, or for any action where the party is the direct submitter, the flow has three steps.
Prepare. One participant calls
participant.ledger_api.interactive_submission.prepare(actAs = Seq(cbtcNetwork), ...). The call returns a prepared transaction plus a canonical hash.Sign. Each operator signs the hash on its own host via
cr.privateCrypto.signBytes(hash, fingerprint, SigningKeyUsage.ProtocolOnly). Two signatures clear thePartyToKeyMappingthreshold; additional signatures up to four are permitted and are often produced in practice for redundancy.Execute. Any participant calls
interactive_submission.execute(preparedTx, Map(cbtcNetwork -> Seq(sig1, sig2)), ...). Canton verifies the signatures against thePartyToKeyMapping, routes the transaction to all three hosts for confirmation, and the mediator commits once 2-of-3 confirmations come back.
Two thresholds clear sequentially within a single transaction: the signing quorum at submission time, and the hosting quorum at confirmation time. Both belong to cbtc-network, but they are enforced independently and require different key material to satisfy. A submitter with valid signing signatures still cannot commit unilaterally; the hosting quorum is the second gate.
Why 2-of-4 at every layer
The choice of 2-of-4 at each layer is not arbitrary. It is a configuration that meets two criteria simultaneously: no single operator can act for the party on its own, and the party stays available even if two operators are unreachable.
A 1-of-4 setup would allow any operator to act unilaterally and removes the point of having four. A 4-of-4 setup would halt the party the moment any one operator is unavailable, which is not acceptable for a governance party that has to keep authorizing CBTC operations. 2-of-4 sits at an operating point where unilateral action is impossible and the party tolerates up to two operators being unavailable simultaneously.
The same logic applies at each layer for now. Identity changes, signing, and hosting each get the same quorum because the operator set is the same and the failure modes the team is willing to tolerate are the same.
Tuning the thresholds independently
The three thresholds are independent in the protocol, even though cbtc-network runs them at the same value today. Each lives in its own topology mapping and is changed through that mapping, subject to the namespace quorum approving the change.
That gives the operators room to tune in the future. Identity changes happen rarely, and a stricter setting such as 3-of-4 or 4-of-4 is defensible for them: near-unanimous or unanimous consent for any change that goes through namespace authority. Signing happens on every transaction and benefits from quorum tolerance, so a 2-of-4 there is the more practical setting. Hosting can be set separately again, depending on how much availability the team is willing to trade for a stricter confirmation rule. None of these decisions is forced by the protocol.
How the operators run it in practice
A few operational properties fall out of the design and are worth naming explicitly.
Keystores are not shared. Each operator's namespace key and signing key live in that operator's own participant keystore. There is no shared HSM, no shared signing service, and no operator that can produce another operator's signature.
Signing is asynchronous. The interactive submission flow allows each operator to sign the prepared hash on its own host, in its own time window, without a synchronous handoff. Signatures are aggregated by whichever participant executes the transaction.
Bootstrap was a one-time, threshold-signed event. The initial
PartyToKeyMappingandPartyToParticipantmappings forcbtc-networkwere themselves authorized by the namespace quorum at party creation. From that point on, the party's identity is self-enforcing on the network.Day-to-day governance does not consult the signing keys for every action. Most governance choices on
CBTCGovernanceRulesare exercised by members (such asattestor1), not bycbtc-networkitself. That pattern, on-chain indirection through DAML signatories, is the subject of the next piece in this series.
Building a decentralized party on Canton, or weighing whether to? Book a call with the BitSafe team and we'll walk through your topology choices, the threshold trade-offs we make in production for CBTC, and how our DecParty tooling could fit your stack.
Next in this series
The fourth piece, How CBTC governance works without re-signing every action, explains the DAML signatory pattern that the governance contract uses. It covers why a threshold-signed creation of CBTCGovernanceRules lets members exercise governance choices without producing a fresh 2-of-4 signature on every action, and why the hosting quorum is the layer that keeps enforcing the party's authority on every transaction even when the signing keys are not consulted.
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.