CIP Browser/CIP-0089GitHub ↗

CIP-0089: Synchronizer Migration with Downtime to Splice 0.5.0 / Canton 3.4

ApprovedStandardsby , Curtis Hrischuk, Marcin Ziolek, Soren Bleikertz, Wayne CollierCreated 21-08-2025Approved 30-10-2025
TL;DR

CIP-0089 Synchronizer Migration with Downtime to Splice 0.5.0 / Canton 3.4

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.

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 2:00 PM GMT
  • TestNet: Nov 26, 2025 2:00 PM GMT
  • MainNet: Dec 10, 2025 2: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-12T14:00:00Z
  • Set “nextScheduledSynchronizerUpgrade.migrationId” to 1.

Then, starting at 2025-11-12T14:00:00Z, complete the documented procedure.

TestNet

  • Check the checkbox for “Set next scheduled domain upgrade”
  • Set “nextScheduledSynchronizerUpgrade.time” to 2025-11-26T14:00:00Z
  • Set “nextScheduledSynchronizerUpgrade.migrationId” to 1.

Then, starting at 2025-11-26T14:00:00Z, complete the documented procedure.

MainNet

  • Check the checkbox for “Set next scheduled domain upgrade”
  • Set “nextScheduledSynchronizerUpgrade.time” to 2025-12-10T14:00:00Z
  • Set “nextScheduledSynchronizerUpgrade.migrationId” to 4.

Then, starting at 2025-12-10T14: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 were addressed:
    • Adding a validator to the network takes more time as the topology state grows.
    • As the number of validators and parties increase, there is also an increase in the number of transactions processed by the Global Synchronizer.
  • The SVs have to manually construct a list of parties to ignore when performing an upgrade which is tedious and error prone.
  • As a dApp evolves through several package versions, loading the entire lineage of versions (e.g., versions 1.0.1, 1.0.2, 2.0.0, 3, …) is needed for each validator running the dApp to accommodate the possibility of multiple contract versions being in the ACS. This is tedious and time consuming. It also uses more validator memory as each package version is loaded.
  • Importing an ACS for a new validator requires loading the entire version lineage of the package which slows bringing the validator online and can be quite complex with several dApps that each have their own version lineage .
  • Traffic is the measured cost to execute a transaction. Being able to estimate traffic cost leads to efficient, cost-effective, and successful transaction execution.
  • Hard synchronizer migrations are a complex and expensive operational procedure to upgrade the protocol version of a synchronizer. .

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.
    • Improved topology state validation and BFT read 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 the average and peak transactions per second to allow for continued growth.
    • Other features discussed below reduce the amount of topology state that a validator needs to hold which increases 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 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. This will reduce memory use on the validator.
  • 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.
  • Introduction of a preview Canton feature, for testing purposes, of “logical synchronizer upgrades” which reduces downtime and operational complexity for protocol version upgrades, as well as supporting data continuity for history across upgrades. This preview feature is for testing purposes only and should not be run in production (yet).
  • The SVs no longer have to manually construct a list of parties to ignore when performing an upgrade. Canton now has better support for unvetting packages which removes the need for SVs have to manually construct a list of parties to ignore
  • An improved package selection algorithm to select a dApp's package version when a dApp has multiple package versions deployed.

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.
  • 2025-10-30: Approved CIP.
  • 2025-11-04: Edited to incorporate daylight savings change which moves times in UTC ahead an hour