This is the technical primer in a series on Canton's three-layer model. The hub piece, Decentralized custody and governance on Canton, explains what the model is and why it matters for teams building on the network. This piece goes into the implementation: the topology mappings the protocol actually uses, the keys behind each one, and the rules each layer enforces. If you have not read the hub yet, start there.
The three layers
Every party on Canton has three topology mappings. Each carries its own keys, its own format, and its own rules for when and how it can change.
Layer | Topology mapping | What it answers | Key type | Changes require |
|---|---|---|---|---|
Identity |
| Who is this party? Who owns the namespace? | Root key ( | Root key signature |
Authorization |
| Which key(s) can sign ledger transactions on behalf of this party? | Signing key ( | Root key signature, or namespace threshold for a decentralized party (to publish or rotate the mapping) |
Hosting |
| Which participant nodes run this party, what each is allowed to do, and at what confirmation threshold? | Participant node keys (internal) | Co-signed: root key (party side) + each host's node key (host side) |
None of these mappings is a substitute for another. A party with only the Identity layer cannot transact. One with Identity and Authorization but no Hosting mapping has no node bound to host it. One with all three but mismatched thresholds may have security properties the team did not intend. A high signing threshold paired with a permissive hosting layer, for example, still lets a single host commit transactions on its own, regardless of how strict the signing quorum is.
The three layers also live at different operational tempos. Namespace keys are cold, typically held offline and rarely brought online. Signing keys are warm, held by participant operators or external signers and used to authorize ledger transactions. Hosting permissions are a runtime concern: which participants run the party today, and what each is allowed to do.
The cardinal rule
The single most important property of this model: namespace keys sign topology, signing keys sign transactions. They never cross over.
Namespace keys sign topology. Signing keys sign transactions. Never the other way around.
SigningKeyUsage. A NamespaceOnly key cannot sign a ledger transaction. A ProtocolOnly key cannot sign a topology change. The system rejects the wrong combination during topology and transaction validation, based on the SigningKeyUsage metadata of the signing key.This matters for two reasons. First, the blast radius of any single key compromise is bounded by what that key was already authorized to do. A ProtocolOnly key, even if exposed, cannot be escalated into a change of the party's identity. A NamespaceOnly key, even if exposed, cannot move ledger state. Identity compromise and operational compromise become independent failure modes that can be mitigated separately. Second, namespace keys can be treated as cold-storage material with strong operational hygiene (HSMs, paper backups, hardware-isolated signers) without competing with the throughput requirements of routine signing.
In practice, this means an organization running a Canton party can keep namespace key custody fully separate from production signing infrastructure. The two never need to share a process, a network, or a hardware boundary.
Hosting permissions
The third layer, PartyToParticipant, carries more than the first two. It does not just record which nodes run a party. It also encodes what each node is allowed to do, and how many of them must agree before a transaction commits.
Each host gets one of three permission levels:
Permission | Can submit? | Can confirm? | Can read? |
|---|---|---|---|
| Yes | Yes | Yes |
| No | Yes | Yes |
| No | No | Yes |
A Submission host can initiate ledger transactions on behalf of the party. A Confirmation host cannot initiate, but validates transactions the party is a stakeholder in and contributes to the confirmation quorum. An Observation host can read the party's ledger state but plays no role in authorizing it.
For a party run by a single operator on a single node, the simplest setup is one host with Submission permission and a quorum of one. The host submits, the host confirms, and there is no quorum to clear. For multi-party governance, this concentrates authority in a single host, which is exactly what most multi-party projects on Canton are trying to avoid.
The fix: zero hosts with Submission, all hosts with Confirmation, and a quorum threshold greater than one. No single host can act unilaterally. To act on the party's behalf, the operators must produce a threshold-signed transaction via Canton's interactive submission flow, and the network's mediator must collect at least the threshold number of confirmations from the participating hosts before committing. Both layers, signing and hosting, must clear their thresholds independently. Either is enough to halt an unauthorized action.
Scaling to a decentralized party
Each of the three layers can run as a single-owner setup or as a quorum-based decentralized setup, independently per layer. You can run a centralized identity with a decentralized signing layer and a single-host setup, or any other combination, because the layers compose without interfering with each other.
Concept | Single-owner form | Decentralized form |
|---|---|---|
Namespace |
|
|
Signing | P2K threshold = 1, one key | P2K threshold = k, N keys |
Hosting | P2P threshold = 1, one host with | P2P threshold = k, N hosts with |
A fully decentralized party, like the one that governs CBTC on Canton today, runs all three layers in the right column: four independent operators, four component namespaces, four signing keys, four hosting nodes, with a 2-of-4 threshold at each layer. No single operator can rewrite the party's identity, sign on its behalf, or commit a transaction unilaterally.
Thresholds are tunable per layer. A team could run 4-of-4 on identity (unanimous consent for any change that goes through namespace authority), 2-of-4 on signing (with tolerance for two operators being unavailable), and 2-of-4 on hosting, or any other combination. Identity changes happen rarely and a high bar makes sense; signing happens constantly and benefits from quorum tolerance. The protocol does not force a uniform answer.
What this means at the implementation level
The hub piece covers what becomes possible at the model level. Two things are worth calling out at the implementation level. First, identity material and operational signing material can be administered by different teams, on different storage tiers, with different approval workflows, because Canton enforces the boundary cryptographically through SigningKeyUsage rather than through team discipline. Second, each threshold tunes independently per layer, so a team can match each one to the operational reality of its application instead of working from a fixed set of presets.
Next in this series
The next piece walks through how these three layers are instantiated in cbtc-network, the decentralized party that governs CBTC on Canton today: the topology mappings as they actually exist on the network, the threshold choices and the reasons behind them, and how the operators run the party in practice.
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.
Website | Twitter (X) | LinkedIn | Telegram