Logical Synchronizers provide an abstraction layer between physical synchronizer nodes and the Validators that rely on them. This abstraction allows the Validator node to connect to a single synchronization service, even as the underlying synchronizer nodes (the "physical" synchronizers) change their deployment and adopt new communication protocols. This CIP proposes that the Global Synchronizer adopt Logical Synchronizers, and use Logical Synchronizers for future protocol upgrades. This will allow Validator nodes to maintain a continuous synchronizer connection as the physical synchronizer nodes upgrade from one protocol version to another, and to retain all local history. The CIP also proposes scheduling the first Logical Synchronizer Upgrade (LSU) of the Global Synchronizer, to move the network from Canton Protocol Version 34 to Canton Protocol Version 35.
Logical Synchronizer-enabled upgrades (LSUs) will replace the "Synchronizer Upgrades with Downtime" procedure used in CIP-0062 and CIP-0089. A successor physical synchronizer spins up alongside the existing one. Validators switch over automatically, with seconds to minutes of noticeable downtime and no migration dump export/import. This eliminates the 90-minute to 3-hour coordinated network pause required by prior protocol upgrades, and allows Validators to retain historical data. Note however that topology changes (new parties, new nodes, and Daml model vetting) must pause for a longer period, up to a few hours, as the topology state propagates to the new physical synchronizer nodes. (Future protocol versions may reduce this topology management pause.)
Specification
How LSU Differs from Previous Upgrades
Previous upgrades (CIP-0062, CIP-0089) required a coordinated global halt. SVs paused the synchronizer, all nodes exported migration dumps, SVs deployed new Canton components, imported the dumps, and waited for a BFT majority to finish. Validators then deployed a new node that imported the migration dump. The whole process required from 90 minutes to 3 hours of downtime. It involved a live coordination call involving all Super Validator operators, and required explicit action by all Validator operators to spin up a new node from a migration-specific node backup.
I want to be clear that we are recommending that while Wayne's message was about this particular LSU, our recommendation is to generally move MainNet protocol upgrades outside of core market ours - which coincide with core working hours. The downsides you highlight are real, but we believe are worth it:
These upgrades are rare. We are only about to do the second one this year.
If they work, they take minutes. As you say, the point of LSUs is to almost make them a non-event. So the expected actual burden is to be available on standby for a short period.
There is a blip for participants for about a minute where may need to be retried due to timeouts. This would better be kept outside market hours.
Should a protocol upgrade go wrong for some unforeseen circumstance, despite all the testing and pre-validation on Dev- and TestNet, the impact during market hours is higher than outside. This is the main rationale for the move.
Because there's always the possibility of something going wrong - as per bullet 4 above - LSUs ops teams should be on standby just in case. This does indeed require commitment from the ops teams, which is why we are putting it forward as a governance topic.
I believe that the Wednesday US morning timing, just as US markets open, is the worst possible from a risk perspective. Saturday fully mitigates this. If you see a middle ground that all operators would be more able to commit to, let's put a few more options out there. My understanding is that due to operator time zones, 9am ET is preferred as a time of day, which makes all weekdays somewhat equally problematic.
I like the consideration how timing would influence how any scalability issues would be caught, despite it being an unlikely scenario given all the testing that goes into releases. But thinking it through, I reach the a different conclusion about upgrading during peak vs lowest load.
Upgrading during peak load gives you the strongest signal that there is no such regression, but if there is, you have an immediate fire drill.
If you upgrade during lowest load, you can observe the network's performance as load ramps back up and have a bit more breathing room to react. I'd argue the latter is preferable. Note also that today, there is no discernable difference in load on the network during different times of the week. 24/7 business dominates. What we are looking to shield with this change is the regulated market activity taking place on the network.
On Tue, May 19, 2026 at 1:38 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:
Hello All,
Our tech team reviewed the timing for LSU migrations and had a few observations below that may be worth considering.
Weekday upgrades provide a stronger validation signal because the network is operating under normal business conditions. Weekend activity is typically lighter, so a successful weekend upgrade may only confirm that the system performs well under reduced load.
Some issues only appear when the network is busy. Things like contention, backpressure, timeout behavior, and sequencer batching may not show up in a quiet weekend environment. If those issues exist, they are more likely to surface when weekday traffic returns,
which can create more risk at the beginning of the week.
We understand the value of weekend practice and operational readiness. A better way to support that may be through dedicated TestNet drills, where the team can rehearse the process without reducing the validation value of the MainNet cutover.
A Wednesday upgrade window appears to offer the cleanest feedback loop. It provides real traffic, active users, full engineering coverage, and time to observe behavior before the weekend.
Our suggestion is to keep LSU migrations on weekdays where possible. If weekend readiness is a priority, we would suggest scheduling separate TestNet weekend drills to support that need. For the same reason, DevNet and TestNet upgrades may also be better suited
to weekday schedules.
From: cip-discuss@... <cip-discuss@...> on behalf of Aman Goyal via lists.sync.global <aman.goyal=sbisecsol.com@...> Sent: Tuesday, May 19, 2026 4:35:57 AM To: cip-discuss@... <cip-discuss@...> Subject: Re: [cip-discuss] CIP-0117 Logical Synchronizers and LSUs
Hi,
I propose we reconsider scheduling the upcoming logical synchronizer upgrade (LSU) over the weekend. While I understand the desire to minimize weekday impact, moving forward with a weekend maintenance
window introduces several operational risks:
It sets a precedent that major network upgrades are expected to happen during weekends.
It may be difficult for operators and contributors to sustainably commit to weekend work on an ongoing basis.
If coordinated action is required during or after the upgrade, some network participants may not respond promptly outside normal working hours.
One of the goals of LSUs is to reduce the operational burden and urgency associated with upgrades, including minimizing the need for tightly coordinated maintenance windows.
Preferably, schedule upgrades during regular working days and hours.
Regards,
Aman
On Tue, May 19, 2026 at 1:41 AM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:
After internal discussions at Digital Asset, and a recommendation from Justin Peterson at Tradeweb, I'd like to propose moving the Logical Synchronizer Upgrade on MainNet from Wednesday June 17th to Saturday, June 20th, at 9 am US Eastern.
I'd also like input on whether we should perform the DevNet and TestNet upgrades on Saturday as well.
Argument in favor: SV operators can all work out their weekend operating procedures before the MainNet upgrade
Argument against: Weekday practices are just as good as weekend practices
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
No changes will be made to the CIP text after this announcement other than updating the approval date and status.
Sponsors / Endorsers
DA– SV Sponsor
MPCH– SV Endorser
Voting Instructions All other operators, please reply with:
<SVName> votes <infavor | notinfavor>
If you believe any change made after this announcement is substantive, please vote not in favor and include your reasoning in the vote response.
Super Validators deploy successor synchronizer nodes alongside existing ones before the freeze time. Automation built into Splice handles state transfer, successor initialization, health checks, and traffic migration.
Validators upgrade to a new binary at their own pace before the upgrade time. This new binary allows the Validator to use both the existing and new protocols (in this case, Canton Protocols 34 and 35). The Validator node switches from one protocol to the other upon receiving a specially formatted transaction from the logical synchronizer.
Application Developers don't need to do anything, as the logical synchronizer ID remains stable across the upgrade. Applications see a continuous transaction stream, with a pause of seconds to a few minutes when their Validator performs the switch.
Upgrade Procedure
Release availability. Canton 3.5 (Protocol Version 35) and Splice 0.6.1 become available. These releases support both the old and new protocol versions. Note that Splice 0.6.1 is available now on DevNet.
Asynchronous binary upgrade. Validators and Super Validators upgrade to the new binaries independently, at their own pace, while continuing to run on the original physical synchronizer. This must be done before the scheduled upgrade time.
Governance vote. Using the SV governance UI, an SV proposes an on-chain vote to schedule the LSU through the nextScheduledLogicalSynchronizerUpgrade field in DsoRulesConfig. The schedule includes:
Topology freeze time: after this point, no topology transactions (party additions, package vetting, etc.) can be sequenced until the upgrade completes.
Upgrade time: the moment the switchover happens. Daml transactions on the original synchronizer time out; new transactions are processed on the successor.
New physical synchronizer serial: the old serial incremented by 1.
New protocol version: the target protocol version (e.g., "35").
Successor node deployment (SVs only). SVs deploy successor sequencer, mediator, and ordering nodes alongside their existing nodes. The Validator is not redeployed, because it is tied to the logical synchronizer identity and persists across upgrades. SVs configure synchronizers.successor in their SV and scan Helm charts. This must be done before the topology freeze time. Announcement of the successor happens after the topology freeze time, once the topology state has been imported into the new node.
Topology freeze and state transfer. At the freeze time, each SV's automation publishes an LsuAnnouncement topology transaction. This freezes non-upgrade topology changes and identifies the successor synchronizer. Each SV's automation then exports topology and identity state from the current nodes, initializes the successor nodes from that state, and publishes LsuSequencerConnectionSuccessor topology transactions containing the new sequencer endpoints. For the first LSU, in June 2026, the topology freeze will begin 24 hours before the upgrade itself.
Health verification. Between the freeze time and upgrade time, SV automation sends periodic health check events on the successor synchronizer. SVs monitor the "LSU Sequencing Test" dashboard to confirm that every SV can sequence on the successor and that BFT peer connections are healthy.
Automatic switchover. Before the upgrade time, Validator nodes detect the successor, performs a handshake, and initiates a local copy of the topology state. It then verifies internal consistency (a clean synchronizer index and an ACS commitment watermark), registers the successor connection, and switch over. SV automation transfers traffic control state to the successor sequencer.
Post-upgrade cleanup. SVs update their Helm configuration: synchronizers.successor becomes synchronizers.current; the old current becomes synchronizers.legacy. After 30 days, legacy synchronizer nodes are decommissioned.
On-Chain Actions by Super Validator Operators
Using the "Set DsoRules Configuration" vote proposal form, propose a vote that populates the nextScheduledLogicalSynchronizerUpgrade schedule:
DevNet
The Super Validators will perform a practice LSU on DevNet, followed by an official LSU.
Set newPhysicalSynchronizerProtocolVersion to "35"
Then, at the scheduled topology freeze time, the automated LSU procedure begins.
Cancellation
Between the topology freeze time and the upgrade time, the upgrade can be cancelled if the successor synchronizer is unhealthy. A threshold of Super Validators sends a POST request to the /v0/admin/synchronizer/lsu/cancel endpoint on the SV API.
Cancellation removes the LsuAnnouncement topology transaction, which unfreezes the topology state and restores normal operations on the original physical synchronizer. No data is lost, and no further recovery steps are needed.
Failure Recovery
If the upgrade proceeds past the upgrade time but the successor synchronizer then breaks, the Super Validators can implement a “roll forward” recovery mechanism by spinning up a third synchronizer and processing new transactions there. The details of roll forward recovery depend on whether any Daml transactions were sequenced on the (failed) successor:
No transactions sequenced on successor: The broken successor is thrown out and replaced by a new one with an incremented serial (e.g., serial 2 more than the original). SVs deploy the replacement and re-run the LSU process.
Some transactions sequenced on successor: SVs keep both the original and broken successor running (so nodes can catch up) and spin up a third synchronizer as the new successor. ACS commitment mismatches may surface and are resolved using the standard resolution process.
This "roll-forward" LSU also works as a general disaster recovery mechanism if the current physical synchronizer becomes permanently unavailable, independent of any planned upgrade. In that case, SVs coordinate through configuration rather than on-chain governance.
Motivation
The Canton Network has completed 4 major upgrades with downtime: to Canton 3.1, 3.2 (pre-CIP), 3.3 (CIP-0062), and 3.4 (CIP-0089). Each one required a multi-hour coordinated halt, a live call among all SV operators, and manual deployment steps from every validator. As the network grows, this pattern breaks down.
Prior “major upgrade” logic removes Validator history. Major upgrades with downtime purge the history stored locally on Valdiator nodes, forcing operators to back up and access their historical data in separate offline stores.
Downtime is commercially unacceptable at scale. The network now supports real financial activity. A 3-hour halt disrupts live applications and erodes confidence in the platform's availability guarantees.
Operational burden is a barrier to growth. Every validator operator needs substantial expertise to perform the migration sequence within a narrow window. That raises the bar for joining the network and increases the risk of errors that cascade.
Coordination doesn't scale. Coordination across Super Validator operators on a live call will become untenable as the number of Super Validators increases. LSUs will enable a larger Super Validator pool in the future.
Risk compounds with scale. The dump-and-restore procedure creates windows for data corruption or operator error. Each additional participant is another potential point of failure in the chain.
LSU moves coordination on-chain (through LsuAnnouncement and LsuSequencerConnectionSuccessor topology transactions), automates the validator-side upgrade, and cuts the downtime window from hours to seconds. Our goal is to make protocol upgrades a routine operation.
Rationale
Why LSU Is Possible Now
Canton 3.4 shipped LSU as a preview feature, for testing only. Canton 3.5 hardens it for production. Here's what makes it work:
Logical vs. Physical Synchronizer Identity. Canton 3.5 implements a composite PhysicalSynchronizerId that links a serial number and protocol version to the stable logical synchronizer ID. The logical identity (the one Validators, parties, and applications reference) does not change. History is preserved across upgrades under a single logical ID. Safety comes from strict time ordering and the successor mechanism.
On-chain upgrade orchestration. Two new topology transaction types, LsuAnnouncement and LsuSequencerConnectionSuccessor, let the protocol itself coordinate the migration. The announcement freezes topology state and signals the upcoming upgrade, while the connection successor mappings tell Validators where to find the new sequencers.
Automated participant logic. The Canton participant detects the LSU announcement, verifies readiness, registers the successor, and switches over. The Splice team has provided automation in Splice 0.6.1 to cover various edge cases, including automatic upgrade, crash recovery, late joining, and manual recovery for disaster scenarios.
Sequencer time bounds. The successor sequencer enforces strict time boundaries that ensure monotonic time progression across the upgrade boundary and block message replay between physical synchronizer instances.
Deduplication across the physical synchronizer boundary. From Protocol Version 35, the physical synchronizer ID (not the logical ID) is used in the hash computation for externally signed transactions. A transaction prepared for one physical synchronizer can't be replayed on its successor, so it must be prepared again.
What This Means for the Network
We aim to make protocol evolution a routine process. The Canton Network can adopt improved protocol versions, bug fixes, and performance improvements without the "fear of upgrade" that bogs down many distributed ledger networks.
The synchronizer becomes commodity infrastructure. Upgrades and maintenance become straightforward, with minimal impact on application developers and end-users.
Validator operations are significantly simpler. Validators don't need to run complex migration steps. Provided they upgrade their binary on the regular weekly cadence, the rest of the process is automatic.
Disaster recovery is automated and more scalable. The roll-forward LSU mechanism provides an automated recovery path for synchronizer failures, in addition to the upgrade flow.
Backwards Compatibility
Applications that use the Validator APIs and Scan APIs are not affected by this change. The logical synchronizer ID stays stable across the upgrade, and migration IDs will freeze at the latest value; applications see a continuous transaction stream under a single identity.
Applications that integrate directly with the Canton participant and its Ledger API should note:
Starting with Protocol Version 35, the synchronizer_id field in externally signed prepared transaction metadata contains the physical synchronizer ID rather than the logical synchronizer ID. Applications should not rely on the format of this value.
We anticipate that future protocol versions will add the logical synchronizer ID.
Integrators using external signing are encouraged to adopt HASHING_SCHEME_VERSION_V3, which includes TTL in the hash computation.
The Canton 3.5 release notes will cover the complete set of API changes, deprecations, and migration guidance beyond LSU's scope.
Splice 0.6.1 and Canton 3.5 (which introduces Canton Protocol 35) have been integrated and are available on DevNet. The LSU procedure has been validated by the Splice team through integration tests covering the happy-path upgrade, offline validator recovery, LSU cancellation, roll-forward disaster recovery, consecutive LSUs, crash recovery, late validator onboarding, and sequencer health checks. Canton 3.5 Release Notes will be published once the release process is complete.
The Splice team has found an error in the Logical Synchronizer Upgrade (LSU) process in Splice 0.6.4.
This will require a one-week delay in the LSU rollout on DevNet and TestNet:
DevNet practice LSU run moves to June 3rd: 2026-06-03
DevNet LSU moves to June 10th: 2026-06-10
TestNet LSU moves to June 17th: 2026-06-17
Separately, Justin Peterson of Tradeweb, chair of the Foundation Tech & Ops committee, has asked to discuss and conclude on the question of weekday versus weekend upgrade timing at the next Tech & Ops committee meeting on June 2nd, 9 am US Eastern.
DA will wait for the conclusion of that meeting to update its recommendation for MainNet launch timing, which we'll do in this forum.
WC
Wayne Collier
May 21, 2026
Finalizing the date for the MainNet Logical Synchronizer Upgrade:
The topic of whether to hold the upcoming MainNet Logical Synchronizer Upgrade (LSU) during weekday or weekend hours will be discussed at the Technology & Operations meeting on June 2nd, at 9 am US Eastern.
Super Validator node owners are encouraged to attend. Amanda Martin can provide meeting details.
Best regards,
Wayne Collier
VA
Veronica Augustsson
Jun 5, 2026
7RIDGE/C7 votes in favour
Veronica
V E R O N I C A A U G U S T S S O N
/
P A R T N E R
7RIDGE IS A PRIVATE MARKETS ASSET MANAGER INVESTED IN TRANSFORMATIVE TECHNOLOGY FOR FINANCIAL SERVICES TO POWER THE GLOBAL ECONOMY
Signature for V e r o n i c a A u g u s t s s o n
Från: cip-vote@... <cip-vote@...> för Aman Goyal via lists.sync.global <aman.goyal=sbisecsol.com@...> Skickat: Thursday, 04 June 2026 10:30:16 Till: cip-vote@... <cip-vote@...> Ämne: Re: [cip-votes] CIP-0117: Logical Synchronizers
SBI votes in favor.
Show quoted message
On Thu, Jun 4, 2026 at 2:12 AM Amanda Martin via lists.sync.global <amanda=canton.foundation@...> wrote:
