CIP-TBD
Title: Synchronizer Migration with Downtime to Splice 0.5.0 / Canton 3.4
Author:
Curtis Hrischuk
Marcin Ziolek
Soren Bleikertz
Wayne Collier
License: CC-1.0
Status: Draft
Type: Standards
Created: 2025-08-20
Approved: ??
Abstract
Splice 0.5.0 introduces new features and scaling improvements that rely on Canton 3.4. We recommend adopting Splice 0.5.0, which requires a Major Upgrade with Downtime, for the Super Validators and Validators, to move the network from Canton 3.3 to Canton 3.4. .
Specification
Super Validators will upgrade from one Canton release to the other, specifically 3.3 to 3.4, requiring a special upgrade procedure described under Synchronizer Upgrades with Downtime. This process requires a synchronized operational procedure involving all Super Validator nodes, and pauses the synchronizer until the upgrade is complete. While paused, no transactions will be sequenced on the synchronizer, and thereby also no activity records are created or rewards minted. This process has been tested extensively and has been completed thrice previously on DevNet, TestNet and MainNet, for Canton 3.1, Canton 3.2, and Canton 3.3. The procedure will be tested for Canton 3.4 on DevNet and TestNet before it will be carried out on MainNet. The procedure typically completes within three hours.
Validators undergo a similar but simpler procedure to upgrade their nodes described in the documentation. Validators do not have to do this synchronized with SVs, but until they upgrade, their node will be unable to create new activity records or mint rewards.
The proposed dates for the upgrade are:
DevNet: Nov 12, 2025 1:00 PM GMT
-
TestNet: Nov 26, 2025 1:00 PM GMT
-
MainNet: Dec 10, 2025 1:00 PM GMT
The specific actions to be taken on chain by the Super Validator operators are:
Using the “Set DsoRules Configuration” vote proposal form, propose a vote that:
DevNet
-
Check the checkbox for “Set next scheduled domain upgrade”
-
Set “nextScheduledSynchronizerUpgrade.time” to 2025-11-12T13:00:00Z
-
Set “nextScheduledSynchronizerUpgrade.migrationId” to 3.
Then, starting at 2025-11-12T13:00:00Z, complete the documented procedure.
TestNet
-
Check the checkbox for “Set next scheduled domain upgrade”
-
Set “nextScheduledSynchronizerUpgrade.time” to 2025-11-26T13:00:00Z
-
Set “nextScheduledSynchronizerUpgrade.migrationId” to 5.
Then, starting at 2025-11-26T13:00:00Z, complete the documented procedure.
MainNet
- Check the checkbox for “Set next scheduled domain upgrade”
-
Set “nextScheduledSynchronizerUpgrade.time” to 2025-12-10T13:00:00Z
-
Set “nextScheduledSynchronizerUpgrade.migrationId” to 4.
Then, starting at 2025-12-10T13:00:00Z, complete the documented procedure.
Motivation
The 0.4.x Splice codebase has evolved since the Global Synchronizer nodes (the synchronizer nodes as well as the Super Validator and validator participant nodes) adopted version Canton 3.3. The Canton 3.4 release improves the feature set of Canton 3.3 in multiple aspects. Notable improvements from an ecosystem growth perspective are:
-
Canton Network is growing rapidly and may approach limits without further scaling improvements. The following scaling dimensions are improved:
-
Adding a validator to the network takes more time as the topology state grows. In Canton 3.4, a more efficient method for shipping the topology state will slow or reduce the time increase.
-
Wallet providers are joining the Canton Network and each wallet adds a party. Without an increase in the number of supported parties, the growth of the wallets and new users will slow. Canton 3.4 increases the total number of parties that a Canton synchronizer and its connected nodes can support.
-
As the number of validators and parties increase, there is also an increase in the number of transactions processed by the Global Synchronizer. Splice 0.5.0 and Canton 3.4 increase the average and peak transactions per second to allow for continued growth.
-
The SVs have to manually construct a list of parties to ignore when performing an upgrade. Canton now has better support for unvetting packages which will remove the need to construct this ignore list.
-
Simpler deployment of a dApp's package files.
-
Easier ACS import for a new validator.
-
An improved package selection algorithm to select a dApp's package version when a dApp has multiple package versions deployed.
-
Traffic is the measured cost to execute a transaction. Being able to estimate traffic cost leads to efficient, cost-effective, and successful transaction execution. Traffic estimation is available for prepared transactions in Canton 3.4.
-
A major upgrade requires pausing the synchronizer until the upgrade is complete, which halts transaction processing; and further drops all transaction history in the Canton nodes. Canton 3.4 previews a new feature, for testing purposes, which will ultimately be able to perform major upgrades with near-zero downtime and data continuity for history across upgrades.
Rationale
The Canton 3.4 release is available for upgrade. It enables new features in Splice 0.5.0, as well as new capabilities to be leveraged by Canton Network application developers and partners.
The Canton 3.4 release introduces the following new capabilities:
-
Several optimizations to improve performance were implemented.
-
BFT validation of the initial topology state enables faster onboarding for validators to the network while preserving integrity.
-
ACS commitments are now more efficient which increases the TPS by lowering resource use.
-
Sequencer processing efficiency was improved which has a positive impact on TPS.
-
Other features discussed below reduce the amount of topology state that a validator needs to hold to increase scaling.
-
Only the latest package version of a dApp needs to be loaded. Previously, when a dApp had multiple package versions the entire package version lineage (e.g., versions 1, 2, 3, …) needed to be uploaded to a validator.
-
When importing an ACS for a new validator, there is no longer the need to load the entire version lineage of a package even if contracts in the ACS were originally created with older package versions.
-
The package selection algorithm for a dApp's package only considers vetted packages. It previously considered the uploaded packages irrespective of their vetted state.
-
Ability to safely unvet a vetted package. If a package is mistakenly unvetted, it can be restored by simply re-vetting the package.
-
A traffic cost estimation for a prepared transaction is available in Canton 3.4. The estimate is for submitting the prepared transaction against the validator that was used during preparation; if the transaction is submitted to a different validator then the estimation may be off.
-
Canton 3.4 introduces a preview Canton feature of a rolling protocol upgrade which is for enabling upgrades without downtime. This preview feature is for testing purposes only and should not be run in production (yet).
There are also numerous smaller robustness and feature improvements that will be described in the 3.4 release notes.
Backwards compatibility
Applications that use the Validator APIs and Scan APIs are not affected (see validator node network diagram). Applications that integrate directly with the Canton participant node and its Ledger API should no longer be using the JSON API v1 and must have migrated to JSON API v2.
Reference implementation
The Splice 0.5.0 code can be found here.
The OSS Canton 3.4 code can be found here.
Splice 0.5.0 and Canton 3.4 have been integrated and are completing functional and performance testing. Canton 3.4 Release Notes will be published once the release process is complete.
Copyright
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal
Changelog
-
2025-10-21: Initial email draft of the proposal.