How multi-synchronizer connections work
Each synchronizer connection is independent. Your validator maintains a separate communication channel to each synchronizer’s sequencer, and contracts are assigned to a specific synchronizer. When you create a contract, it is assigned to one synchronizer. You can later move it to another synchronizer using the unassignment/reassignment protocol. The validator tracks which synchronizer each contract belongs to and routes transactions accordingly. If a transaction involves contracts on different synchronizers, Canton synchronizes the transaction across both — though this adds latency compared to single-synchronizer transactions.Adding a synchronizer connection
Via Canton Console
If your validator is already running and connected to the Global Synchronizer, you can add a private synchronizer connection at runtime:alias is a local name you choose to identify the synchronizer. It does not need to match any network-level name — it is only used in your local configuration and API calls.
To verify the connection:
Via Admin API
You can also register a new synchronizer connection through the Admin API’s gRPC interface. The relevant service isSynchronizerConnectivityService, with the ConnectSynchronizer RPC:
SynchronizerConnectionConfig includes the sequencer connection URL and any TLS settings.
Via Helm values
For validators deployed with Helm, you can declare additional synchronizer connections in the values file so they are established on startup:Managing synchronizer connections
Listing connections
Disconnecting from a synchronizer
You can disconnect from a synchronizer without losing contract data:Reconnecting
Contract assignment and reassignment
When a contract is created, it is assigned to the synchronizer where the creating transaction executes. You control this by submitting the command through the appropriate synchronizer connection. To move a contract to a different synchronizer:Choosing the right synchronizer for a contract
Consider these factors when deciding where to assign a contract:- Who needs to see it? All validators hosting the contract’s stakeholders must be connected to the contract’s synchronizer. Use the Global Synchronizer for contracts involving external parties.
- Transaction frequency — High-frequency bilateral workflows run more efficiently on a private synchronizer where you control capacity and avoid traffic fees.
- Settlement needs — If a contract will eventually interact with Canton Coin or Global Synchronizer contracts, plan for a reassignment step.
- Privacy requirements — Contracts on a private synchronizer are processed exclusively by infrastructure you control. On the Global Synchronizer, the sequencer and mediator are operated by super-validators.
Troubleshooting
Connection refused or timeout:- Verify the sequencer URL is correct and reachable from your validator’s network
- Check that TLS certificates are valid and trusted
- Confirm any firewall or network policy allows outbound connections to the sequencer port
- Check the validator logs for connection errors
- Verify the synchronizer is initialized and the sequencer is healthy
- Ensure the validator’s identity is authorized on the target synchronizer
- Confirm your validator is connected to both the source and target synchronizers
- Verify all contract stakeholders have validators connected to the target synchronizer
- Check that the contract is not currently being exercised in another transaction
Synchronizer connections
A Participant Node connects to the Synchronizer by connecting to one or many Sequencers of this Synchronizer. A Participant Node can connect to multiple Synchronizers at once. The synchronizer connectivity commands allow the administrator of a Participant Node to manage connectivity to Synchronizers. The following sections explain how to manage such Sequencer connections for a Participant Node.Connect
Connect to a Sequencer by Reference
To connect a Participant Node to a Sequencer by reference (local or remote reference), follow the steps below.- Define a Synchronizer alias. An alias is a name chosen by the Participant’s operator to manage the connection. For example:
- Set Optional Sequencer Connection Validation. This parameter determines how thoroughly the provided Sequencer connections are validated before being persisted.
- Execute the
connect_localcommand:
- List the connected Synchronizers to verify that the connection is listed. See inspect connections.
Connect to a Sequencer by URL
To connect to a remote Sequencer:- Obtain the Sequencer address and port from the Synchronizer Operator.
- Provide custom certificates (if necessary). If the Sequencer uses TLS certificates that cannot be automatically validated using your JVM’s trust store (for example, self-signed certificates), you have to provide a custom certificate such that the client can verify the Sequencer’s public API TLS certificate. The operate must trust the custom root CA. Let’s assume that this root certificate is given by:
- Connect the Participant to the Sequencer using the
connectconsole command.
- List the connected Synchronizers to verify that the connection is listed. See inspect connections.
Connect to decentralized Sequencers
To enhance reliability and security, you can connect to multiple Sequencers of the same Synchronizer using theconnect_bft command.
- Create the URL for each Sequencer by referencing its public API address and port.
- Create the Sequencer connections.
- Configure the Sequencer trust threshold by setting the minimum number of Sequencers that must agree before a message is considered valid.
- Default: 1
- Maximum: Number of connections
- [Specific to the connection pool] Configure the Sequencer liveness margin; this sets the number of Sequencer connections, in addition to
sequencerTrustThreshold-many, from which we attempt to read messages.
- Default: 0
- Higher values increase the resilience to Sequencer delays or failures, but having (
sequencerTrustThreshold+sequencerLivenessMargin> number of connections) provides no benefit.
- Configure submission request amplification: define how often the client should try to send a submission request that is eligible for deduplication.
- Higher values increase the chance of a submission request being accepted by the system, but also increase the load on the Sequencers.
- Default:
SubmissionRequestAmplification.NoAmplification
- Connect using the
connect_bftcommand.
- List the connected Synchronizers to verify that the connection is listed. See inspect connections.
Inspect connections
You can inspect the connected Synchronizer connections, as well as the configuration of a specific connection.- List connected Synchronizer connections. You can get the Synchronizer aliases and Synchronizer IDs of all connected Synchronizers:
- Inspect the configuration of a specific connection:
Modify
Update Sequencer trust threshold
You can modify the Sequencer trust threshold to control how many Sequencers must agree before a message is considered valid.- Define a valid threshold. Set the threshold value between 1 and the number of connected Sequencers.
- Verify the updated configuration using:
[Specific to the connection pool] Update Sequencer liveness margin
You can modify the Sequencer liveness margin to control the resilience to faulty Sequencers.- Update the configuration with the new liveness margin:
- Verify the updated configuration using:
Update request amplification
- Configure submission request amplification. Amplification makes Sequencer clients send eligible submission requests to multiple Sequencers to overcome message loss in faulty Sequencers.
- Same as above, verify the updated configuration using
configcommand.
Synchronizer priority
When connected to multiple Synchronizers, transaction routing will select the Synchronizer with the highest priority for submitting transactions. You can adjust the priority of a Synchronizer to control which one is preferred for submissions. For more details, refer to the multiple synchronizer documentation- Update the priority of the Synchronizer connection.
- Same as above, verify the updated configuration using
configcommand.
Update a custom TLS trust certificate
Whenever the root of trust changes, the clients need to update the custom root certificate accordingly. To update a custom TLS trust certificate, particularly when using self-signed certificates as the root of trust for a TLS Sequencer connection, follow these steps:- Load the root certificate from a file:
- Create a new connection instance and pass the certificate into this new connection.
- Update the Sequencer connection settings on the Participant Node:
Disconnect and reconnect
- Disconnect from the Synchronizer by using the
disconnectcommand with the Synchronizer alias:
- Verify the disconnection:
- Reconnect to a specific Synchronizer using the
reconnectcommand with the Synchronizer alias:
- To reconnect all Synchronizers that are not configured to require a manual connection, use the following command: