Skip to main content
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.

​
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. The protocol operates across three node types:
  • 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
Participants and mediators never communicate directly. All messages flow through sequencers, which provide global ordering. Payloads are encrypted so that sequencers see only metadata — recipient lists and message sizes — not transaction content.

​
Protocol Types

The term member denotes a sequencer, a mediator, or a participant node. This section presents the different kinds of protocols supported by Canton:
  • Channel broadcast to broadcast a message to some or all members of a synchronizer.
  • Two-phase commit to coordinate changes on state (for example, Canton transactions to change the state of a contract, or reassignments to change assignation of a contract).
  • Point-to-point to enable pairs of members to exchange messages (note that members always exchange messages through sequencers).

​
Channel broadcast

A channel is a well-defined group of recipients. Channel broadcast ensures that all members of the channel receive the same set of messages. Because of the ordering guarantees offered by the sequencers, channel members can use state machine replication for updating the state managed by the group. Examples:
  • Topology state is broadcasted to all members of the synchronizer.
  • Traffic management uses broadcasts to all sequencers of the synchronizer.

​
Two-phase commit

To coordinate atomic changes that affect the state of multiple channels, Canton implements a two-phase commit protocol. Canton’s transaction protocol allows app composability as well as privacy (each participant node only sees parts of the transaction involving parties it hosts). The underlying theory:
  • Each data item belongs to a channel, and within a channel every member performs state machine replication. For contracts in the context of a transaction, the channel is a group of stakeholders.
  • A transaction can span multiple channels. Two-phase commit ensures that the changes to all channels commit.
  • Invariants across channels (for example, the internal consistency of transactions) can only be ensured by the honest channel members.
  • Additionally, further members may need to validate an action or be notified of it (for example, for checking delegations).

​
Point-to-point

Point-to-point protocols allow a member of the synchronizer to send messages to another member of the same synchronizer. Since sequencers are used as gateways, such messages are ordered with respect to other messages of the other protocols. One use case of point-to-point communication is ACS commitments.

​
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 Canton transaction moves through both consensus layers during its lifecycle:
  1. The submitting participant prepares the transaction locally (smart contract layer)
  2. The participant sends encrypted views to the sequencer (ordering layer)
  3. The sequencer distributes views to affected participants and an informee message to the mediator
  4. Each confirming participant validates its views and sends a confirmation or rejection to the mediator (smart contract layer, via ordering layer)
  5. The mediator aggregates confirmations and issues a verdict, within the required time window, which the sequencer distributes to all participants (ordering layer)
The Transaction Lifecycle page covers each phase in full detail.