On the majority of blockchains, three different questions about a party get tangled together: who owns this party, who can sign for it, and who runs the infrastructure underneath. Some chains handle one or two of these cleanly; few handle all three. Application teams paper over the gap with multisigs and off-chain coordination. For institutional custody, settlement, or on-chain governance, that paper is too thin.
Canton handles the three separately at the protocol level. Each has its own keys, its own threshold, and a cryptographic boundary between it and the next. BitSafe runs the first production deployment of this model: CBTC, the first non-native asset on Canton, governed by a fully decentralized party since launch.
Why this matters now
Canton is past proof-of-concept. CBTC has been live since August 2025. New institutions are onboarding. Teams are deploying multi-party applications that need custody, settlement, and governance baked in at the foundation, not bolted on later.
The choices you make at this layer propagate up the rest of the stack. An application that calls itself decentralized but rests on a single identity key, or a single hosting node, is decentralized in name only. The cleaner the model going in, the less you have to retrofit later.
The three layers
Every party on Canton sits behind three independent topology layers. Each one answers a different question, with its own keys and its own threshold rules.
Layer | What it answers | Single-owner form | Decentralized form |
|---|---|---|---|
Identity | Who is this party, and who owns its namespace? | One root key | N component namespaces, each with its own owner, threshold k-of-N |
Authorization | Which keys can sign ledger transactions on behalf of this party? | One signing key | N signing keys, threshold k-of-N |
Hosting | Which participants host this party, what they're permitted to do, and what consensus is required for a transaction to commit? | One host with full submission rights | N hosts with confirmation rights, threshold k-of-N |
None of these is a substitute for another. Identity material is cold: held offline, almost never online. Signing material is warm: held by participant operators or external signers, used to authorize ledger transactions. Hosting is a runtime concern, about which nodes carry the party and what each is allowed to do on its behalf.
Each layer is configured independently. A team can pair a single-owner identity with a quorum-based signing layer and a quorum-based hosting setup, or any other combination. Thresholds are tunable per layer to match what the application actually needs.
What Canton makes possible
A few things become possible because of this separation:
Cryptographic separation between identity and operational signing. Canton enforces it at the key level. A key with authority over topology cannot sign a ledger transaction, and a signing key cannot rewrite the party's identity. This is not policy or convention; the protocol itself makes the substitution impossible.
Composable thresholds. Identity, signing, and hosting tune independently. Identity changes are rare and benefit from a high bar (unanimous consent is reasonable). Signing happens constantly and needs quorum tolerance for liveness. Hosting reflects whichever participants actually run the infrastructure.
Native multi-party governance. Quorum thresholds are baked into how Canton works, not bolted on as a coordination layer above. Decentralized governance is a property of the platform underneath, not an application-level concern you build on top.
Where BitSafe fits
BitSafe brought Bitcoin to Canton with CBTC, the first non-native asset on the network. CBTC is governed by a fully decentralized party with four independent operators, four component namespaces, four signing keys, four hosting nodes, and 2-of-4 thresholds across each layer. No single operator can rewrite the party's identity, sign on its behalf, or commit a transaction unilaterally. Today, that party authorizes every CBTC mint and redemption on the network, with no individual operator able to override the others.
The same three layers underpin anything else built on Canton with similar requirements. Decentralized custody, multi-party settlement, on-chain governance: all of them inherit this structure.
The deep dives
This is the opening piece. Three deep dives are forthcoming in the series:
Canton's three topology layers, explained. The technical primer. How each layer is implemented, what each topology mapping does, and how they compose under the hood.
Inside
cbtc-network. The reference implementation. How CBTC's decentralized party is set up end-to-end, with the actual topology, thresholds, and operational properties.The DAML signatory pattern. How on-chain governance authority composes on top of the three layers, so a decentralized party can authorize operations through DAML contracts rather than every operator co-signing every transaction.
Where this goes next
More applications are coming. As more teams ship on Canton, the three-layer model is the structure they will build on. BitSafe's job, and the ecosystem's, is to keep proving it works in production and to lower the bar for the next team.
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