Canton is a Layer 1 network purpose-built for regulated finance - it's a public blockchain but with privacy controls proven to work at scale for institutional flows. It is designed as a “network of networks” so that institutions can run private applications while still settling atomically with other participants when needed.
Canton Network Architecture Basics
At its core, Canton replaces the idea of a single global ledger with multiple subnets connected through a shared coordination layer.
- Subnets (domains): Sovereign, run environments where institutional application operators can establish their own permissioning and governance. Applications are built with Daml smart contracts, which provide highly configurable privacy and workflows, with out-of-the-box logic for wholesale financial use cases (for example, issuance, settlement, or collateral management).
- Global synchronizer: A shared, decentralized domain and coordination layer operated by super validators that application providers can also build on. It sequences encrypted messages and ensures atomic cross-domain settlement—meaning multi-leg transactions either fully succeed or fully fail—without ever decrypting the payload.
Conceptually, Canton behaves like a UTXO-style chain (unspent transaction output). Its utility token, Canton Coin, runs as a decentrally-operated and public application on the Global Synchronizer. State transitions are grouped into “rounds” that are functionally similar to blocks. Rounds occur on a regular cadence, every 10 minutes, providing a clear ordering of Canton Coin transactions for participants.
PartyIDs, Wallets, and Multi-Tenancy
In Canton, what most blockchains call a “wallet” is represented by a PartyID. A PartyID is a cryptographic identity that can hold rights in contracts, sign transactions, and participate in workflows.
Every PartyID is hosted on a participant node (a Validator). A single participant node can host thousands of PartyIDs with strong isolation, enabling custodians, service providers, and infrastructure operators to serve multiple unrelated clients on shared hardware.
This multi-tenancy is achieved by:
- Separating each PartyID’s key management from the general node infrastructure.
- Using end-to-end encryption for all transaction data between the PartyIDs involved in a workflow.
The result is that each client or business line can be treated as its own secure “tenant”, even when running on common infrastructure.
Privacy-by-Design in Canton
Privacy is not an add-on in Canton; it is the default operating mode. Only the parties explicitly named on a Daml contract—or those given observer rights—can see the contents of that contract and its associated transactions.
- Participant nodes for the relevant PartyIDs decrypt and process the transaction.
- Super validators in the global synchronizer never see raw transaction data; they only handle encrypted blobs, timestamps, and ordering metadata.
For example, two institutions transacting in a stablecoin on Canton can keep their activity visible only to themselves and designated observers, with no leakage to the wider network. This “need-to-know” distribution of data is what allows Canton to support regulated use cases that would be impossible on fully transparent public chains.
Burn-and-Mint Equilibrium for CC
Canton’s native token, CC, follows a burn-and-mint equilibrium model that ties token dynamics to real network usage:
- There is a 100 billion CC issuance ceiling for the first 10 years, with no pre-mine.
- Fees, such as Global Synchronizer traffic fees, are paid in CC and then burned, permanently reducing circulating supply.
- New CC is minted as liveness rewards for validators, weighting for super validators, and reward shares for applications that drive activity.
While the protocol technically allows an unlimited theoretical supply over the very long term, the combination of fee burning and controlled minting is designed so that effective supply stabilizes well below the initial 100 billion ceiling over the first decade. Utility and transaction volume are the primary drivers of CC demand.
Why Canton Fits Regulated Real-World Assets
Canton combines three properties that are difficult to achieve together on traditional blockchains:
- Private execution – Only relevant parties see contract state and transaction details.
- Provable atomic interoperability – Cross-entity workflows (for example, delivery-versus-payment or collateral swaps) settle as a single, all-or-nothing transaction across domains.
- Independent sovereignty – Each institution or consortium can operate its own domain with its own policies, while still connecting to others when needed.
This makes Canton particularly well suited for tokenized funds, syndicated loans, structured products, and 24/7 collateral mobility—areas where regulators expect both strong controls and clear, verifiable behavior.
Example: Tokenized Fund Trade With a Shared Custodian
Say a global custodian, Acme Bank, runs a Canton participant node that hosts separate PartyIDs for “Fund A,” “Fund B,” and “Custody Ops.” Each fund PartyID represents a different client fund on that same node.
- A sell order is placed by Fund A to redeem units in a tokenized money‑market fund, and a buy order is placed by Fund B to purchase those units.
- The trading application for these orders runs on another participant node (for example, at a broker or platform provider) and talks to both fund PartyIDs on the custodian node.
- When the trade matches, a single Canton transaction moves the fund units from Fund A’s PartyID to Fund B’s PartyID and updates the corresponding cash balances, even though:
- Both Fund A and Fund B sit on the same custodian node as separate PartyIDs.
- The trading and cash applications may be running on other nodes and even other domains.
- Only the PartyIDs directly involved in the contracts (Fund A, Fund B, Custody Ops, and any configured observers such as a regulator) can see the full transaction details.
- The global synchronizer sequences and settles the transaction atomically across the relevant domains, but never sees the underlying contract data.
Check out the other blogs in this series:
