Canton closes CantonBFT migration window without public performance data

Canton Network’s scheduled MainNet migration to CantonBFT passed its operating window on October 10, and custody provider BitGo marked its associated service notice resolved at 14:45 UTC that day. The records indicate that the network-wide maintenance period ended, but they do not provide a formal post-migration assessment of validator participation, transaction performance or realized downtime.

The change matters because CantonBFT is the ordering service responsible for helping the Global Synchronizer’s operators agree on the sequence of activity. Moving that component onto Canton’s native Byzantine-fault-tolerant implementation changes core infrastructure beneath applications used for tokenized assets and settlement. It does not, by itself, establish higher throughput, eliminate operational failures or change the legal status of assets using the network.

What the operating records establish

A Canton Network forum announcement dated October 5 said MainNet would undergo a Logical Synchronizer Upgrade to adopt CantonBFT. The notice set a topology freeze from 13:00 UTC on October 9 until 13:00 UTC on October 10. Ordinary Daml transactions were expected to continue during that 24-hour interval, with a pause lasting a few minutes around the final switchover.

BitGo opened a matching status notice at 13:13 UTC on October 9. It described the work as a Canton Foundation network-wide upgrade rather than a BitGo-specific change and warned that wallet initialization would be unavailable during the topology freeze even while transfers continued. BitGo marked the incident resolved at 14:45 UTC on October 10, one hour and 45 minutes after the scheduled freeze ended.

That status change is evidence that BitGo’s affected Canton service returned to its normal state. It is not an independent measurement of the entire network, and BitGo did not report the actual transaction-pause duration, failed-transaction count or validator availability during the transition. Coinburn found no separate Canton Foundation post-migration report containing those measurements by publication time.

How the migration was designed

Canton introduced Logical Synchronizer Upgrades on MainNet earlier in 2026. Its published design runs successor synchronizer infrastructure alongside the existing system before an onchain-governed switch. Validators supporting both versions can then move to the successor while applications retain the same logical synchronizer identity and transaction history.

Canton’s technical explanation says legacy synchronizer infrastructure remains available for 30 days after a switch before decommissioning. That period is a recovery and operational feature of the upgrade design; it should not be read as evidence that every operator completed this particular migration at the same moment.

The public Canton software record also shows that CantonBFT was being actively hardened ahead of deployment. Canton version 3.5.19, released September 23, included fixes for memory handling, peer-to-peer connection behavior and retransmission-message sizing. Its release record lists support for Canton protocol versions 34 and 35. Those engineering notes establish what the software addressed, not how the October 10 MainNet deployment performed under production load.

What remains unverified

The available evidence supports a narrow conclusion: the scheduled migration window occurred, Canton and BitGo identified CantonBFT as its purpose, and BitGo subsequently resolved its service notice. It does not establish zero downtime, successful upgrades by every validator, improved throughput or stronger realized security.

The next meaningful evidence would be a Canton Foundation completion notice, updated network configuration, operator telemetry or a public incident report. Until then, the migration should be treated as an infrastructure deployment whose network-wide performance remains unquantified, not as proof of a measured improvement.