This section provides the full technical specification of the Canton protocol. Where the Learn pages introduce concepts at a high level, these reference pages describe the protocol mechanics in detail — the data structures, trust assumptions, message flows, and formal properties that underpin Canton Network.Documentation Index
Fetch the complete documentation index at: https://docs.canton.network/llms.txt
Use this file to discover all available pages before exploring further.
Protocol Architecture
Canton’s protocol separates two concerns that most blockchains conflate: smart contract validation and transaction ordering. The result is a two-layer consensus architecture where each layer can be optimized independently.| Layer | Responsibility | Mechanism | Trust Boundary |
|---|---|---|---|
| Smart contract consensus | Validate transaction correctness | Proof of Stakeholder (peer-to-peer) | Only affected parties |
| Ordering consensus | Establish consistent synchronizer ordering | BFT ordering via sequencers | Synchronizer operators |
- Participant nodes host parties, maintain their Active Contract Set (ACS), execute the smart contract consensus protocol on their behalf, and make the LAPI available for use.
- Sequencer nodes provide authenticated, event ordering multicast with sender privacy
- Mediator nodes mediate the two-phase commit protocol that binds validation results into final transaction decisions
Reference Pages
Ledger Model (Detailed)
The extended UTXO model: templates, stakeholders, choices, transaction structure, views, and witnesses.
Smart Contract Consensus
Proof of Stakeholder validation, privacy-preserving consensus, and trust domain comparisons.
Ordering Consensus
Sequencer and mediator architecture, BFT ordering service, and the ISS-inspired consensus protocol.
Transaction Lifecycle
The complete five-phase lifecycle from preparation through commit.
Topology
Namespace management, cryptographic keys, party-to-participant mappings, and topology transactions.
Key Properties
Canton’s protocol provides the following guarantees:- Sub-transaction privacy: Each party sees only the portions of a transaction relevant to them. Sequencers and mediators cannot read transaction payloads.
- Integrity: A transaction commits only if all required stakeholders confirm it, and only if the smart contract logic passes validation for every signatory.
- Consistency: The ordering layer helps to prevent double-spends by ensuring a single global ordering of all state changes on a given synchronizer.
- Finality: Once a mediator issues a commit verdict and it is sequenced, the transaction result is final. There are no forks or reorganizations.
- Liveness: Under the BFT fault tolerance threshold (fewer than one-third of ordering nodes faulty), the protocol makes progress.
How the Layers Interact
A Daml transaction moves through both consensus layers during its lifecycle:- The submitting participant prepares the transaction locally (smart contract layer)
- The participant sends encrypted views to the sequencer (ordering layer)
- The sequencer distributes views to affected participants and an informee message to the mediator
- Each confirming participant validates its views and sends a confirmation or rejection to the mediator (smart contract layer, via ordering layer)
- The mediator aggregates confirmations and issues a verdict, within the required time window, which the sequencer distributes to all participants (ordering layer)