Synchronizers
What sequencers and mediators do, and how a synchronizer is structured.
The previous page showed how Canton enforces privacy at the transaction level. This page introduces the synchronizer: the infrastructure layer that coordinates participants without seeing their data.
What is a synchronizer?
A synchronizer is not a node, a process, or a piece of software you install. It is a logical name for a group of sequencer and mediator nodes that work together to coordinate transactions between participants.
In practice, participants connect directly to one or more sequencer nodes. Sequencers are the only entry point into a synchronizer. All messages (from participants to mediators, and back) flow through them. Participants and mediators never communicate directly.
A synchronizer consists of two types of components:
| Component | Responsibility |
|---|---|
| Sequencer | Orders messages and delivers them to recipients. |
| Mediator | Collects confirmations and produces transaction verdicts. |
The participant connects to sequencer nodes inside the synchronizer. The synchronizer boundary is logical, not a separate service.
Who runs a synchronizer?
A synchronizer is owned by one entity or a group of entities. The owners control which sequencer and mediator nodes run on the synchronizer.
In simple setups, a single company runs everything:
In larger networks, the synchronizer owners choose a specific sequencer and mediator implementation, and multiple organizations each run their own instance of that same software. This way, no single operator has full control. For example, the Global Synchronizer is operated by a network of independent organizations ("Super Validators") who jointly run the sequencers using Byzantine Fault Tolerant (BFT) consensus and mediators with BFT state machine replication:
A participant can connect to any sequencer in the synchronizer. In this diagram each participant connects to one, but a participant can also connect to multiple sequencers simultaneously to reduce trust in any single operator and improve availability.
Sequencers in detail
The sequencer is the message backbone of Canton. Every protocol message between participants and mediators flows through it.
What the sequencer does
- Assigns timestamps. Every batch of messages gets a unique, globally ordered timestamp. This is what gives Canton its total ordering guarantee.
- Delivers messages to recipients. The submitter specifies who should receive each message. The sequencer routes accordingly.
- Provides delivery proofs. Each delivery includes cryptographic evidence that the sequencer actually processed and ordered the message. This prevents disputes about whether a message was sent.
What the sequencer does not do
- Read message contents. Payloads are encrypted by the sender. The sequencer sees metadata (such as recipients) but cannot decrypt the actual transaction data.
- Make decisions. The sequencer does not approve or reject transactions. It only orders and delivers.
Sequencer backends
Canton supports multiple sequencer backends. The choice is made at the synchronizer level, and all sequencer nodes on a given synchronizer run the same technology:
| Backend | Description |
|---|---|
| BFT (Byzantine Fault Tolerant) | Built-in backend for multi-operator deployments. Can run as a single node or across multiple peers. |
| External sequencers (e.g., CometBFT) | A plugin model where an external ordering service provides the sequencing. Requires a sequencer driver on the classpath. |
Mediators in detail
The mediator is the decision-maker in the two-phase commit protocol.
What the mediator does
- Collects confirmations. After the sequencer delivers a transaction request to participants, each confirming participant sends a response. The mediator collects these responses.
- Produces a verdict. The mediator computes one of three outcomes: approve (all required confirmers agreed), reject (a required confirmer disagreed), or timed out (the deadline passed before all responses arrived).
- Records the outcome. The mediator persists every verdict for auditability. If a dispute arises later, there is a record of what happened and why.
What the mediator does not do
- See contract data. Like the sequencer, the mediator works with encrypted payloads. It knows which parties are involved and whether they confirmed, but not what the transaction contains.
- Override party decisions. The mediator cannot force a transaction through if a required confirmer rejects it.
Trust model
A key design principle of Canton is that trust in the synchronizer is limited and explicit:
| Trust assumption | What it means |
|---|---|
| The sequencer orders messages correctly. | If the sequencer misordered messages, participants could end up with inconsistent ledger states. |
| The sequencer delivers messages to the specified recipients. | If the sequencer dropped messages, transactions could stall. |
| The mediator produces correct verdicts. | If the mediator approved a transaction that should have been rejected, the ledger could become inconsistent. |
| The sequencer does not store data longer than necessary. | The sequencer handles encrypted payloads, but it should not retain them indefinitely. |
Importantly, the synchronizer is not trusted with:
- Contract data. All payloads are encrypted. The synchronizer cannot read them.
- Business logic. The synchronizer does not execute Daml code. It only coordinates.
- Unilateral control. Only participant nodes can submit and validate transactions. The synchronizer coordinates, but cannot initiate changes to the ledger.
This limited trust model is what allows independent organizations to share a synchronizer without handing over control of their data.
Synchronizer membership
Participant nodes must explicitly join a synchronizer. When a participant connects:
- It submits its identity information (keys and certificates) to the synchronizer.
- It issues a trust certificate specific to that synchronizer, signaling that it consents to being a member.
- The synchronizer distributes this information to other members.
The participant explicitly signals its intent to join via the trust certificate. The synchronizer operator can optionally verify and approve the participant's topology transactions before admitting it. A participant can connect to multiple synchronizers simultaneously.
Next step
Now that you know what synchronizers are made of, the next page shows how these components coordinate to process a transaction: the two-phase commit protocol.