A Chainflip upgrade can't just push to prod because there is no single server to push to. The protocol runs on about 150 independent validators, so every release goes through the Perseverance testnet, then a window where operators upgrade their own nodes, then an on-chain runtime vote before anything changes on mainnet. That sequence decides when new chains reach the app where you swap native assets across chains, and what you'll see on Chainflip Scan during release week.
How a Chainflip upgrade works, step by step
A release bundles two things: a new runtime for the Chainflip State Chain and a new version of the engine software each validator runs next to its node. Both have to line up, so the order of operations matters. The pending BNB Chain release and the earlier v1.8 upgrade show that order in practice.
Step 1: Perseverance testnet
Every change lands on Perseverance first, which the Chainflip docs describe as the persistent testnet. New chains, assets and features run there under live conditions long enough to surface problems that internal testing misses. For BNB Chain, that phase started when Chainflip added it to testnet on September 9 (Coindar).
Step 2: Operators upgrade their own nodes
Once a build is ready, independent operators upgrade their own infrastructure. Chainflip's post on its decentralized validator infrastructure puts the active set at 150, and Chorus One describes 150 as the cap on the authority set, so "about 150" is the accurate way to say it. Nobody at Chainflip Labs can log into those machines and do the upgrade for them.
Some releases ask for more than a new binary. Ahead of v2.3, the validator setup docs require every validator to add a [bsc] section to Settings.toml and send BNB to its validator address. Without a working BSC RPC endpoint, the engine won't start after the upgrade, which means each operator has to source an endpoint, fund the address and test the config on their own schedule.
Step 3: The runtime vote
The new runtime goes live through an on-chain governance vote on the State Chain, and it comes last on purpose. Applying it before operators are ready would leave the network running rules its engines don't yet understand. Once the vote passes, the upgrade executes on-chain and every node moves to the new runtime at the same block.
Step 4: Apps and integrators catch up
During the v1.8 release, the swapping app went into maintenance mode, so swaps were unavailable while the upgrade ran (Chainflip on X). Liquidity providers were told to upgrade their LP API to 1.8 only after the runtime upgrade, once Chainflip confirmed it was safe. That release added vault swaps, including Bitcoin vault swaps, plus cross-chain aggregation.
Worked example: two swaps during release season
Say you planned to sell 0.5 native BTC for USDT on Ethereum while the v1.8 runtime upgrade was running. You'd have opened the app, seen maintenance mode, and waited until the upgrade completed. When the app came back, the same 0.5 BTC swap ran on the new runtime, and you could follow it on Chainflip Scan as usual.
Now take someone holding 2,000 USDT on Tron who wants USDT on BSC. That route can't run until operators have BSC configured and the v2.3 runtime vote passes on mainnet. Until then, the realistic move is to swap USDT on Tron to USDT on Ethereum, Arbitrum, Solana or Polkadot Assethub.
Why the release process matters
The slow parts of this process are the cost of decentralization. Chainflip uses a decentralized custody model where funds are secured by validators and there is no centralized custodian. If one team could push code to every node on its own, that team would be the custodian in practice.
The process also protects volume that's already flowing. Chainflip has processed $10.22B in all-time swap volume (Chainflip Scan), and every release has to land without breaking existing Bitcoin, Ethereum, Solana, Polkadot, Arbitrum and Tron routes. Testing on Perseverance and staging operator upgrades is how new chains get added without putting the existing ones at risk.
Limits and risks of this approach
The obvious cost is speed. A centralized exchange can list a chain as soon as its own engineers finish the integration. Chainflip has to wait for testnet results, for about 150 operators to prepare their nodes, and then for the vote.
BNB Chain shows this clearly. It has been on testnet since September 9, and the docs already describe v2.3 as introducing BSC with BNB and USDT, yet it is not live on mainnet. We're not putting a date on it, because the date depends on testing and operator readiness rather than a marketing calendar.
A chain appearing in the docs or on testnet is not the same as it being swappable. Until the v2.3 runtime vote passes on mainnet, BNB and USDT on BSC are not available on Chainflip, and only USDT is planned on BSC, not USDC. cbBTC support on Ethereum is set to ship in the same release.
Runtime upgrades can also bring a short window where swaps pause, as v1.8's maintenance mode showed. Every operator-side prerequisite adds coordination risk too, which is why the docs flag requirements like the BSC setup well before the upgrade.
How to use Chainflip during an upgrade
Most of the time, upgrades won't affect you. When one is scheduled, a few habits help:
Follow Chainflip on X and the blog for upgrade announcements before planning a large swap.
If the swap app shows maintenance mode, wait for it to clear instead of looking for workarounds.
If you started a swap before maintenance began, check its status on Scan rather than resubmitting. This walkthrough on reading a swap in Chainflip Scan covers what each stage means.
If you run an LP integration, upgrade your LP API only after Chainflip confirms the runtime upgrade is complete.
If you operate a validator, complete prerequisites like the [bsc] config and BNB funding early, not on upgrade day.
Check the supported chains list before planning a route that depends on an upcoming release.
Pushing to prod on Chainflip means testnet first, then about 150 independent operators, then a runtime vote. That takes longer than a centralized release, and it's the reason no single party controls the network or the funds it secures.
BNB Chain will arrive the same way when it's ready. In the meantime, you can swap native BTC, ETH, SOL, DOT, TRX and stablecoins on Chainflip across every chain that's already live.
Resources
Swap - Start swapping native assets
Lending - Borrow against native Bitcoin
Blog - Product updates and announcements
Chainflip Scan - Track swaps and network activity
Website - Explore Chainflip
Earn with Chainflip:
Boost - Earn fees by providing single-sided liquidity with no IL risk
Stablecoin Strategies - Deposit stablecoins and earn optimized yields
Provide Liquidity - Supply assets to Chainflip's liquidity pools
Stake FLIP - Delegate FLIP and earn staking rewards
Find us:
FAQ
Can I swap on Chainflip while an upgrade is happening?
During some runtime upgrades, the swap app enters maintenance mode and swaps are unavailable, as happened with v1.8. Watch Chainflip's X account and blog for announcements, and use Chainflip Scan to check any swap you started before maintenance began.
What is Perseverance?
Perseverance is Chainflip's persistent testnet. New releases, chains and assets run there before they're proposed for mainnet.
Is BNB Chain live on Chainflip?
Not yet. BNB Chain was added to testnet on September 9 and the docs describe v2.3 as introducing BSC with BNB and USDT, but mainnet support depends on operator upgrades and the runtime vote. There is no confirmed date, and only USDT is planned on BSC, not USDC.
Why can't Chainflip Labs upgrade the validators itself?
Validators are run by about 150 independent operators on their own infrastructure. That separation is what makes the decentralized custody model work, so each operator upgrades their own node.
When does the runtime vote happen?
The runtime vote comes after testnet and after operators have upgraded their nodes. Applying the new runtime earlier would leave validators running engines that don't support the new rules.
