> ## Documentation Index > Fetch the complete documentation index at: https://cantonfoundation-version-dashboard-update.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Canton Protocol Specification > Technical specification of the Canton protocol architecture, covering consensus layers, transaction processing, and topology management This section provides the full technical specification of the Canton protocol. Where the [Learn](/overview/learn/architecture) 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. | 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 | 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](#channel-broadcast) to broadcast a message to some or all members of a synchronizer. * [Two-phase commit](#two-phase-commit) to coordinate changes on state (for example, Canton transactions to change the state of a contract, or [reassignments](/overview/reference/reassignment-protocol) to change assignation of a contract). * [Point-to-point](#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](/overview/reference/topology) 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](https://en.wikipedia.org/wiki/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](/overview/reference/pruning#non-repudiation-guarantees). ## Reference Pages The extended UTXO model: templates, stakeholders, choices, transaction structure, views, and witnesses. Proof of Stakeholder validation, privacy-preserving consensus, and trust domain comparisons. Sequencer and mediator architecture, BFT ordering service, and the ISS-inspired consensus protocol. The complete five-phase lifecycle from preparation through commit. 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](/overview/reference/transaction-lifecycle) page covers each phase in full detail.