1. Executive Summary
What is Canton
Canton is positioned as a “network of networks” for finance: a way to let institutions run privacy-preserving DLT applications while still enabling atomic, cross-application workflows via shared synchronization infrastructure. The Canton protocol is a Daml-based interoperability runtime that creates a “virtual global ledger” without a single globally replicated state.
Institutions have repeatedly hit three blockers with both public chains and earlier permissioned ledgers:
-
Privacy + selective disclosure at the sub-transaction level (necessary for regulated markets).
-
Operationally credible interoperability (not “bridge” risk, not global data leakage).
-
Incremental adoption path rather than “big-bang” platform migrations.
Canton’s architecture directly targets those blockers by (i) partitioned visibility, (ii) domain-based synchronization, and (iii) optional shared “Global Synchronizer” interoperability service.
Cantonʻs operational details
-
Core technical claim: Canton avoids a single global consensus over all state by using synchronization domains and participant nodes; parties only store/validate what they need, enabling privacy and parallelism.
-
Interoperability claim: The Global Synchronizer is presented as a decentralized ordering/commit service operated by multiple Super Validators with a 2/3 threshold for official outputs (BFT-style).
-
Governance claim: Governance/oversight of the Global Synchronizer is routed through a foundation structure (membership is permissioned; Super Validator participation is vetted).
-
Adoption signal (bounded): The Tie covers activity/participants for the Global Synchronizer, but it does not directly evidence volumes inside private Canton domains.
Cantonʻs privacy features
In a public blockchain, transaction data is typically broadcast to every node in the network to be validated. In contrast, Canton uses a “need-to-know” privacy model that keeps business data inside the stakeholdersʻ Participant Nodes while exposing only what is necessary to synchronize transactions.
1. Stakeholder-Based Privacy (Daml)
Canton is built using Daml, a smart contract language designed around the concept of “stakeholders.”
-
How it works: In a Daml contract, you explicitly define who has the right to see the data (Signatories and Observers).
-
The Result: If you are not a party to a transaction, the data physically never reaches your node. This avoids the “Global Shared Ledger” leakage problem where competitors can infer flows, even if the data is pseudonymized.
2. Separation of “Content” from “Ordering”
Canton separates contract execution from transaction ordering:
-
Participant Nodes: Owned by the institution (e.g., a bank). It stores full, unencrypted contract data and performs transaction validation.
-
The Sequencer (Domain): Orders transactions to prevent double-spending.
-
Privacy Feature: The Sequencer only sees encrypted metadata and hashes. It knows that something happened and in what order, but not the trade terms or the contract contents.
3. Sub-Transaction Privacy
Canton allows complex, multi-party transactions to be broken into smaller private pieces.
-
If a transaction involves three parties (Bank A, Bank B, and a Central Bank), Bank A and Bank B can exchange private details that the Central Bank does not need.
-
The system preservers atomicity (all-or-nothing) without requiring every stakeholder to see every “sub-action.”
4. Private Interoperability (the “Virtual” Ledger)
Canton enables cross-domain transactions while keeping privacy boundaries intact.
-
An asset on Domain A (e.g., a private equity fund) can be swapped for a digital currency on Domain B (e.g., a CBDC) atomically.
-
Even domainʻs internal state remains private: the cash operator does not see the fundʻs cap table, and the fund operator does not see the bankʻs cash ledger.
5. Regulatory Compliance and Auditability
While Canton is private to the public, it is not anonymous-by-design.
-
Selective Disclosure: Because privacy is controlled by the smart contract, a regulator can be added as an Observer at the contract level.
-
This can provide real-time read-only visibility for AML/KYC or supervisory needs without exposing data to the makret.
6. Protection Against Traffic Analysis
Even with encrypted payloads, metadata can leak information through the frequency of communication between nodes and the message size. Canton uses techniques to mask these patterns, ensuring that even metadata doesn’t leak sensitive business intelligence to competitors.
Summary comparison
| Feature | Public Blockchains (e.g., Ethereum) | Canton Network |
|---|---|---|
| Data Visibility | Public (everyone sees the data/hash) | Need-to-know (only participants see data) |
| Validation | Every node validates every transaction | Only affected participants validate |
| Sequencer Access | Can see transaction details | Blinded (sees encrypted hashes/metadata) |
| Regulatory View | Hard to implement selectively | Built-in via “Observer” roles |
Major risks & open questions
-
Visibility gap: If production activity remains largely inside private domains, outsiders (and even many members) may have limited ability to verify network utility beyond the Global Synchronizer.
-
Complex trust surface: Security depends on correct behavior across participant nodes, domain operators, and (optionally) Global Synchronizer operators—broader operational risk than a single FMI or a single ledger.
-
Token/fee design credibility: Canton Coin is described as a utility token for synchronization traffic fees and incentives, but institutional willingness to hold/use it at scale (and compliance treatment across jurisdictions) remains a key adoption uncertainty.
2. Canton Network Overview
Core purpose & design goals
Canton Network is designed to address a specific coordination problem in institutional finance: enabling legally binding, multi-party workflows to execute across organizations without requiring a single shared ledger or broad data disclosure.
Canton acts as a connective layer that:
- Enables composable workflows across organizations with strong authorization/privacy semantics via Daml and Canton runtime.
- Replaces brittle point-to-point integration with standardized smart-contract-driven workflow composition.
- Supports federation of permissioned domains “at no interoperability cost” when parties share at least one common domain for a transaction.
The design prioritizes privacy-by-construction, deterministic finality, and incremental adoption, allowing institutions to retain control over data, operations, and governance while still achieving interoperability.
Market participants
-
Application Users (Participants) - Enterprises (banks, asset managers, custodians, clearing houses) operating private participant node. They create/authorize transactions via applications; their sensitive data remains inside their nodes.
-
Participant Nodes - Private nodes operated by each enterprise. They execute Daml deterministically, validate authorization/contract rules, maintain a local state view, and submit transaction messages to synchronizers for ordering and finality.
-
Domains - Individual Canton networks where parties transact. Domains provide synchronization that prevents double-spending and ensures consistent ordering, while keeping contract contents private.
A Domain defines:
- The Rules: who can join the sub-network.
- The Ordering: assigns a single sequence that resolves conflicts (e.g., prevents spending the same asset twice).
- The Connectivity: routes encrypted messages between participants.
-
Domain Operators (Sequencers) - Single-entity or consortium operators running domains. They provide sequencing/timestamping and message delivery, but do not execute smart contract logic or see private contract data.
-
Super Validators - Canton Network-approved operators of the Global Synchronizer that run BFT consensus. They do not validate application logic or re-execute Daml transactions.
Super Validators are responsible for the following:
- sequencing messages
- timestamping transactions
- validation of Canton Coin / Amulet transfers
- approve governance actions
-
Global Synchronizer (Super Validators) - A shared decentralized, interoperability service operated by Super Validators. It is used for:
- cross-chain transactions
- atomicity across applications / subnets
- any Canton Coin / Amulet payments
Target users
Regulated financial institutions building applications for collateral, repo, securities lending, fund tokenization, derivatives margining—workflows that demand privacy, audit trails, and multi-party coordination.
Participant Nodes
Participant Nodes can be connected to multiple domains at once, allowing a single institution to coordinate multi-asset workflows across domains.
The Scenario: Imagine a bank (Bank A) wants to use its Cash (from the Central Bank Domain) to buy Gold (from the Digital Gold Domain).
- Bank A’s node queries the Gold Domain to confirm the gold is available.
- Bank A’s node queries the Cash Domain to confirm the money is available.
- Canton executes an atomic swap so cash moves on the Cash Domain at the same time gold moves on the Gold Domain.
- If one side fails, the whole transaction is cancelled.
The Privacy Result: The Central Bank sees that Bank A spent cash, but cannot see it was used for gold. The Gold Domain sees gold moved, but cannot see the paying cash account or payment terms.
Domain Operators
Canton is designed to allow different entities run different domains based on the use case:
- Individual Enterprises (Private/Club Domains)
A large bank (e.g., Goldman Sachs or J.P. Morgan) might run its own domain to facilitate transactions between its global branches or for selected clients.
- Why? Banks want total control over who enters the environment, hardware performance, and operational policy.
- Industry Consortia (Shared Utility)
A group of financial institutions can co-run a domain (e.g., a shared repo market domain).
- Example: A group of banks create a “Repo Market Domain” to handle overnight lending between each other while sharing the domain cost/governance.
- Financial Market Infrastructures (FMIs)
Central Securities Depositories (CSDs), exchanges (e.g., the ASX or Deutsche Börse), and other FMIs can operate domains as market rails.
- Why? They already operate trusted coordination services and by running a Canton domain, they can provide the tokenized workflows for the entire market to trade assets.
- Governments and Central Banks
A Central Bank can run a domain for a Central Bank Digital Currency (CBDC) ledger.
- Why? Sovereign control over sequencing and monetary operations, with permissioned bank connectivity.
Global Synchronizer
The Global Synchronizer is a shared domain operated by Super Validators. Its function is to provide a neutral interoperability point and shared ordering finality for workflows that must cross domains or use Canton Coin / Amulet.
-
The Directory Service: A shared “phonebook” for identity/address discovery and certificate verification. If Bank A wants to trade with Bank B, their nodes look to the Global Synchronizerʻs Directory Service to find each other’s addresses and verify their identity certificates.
-
The Consensus Engine: Super Validators use a Byzantine Fault Tolerant (BFT) consensus mechanism; as long as a super-majority (~ 2/3) remains honest, the network remains secure and accurate.
-
Cross-Domain Coordination: When a transaction moves an asset from a “Private Bank Domain” to a “Public Exchange Domain,” the Global Synchronizer provides the final timestamp and proof that the transfer happened correctly across the entire ecosystem.
The Global Synchronizer’s most important job in finality is preventing double-spending across coordinated workflows.
Example: Bank A tries to send the same $100 to Bank B and Bank C simultaneously.
-
Both transactions hit the Global Synchronizer.
-
Super Validators order the transactions (e.g., the transaction to Bank B is #101 and the one to Bank C is #102).
-
When the Participant Nodes validate #102, they detect that $100 was already consumed by #101.
-
The Mediator, a logical service operated by the Super Validators, issues a Rollback for #102.
Super Validators
- Consensus
The Super Validators’ role in consensus is limited to:
-
Ordering (Sequencing): Agreeing that “Transaction A happened before Transaction B.”
-
Uniqueness: Ensuring the same state is not concurrently consumed twice (double-spend prevention at the synchronization layer).
-
Availability: Keeping the Global Synchronizer operational and responsive to requests from participant nodes.
Because of Canton’s privacy model, Super Validators reach consensus on encrypted/hashes data and agree on the ordering without ever knowing transaction contents.
- Governance
Super Validators also act as a governance body for shared services. Their roles include:
-
Membership Admission: Voting on new institutions that can join the network as participants/validators (permissioned membership).
-
Protocol Upgrades: Coordinating network upgrades that affect shared infrastructure.
-
Fee Structures: Setting cost parameters for the shared synchronizer services.
-
Conflict Resolution: Provides a framework for resolving technical or operational disputes within the network.
3. Market Context: Institutional Distributed Ledger Technology (DLT)
Where Canton fits in institutional market infrastructure
Canton targets a layer of financial infrastructure that has proven difficult to modernize: cross-firm workflow coordination across post-trade, collateral, margin, and asset servicing processes that span multiple institutions and market infrastructures. This is the layer where operational, legal, and counterparty risk concentrates.
Historically, this layer has been addressed through a combination of bilateral integrations, centralized utilities, and message-based coordination (e.g., SWIFT-style workflows). While these approaches scale organizationally, they struggle to provide atomicity across firms, real-time state synchronization, and fine-grained privacy without reintroducing reconciliation or manual intervention.
Applications and Use Cases
Relationship to FMIs and post-trade systems
The Canton Network has positioned itself as the coordination infrastructure that allows Financial Market Infrastructure (FMIs)—central securities depositories, clearing houses, payment systems—to interoperate as potential domain operators or counterpart domains within the network.
Canton-related pilots include:
-
Depository Trust & Clearing Corporation (DTCC) - Tokenized Assets: The DTCC will tokenize a subset of the U.S. Treasury securities custodied at the Depository Trust Company (DTC) on the Canton Network for use as collateral.
-
Euroclear - Collateral Mobility Pilot: Euroclear, one of the worldʻs largest international Central Securities Depositories (ICSDs), used the Canton network to transfer Gilts, Eurobonds, and Gold between its registry and trader domains enabling 24/7 collateral mobility.
-
Hong Kong Exchanges and Clearing (HKEX) - Synapse: HKEX launched Synapse, a settlement platform built on Daml, to streamline post-trade workflows of mainland Chinese stocks.
-
Deutsche Borse Group (Clearstream) - D7 Platform: Clearstream, Deutsche Borseʻs post-trade arm, launched the D7 platform to issue digital securities (e.g. structured products, commercial paper) that can be used as collateral with other Canton-network banks.
-
Australian Securities Exchange (ASX) - CHESS Replacement: The ASX is replacing its existing clearing and settlement system, CHESS, with a DLT-based solution using Daml.
-
Goldman Sachs - GS DAP: Goldmans Sachs launched GS DAP on the Canton Network in 2023. Goldman Sachs used the platform to issue 100 million Eurodollar digital bond for the European Investment Bank (EIB).
Regulatory and operational context
From a regulatory perspective, Canton aligns with several long-standing supervisory priorities—data minimization, auditability, identity-based participation, and clear operational accountability—while introducing new questions around shared infrastructure governance and failure modes.
Regulators are more likely to focus on:
-
Operational resilience: who operates participant nodes, domains, and shared synchronizers, and under what obligations.
-
Governance enforceability: how upgrades, incident response, and membership decisions are made and contested.
-
Legal finality and dispute resolution: especially for workflows that span multiple domains or FMIs.
Canton’s market positioning therefore depends not only on technical capability, but on whether its federated coordination model can demonstrate reliability, neutrality, and clear accountability at scale—attributes traditionally associated with established market infrastructure.
4. Architecture & Technical Design
High-level architecture: Daml
Daml provides built-in authorization and privacy semantics; Canton is the distributed runtime implementing these models and producing hierarchical transactions. Daml uses a contract model where developers define Templates for digital contracts.
A Daml contract is an immutable object that exists on the ledger until it is “archived” (consumed). It focuses on three questions:
-
Who are the parties involved? (Signatories)
-
What rights do they have? (Choices)
-
What obligations do they carry? (Agreement)
Daml vs. Solidity: Key Differences
| Feature | Solidity (Ethereum) | Daml (Canton) |
|---|---|---|
| Model | Account-Based: A global state updated by functions. | Contract-Based: Similar to UTXO (Bitcoin), where contracts are created and consumed. |
| Privacy | Public by Default: Everyone sees all data/code. | Private by Default: Only signatories and observers see the data. |
| Language Type | Imperative (Object-oriented style). | Functional (Based on Haskell). |
| Execution | Every node on the network runs the code. | Only the affected parties’ nodes run the code. |
| Security | Re-entrancy attacks and integer overflows are common risks. | Built-in formal verification; prevents most common smart contract hacks by design. |
| “The Ledger” | One giant, shared global ledger. | A “Virtual” ledger made of many private data silos. |
Key Daml Actions
Actions define how the ledger state changes.
-
create - Instantiates a new contract on the ledger (authority of all signatories).
-
exercise - Triggers a Choice on an existing contract (primary mechanism for business logic). Every state change on the ledger is essentially an exercise call.
-
fetch - Retrieves a contract from the ledger if the party is a stakeholder.
-
archive - Consumes a contract so it can no longer be used (often paired with create).
-
signatory - Defines which parties must agree to the contractʻs existence. If a party is a signatory, they are legally / technially bound by it.
-
observer - Defines who can see the contract without control rights.
-
ensure - A predicate that must be true for a contract to be valid.
Technical Limits of a Transaction
- Throughput (TPS)
-
Canton Limits: Because only stakeholders execute transactions, throughput bottlenecks are domain- and participant-specific rather than global. A single domain can scale to handle thousands of transactions per second (TPS).
-
Scaling: Additional domains can be spun up to avoid single-domain congestion, subject to governance and operational coordination. There is no theoretical upper limit to the total network capacity.
- Latency (Finality)
- Deterministic Finality: Usually achieved in 1 to 2 seconds. This is the time it takes for a message to hit the Sequencer, be ordered, and for the Mediator to return a Verdict.
- Transaction Size (Payload)
-
Sequencer Limits: Sequencers typically enforce max message sizes; payload handling depends on what is carried versus referenced.
-
Privacy Limit: Since ordering operates over encrypted envelopes/hashes, large business payloads can be handled without exposing contents to the sequencer or slowing down the ordering process.
- Logic Complexity (The “Stack”)
-
No “Gas” Out-of-Memory: Daml does not use gas the way that EVM does. Daml transactions are limited by the Maximum Interpretation Time. The Maximum Interpretation Time is practically limited by the Domain’s Decision Time (usually 60–120 seconds). However, for a standard financial transaction (like a bond settlement or a swap), the actual interpretation happens in under 100 milliseconds.
If a transaction is so complex that it takes too long for a Participant Node to calculate the result (risking a timeout in the sequencing window), it will be rejected.
- Stakeholder Limits
- While there is no hard-coded limit on the number of observers/signatories on a single contract, performance degrades if a single contract has thousands of signatories, as the node must collect and verify many digital signatures simultaneously.
5. Consensus & Validation Model
Canton uses a decoupled consensus model, separating message ordering from transaction validation.
1. The Ordering Layer (Sequencing)
A consortium of Super Validators use a Byzantine Fault Tolerant (BFT) protocol to agree on a single linear sequence of encrypted transaction envelopes. Super Validators do not see the envelope contents; and can only agree on time and order.
Trust Assumption: a super-majority (2/3) of the Super Validators will not collude to reorder or drop transactions.
2. The Validation Layer (Local Consensus)
Only stakeholders of the contract are privy to the transaction details and validate the transaction. Participant Nodes involved in the transaction receive ordered messages, decrypt the transactions, and run the Daml interpreter to confirm the transaction follows contract rules.
Trust Assumption: participants trust the cryptography and the correctness of Daml contract logic.
3. The Mediator
The domain Mediator aggregates stakeholder votes and must receive unanimouse “Approve” votes from all the Participant Nodes in order to issue a “Commit Verdict”. Once a “Commit Verdict” is issued, there is zero change of a chain reorg. If there is less than 100% agreement amongst the Participant Nodes, the transaction will fail and the Mediator issues a “Rollback”.
What is a Rollback
When the Mediator issues a Rollback:
-
Message Broadcast: The Mediator sends the “Rollback” message to all relevant participants.
-
No State Change: The Participant Nodes (Bank A and Bank C) discard the draft state changes.
-
Contract Unlocking: Any pending locks are released; if a double-spend is detected, the already-consumed state remains archived.
-
Immutability: The attempted and then rolled back transaction is recorded as an ordered event by the Sequencer; it cannot be “erased”.
Reasons for discrepancies
Participant Node A issues a “Valid” while Participant Node B issues a “Double Spend”.
-
Intentional Malice: Bank A is intentionally trying to trick the network.
Canton Solution: The Mediator rejects any transactions with non-unanimous Node votes.
-
Race Conditions / Latency: Node A has not yet observed a prior commit when evaluating a later envelope.
Canton Solution: The Mediator uses the lowest Sequence Number as the absolute soruce of truth for state of the ledger.
6. How Cross-Domain Transactions Work
In traditional systems, cross-chain swaps often rely on bridges, which introduce additional security and operational risk. In Canton, cross-domain transactions are designed to be atomic: if any leg fails on any domain, the whole workflow rolls back.
The Coordinator: The Participant Node
Because a participant node can connect to multiple domains, it can coordinate a workflow that spans domains without exposing each domain’s internal state to the other.
The Protocol Mechanism
-
Selection: The participant identifies the contract states on Domain A and Domain B.
-
The Transfer-Out: The participant node submits a transfer-out request to Domain A to lock/extinguish the asset there.
-
The Proof: Domain A provides a signed receipt (a timestamped proof) that the asset is locked/extinguished on that domain.
-
The Transfer-In: The participant node takes that proof to Domain B and submits a transfer-in request.
-
Re-materialization: Domain B’s sequencer verifies the proof from Domain A and allows the asset/ state to appear on Domain B.
Atomic Swap (Cash for Assets) Workflow
This diagram shows how Bank A buys an Asset from Bank B using Cash.
- Domain 1 (Central Bank): Manages the Cash.
- Domain 2 (Exchange): Manages the Asset.
In the public crypto world (like Ethereum to Solana), bridges usually work by “wrapping” assets. You lock Bitcoin in a vault and mint “Wrapped Bitcoin” on the other chain. If the vault is hacked, the wrapped assets become worthless.
In Canton, the protocol uses a Topological Change rather than a wrapper. The asset doesn’t just have a representative version on the other domain; the actual “ledger entry” moves its residency from one domain to another.
7. Deterministic Finality
A transaction is considered complete only after the Mediator issues a Commit verdict, after the Sequencer has ordered the transaction. In Canton, a transaction moves through three distinct phases to reach “Settlement Finality.”
-
Once the Sequencer assigns a sequence number, that order is fixed (under BFT consensus).
-
Once the Mediator issues the commit based on that sequence, the transaction is legally and technically final. There are no “reorgs” in Canton.
| Step | Status | Who “Decides”? |
|---|---|---|
| Execution | Pending | The Participant Node confirms the logic is correct, but doesn’t know if other nodes agree yet. |
| Sequencing | Ordered | The Sequencer / Global Synchronizer guarantees the order and protects against double-spending. |
| Verdict | FINAL | The Mediator commits or rolls back transactions based on the Global Synchronizer’s order and the Participants’ votes. |
Phase A: Submission & Sequencing (Temporal Finality)
The Participant Node (the bank) sends an encrypted transaction to the Sequencer (the domain/Global Synchronizer).
-
What happens: The Sequencer assigns a precise timestamp and a sequence number.
-
Is it final? No. At this stage, the network only knows when the transaction arrived. It doesn’t know if the transaction is valid or if the bank actually has the assets to back it up.
Phase B: Validation (Local Execution)
The Sequencer broadcasts the ordered (but still encrypted) message back to all involved Participant Nodes.
-
What happens: Each Participant Node decrypts the part of the transaction relevant to them. They run the Daml code to check:
- Logic: Is the trade legal according to the contract?
- Authorization: Are all the required signatures there?
- Consistency: Has this specific asset already been spent (double-spent)?
-
The Result: Each participant sends a “Vote” (Approve or Reject) to a component called the Mediator.
Phase C: The Verdict (Settlement Finality)
The Mediator (which is part of the Domain/Synchronizer infrastructure) collects the votes.
-
What happens: If the Mediator receives “Approve” votes from all necessary stakeholders, it issues a “Commit” Verdict. If even one necessary party rejects it (or a double-spend is detected), it issues a “Rollback” Verdict.
-
Is it final? YES. Once the “Commit” verdict is sequenced, the transaction is immutable. The assets have officially changed hands.
Canton emphasizes deterministic execution (Daml transaction model) and “deterministic finality” for atomic consistency (claimed for Global Synchronizer flows).
Finality is therefore not one universal notion across “the whole network”; it depends on (i) the domain(s) a workflow uses and (ii) whether Global Synchronizer coordination is involved.
Data visibility & privacy boundaries
-
Participants only receive/store/process what they “need to know,” determined at the sub-transaction level.
-
Domain operators may see some metadata but message contents are encrypted (as described in the protocol paper).
8. Governance & Control
The Canton Network is managed by the Canton Network Foundation (CNF), a non-profit foundation. Members of the CNF are vetted institutions which prevents sybil attacks.
The Canton Network is Permissioned in who its members are but operates in a Decentralized manner. No single entity can shut down the network or unilaterally change the rules once the consortium has agreed on them.
Governance structure
Governance is enforced through a "Topology” that acts as a decentralized directory that defines the following:
-
Identity Mapping: Real-world entities are mapped to their cryptographic keys.
-
Permissioning: Records the permissions that dictate which Nodes are allowed to connect to which Domains.
-
Protocol Versions: Deciding when the network will upgrade to a new version of Canton.
Canton vs. EVM
| Feature | L2 EVM Chains (Solidity) | Canton Network (Daml) |
|---|---|---|
| Consensus Scope | Global: Every node validates every transaction. | Local: Only involved parties validate. |
| Finality | Probabilistic: Blocks can be “reorged” until a certain depth. | Deterministic: Once the Mediator commits, it is final instantly. |
| Governance Basis | Token-Weighted: “1 Token = 1 Vote” + Security Committee Veto. | Identity-Based: “1 Institution = 1 Vote” (Federated). |
| Transaction Fees | Gas: Used to prevent spam and pay builders / sequencers. | Subscription/Membership: Paid to domain operators. |
| Spam Prevention | High costs (Gas) make spam expensive. | Vetting: Only known, legal entities can enter the network. |
| Code Upgrades | Hard/Soft Forks: Upgrades are hard forks. | Topology Transactions: Upgrades are sequenced like trades. |
Potential governance risks
-
If a small subset of Super Validators dominates operations, upgrades, or incident response norms, “decentralized governance” may be formally true but practically weak.
-
If governance becomes slow or politicized, institutions may fragment into semi-interoperable domains—undermining the network-of-networks thesis.
9. Trust Assumptions and Attack Vectors
Trust assumptions
In a public blockchain, trust is concentrated in majority hashpower/stake. In Canton, trust is distributed across explicit roles:
-
Trust in the Sequencer (Ordering): You trust the Sequencer to provide consistent ordering and not censor or reorder for advantage, while not trusting it with content (encrypted).
Mitigation: BFT consortium sequencing reduces unilateral censorship risk if >2/3 do not collude.
-
Trust in the Mediator (Verdicts): You trust the Mediator to correctly aggregate the “Approve/Reject” votes from participants. If a Mediator is corrupt, they could technically declare a transaction “Committed” even if a participant rejected it.
Mitigation: Participant nodes retain local audit trails. If a Mediator lies, the participant node will immediately detect the malfeasance and can raise a legal/governance dispute.
-
Trust in the Participant Node (Integrity): Because Canton is not a “global broadcast” network, you trust counterparties to provide the correct contract state references and signatures.
Note: Protocol forces nodes to provide cryptographic “inclusion proofs” that the data they are showing you is actually recorded on the ledger.
-
Trust in Governance (Identity): You trust the Canton Network Foundation/topology manager to properly KYC and vet the participants.
Key failure/attack surfaces institutions should pressure-test:
-
Domain operator risk: permissioning, censorship, metadata leakage, operational failure.
-
Cross-domain atomicity risk: if atomic coordination resembles a 2PC-style pattern, liveness/timeout recovery become operational concerns.
-
Global Synchronizer cartelization risk: even with 2/3 BFT thresholds, operator concentration, correlated outages, or governance capture can undermine neutrality.
Attack Vectors
1. Transaction Censorship (Sequencer Level)
A malicious Sequencer could refuse to process a specific participantʻs transactions.
-
The Risk: A bank could be “frozen” out of a market during a period of high volatility.
-
Defense: Multi-operator BFT sequencing reduces unilateral censorship; multi-domain connectivity can provide optionality.
2. Metadata Leakage & Traffic Analysis (Privacy Breach)
Even encrypted payloads can leak the size, timing, and frequency of transactions to the Sequencer.
-
The Risk: Sophisticated observers can infer strategy from repeated transaction patterns.
-
Defense: Padding/masking techniques aim to reduce leakage, but performance tradeoffs and residual leakage remain.
3. Participant Node Compromise (Keys + Data)
Participant Node hold unencrypted data and private keys.
-
The Risk: If an attacker hacks a bank’s Participant Node, they don’t just get the keys to move money; they get the entire historical record of every private contract that bank has ever signed.
-
Defense: Institutional-grade HSMs (Hardware Security Modules), strict key management, and multi-sig requirements for node operations.
4. “Daml Logic” Vulnerabilities
Daml reduces certain classes of bugs but does not eliminate logic risk.
-
The Risk: A developer could write a contract that allows a “Choice” to be exercised without the proper “Ensure” checks, leading to an unintended business obligations (e.g., a bank accidentally agreeing to a trade with a negative interest rate).
-
Defense: Daml allows for “Formal Verification,” meaning that the code can be tested and audited to ensure that it will only behave in certain ways before deploying it.
5. Domain Collusion (“God Mode” risk within a domain)
If one entity controls the Sequencer, the Mediator, and the Topology Manager for a specific domain, they effectively have “God Mode” over that sub-network.
-
The Risk: They could potentially rewrite the history of that specific domain or admit “ghost participants” to the network.
-
Defense: Canton encourages Cross-Domain workflows to limit exposure and minimize reliance on any single domain.
Comparison of Attack Surface
| Attack Type | Public Blockchain (Ethereum) | Canton Network |
|---|---|---|
| 66% Attack | Possible (Validators PoS) | Possible (Super Validators) |
| Data Theft | Impossible (Everything is already public) | High Risk (Node compromise = data leak) |
| Front-Running | High (MEV / Public Mempool) | Low (Sequencers are blinded) |
| Smart Contract Bug | High (Drains global pools) | Moderate (Affects only stakeholders) |
| Censorship | Difficult (Global network) | Moderate (Depends on Domain operator) |
How Canton differs from alternatives
-
Versus public blockchains: avoids global state replication and public-by-default data; trades away “minimize trust” for privacy, permissioning, and operational governance.
-
Versus traditional permissioned ledgers: targets interoperability and composable workflows across domains without requiring every domain operator to integrate pairwise.
-
Versus centralized FMI plumbing: provides FMI-like coordination without a single operator, but introduces multi-party operational complexity.
10. Economic & Incentive Model
Canton Coin
Canton Coin (CC) is a utility and incentive token designed to support Global Synchronizer usage. The token distribution is positioned toward institutions participating in network operations rather than retail distribution.
The Canton Coin is used for:
-
Paying for Sequencing: fees associated with ordering and shared synchronization services paid to the Super Validators.
-
Incentivizing Infrastructure: compensating entities that run Super Validator-grade hardware and operations.
-
Staking and Security: locking tokens ensures that Super Validators have “skin in the game” for validator participation and can be slashed for bad behavior.
-
Governance Voting: participating in decisions affected shared services - e.g. voting on protocol upgrades, fee changes, and the admission of new members.
Amulet Smart Contract
Amulet is the Daml smart contract that governs value, fees, and rewards within the shared synchronizer layer.
Unlike account-based balanaces, an Amulet is a Daml contract with signatories and an owner. Amuletʻs follow the same privacy and UTXO-style rules as any other asset on Canton.
Amulets were designed specifically to solve institutional problems that standard ERC-20 tokens (like those on Ethereum) cannot.
| Feature | Standard Token (ERC-20) | Amulet (Canton) |
|---|---|---|
| Logic Location | Stored in a central “ledger” contract. | Every Amulet is its own independent contract. |
| Parallelism | Transactions often queue up (bottleneck). | Multiple Amulets can be processed in parallel. |
| Programmability | Hard to add “decay” or “auto-rewards.” | Built-in features of the Amulet Daml template. |
| Privacy | Everyone can see the total supply/movements. | Only the owner and the “Mediator” see the Amulet movement. |
Amulet Mechanism
The Amulet mechanism governs four key areas:
1. Fee Payment (The “Fuel”)
When a Participant Node submits a transaction through the Global Synchronizer, it must attach an Amulet (or a fraction of one) to the transaction to cover fees.
-
The Sequencer checks the Amulet to ensure it is valid and has enough value to cover the fee.
-
One finality, the original Amulet contract is archived, and new, smaller Amulet contracts are created and sent to the Super Validators and the Foundation as payment.
2. Staking and Security
To become a Super Validator, an institution must lock Amulets in a staking contract.
-
The locked Amulets cannot be spent or traded.
-
The Validator accures rewards for performing their duties correctly.
-
Governance mechanisms can slash the locked staked if the Validator misbehaves.
3. The “Decay” (Melting) Mechanism
Amulets have an Economic Decay mechanism (also known as Demurrage) to discourage idle hoarding.
Why do this?
-
Velocity: It encourages usage rather than passive holding.
-
Sustainability: The “decayed” value can fund network operations during low network activity.
-
Inflation Control: It acts as a natural offset to reward issuance over time.
4. App Rewards (Ecosystem Incentives)
If an application drives network volume, fee-sharing can route a portion of the rewards to the app developer, creating a built-in business model for software developers.
Amulet Workflow
-
Minting: Amulets are created as rewards for Super Validators or bridging value into the system.
-
Spending: Participants use Amulets to pay for shared synchronization workflows.
-
Splitting: The Amulet mechanism automatically splits the fee: 70% to Validators, 20% to the Foundation, 10% to the App Developer.
-
Archiving: The spent Amulet is archived, and the “change” is returned as new, smaller Amulet contracts.
Network Economic Model
The Canton Network is designed to have stable and predictable fees so that institutions can calculate the cost of transactions in advance.
Transaction Fees
Fees are generally distributed among:
-
The Super Validators: Compensation for running consensus nodes and shared infrastructure costs - e.g. electricity, hardware, and bandwidth, required to keep the Global Synchronizer running.
-
The Foundation: A portion of the fees goes to the Canton Network Foundation to fund the ongoing development, legal compliance, and marketing of the network.
-
The Participant (Indirectly): Participants pay fees, but they benefit from cost savings from reducing reconciliation and operational overhead.
Network Organization Structure
The Canton Network is split into an operational software entity and a stewardship entity:
1. Digital Asset (the “Labs” Team)
Digital Asset is the private, commercial company (SaaS) that invented the Daml language and the Canton protocol. They sell software licenses, support, and services to institutions building and operating Canton infrastructure and applications.
2. The Canton Network Foundation (the “Senate”)
A non-profit organization based in Switzerland that acts as the neutral steward of the network. The Foundationʻs responsibility includes:
- Managing the Global Synchronizer.
- Setting governance rules.
- Maintaining the Topological Directory.
The board consists of representatives from member institutions (Super Validators) ensuring that the users of the network are the ones that govern it.
Sustainability
For institutions, the economic model succeeds if:
-
traffic fees are predictable and operationally manageable,
-
holding/using the token doesn’t create unacceptable balance sheet, capital, or compliance friction,
-
incentives do not distort behavior toward “reward farming” vs real economic workflows.
11. Dashboards & Metrics
Digital Asset publishes developer resources, Pilot Reports, and network insights.
- The Tie by Canton Data Analytics
A public dashboard that tracks “real-time metrics into Canton Network’s decentralized Global Synchronizer,” including activity by participants and application-level signals.
- RWA.xyz
- Canton Network Pilot Reports
Resources
LaunchNodes Canton Youtube Videos
John Galt, The Canton Network: Smart Contracts for the Grown-Ups in the Room
