Solana Schedules Alpenglow Consensus Switch for Wednesday

Solana is scheduled to begin switching its mainnet consensus to Alpenglow on Wednesday, replacing TowerBFT’s on-chain validator votes with certificates designed to finalize blocks in one or two voting rounds. The CoinDesk report on the scheduled upgrade says the target is roughly 150 milliseconds; Solana’s Alpenglow upgrade page puts the current TowerBFT finality baseline at 12.8 seconds. That target is a design goal, not a measured mainnet result.

When does TowerBFT hand over to Alpenglow?

The switch is scheduled for epoch 1064, which the Solana Foundation estimates will start at about 13:20 UTC on October 21. That epoch boundary does not itself start Alpenglow consensus: TowerBFT remains active for 5,000 slots, after which Alpenglow takes over at slot 459,653,000. The Foundation says epoch timing can drift with slot timing, so the slot is the operative boundary, not the clock estimate.

The consensus change is the first phase of Alpenglow. The Foundation identifies that phase as Votor, which ships in Agave 4.3. The later Rotor phase is planned to replace Turbine, Solana’s block-data propagation protocol, but does not have a scheduled release. The Wednesday activation therefore changes how validators agree on blocks; it does not complete every component described under Alpenglow.

How does Votor change block finality?

Under TowerBFT, validators send votes as transactions, and the votes accumulate on-chain over 32 slots before a block becomes final. Votor removes those vote transactions from blocks. Validators send votes directly to one another and aggregate them into certificates; a block becomes final when the required certificate forms after one or two rounds of voting.

The Foundation’s roughly 150-millisecond figure describes the target time for a transaction to become final, not the interval between blocks. Solana’s slot time was reduced separately, from 400 to 200 milliseconds in stages completed in October. Alpenglow also leaves transaction execution unchanged: the Solana Virtual Machine, programs, transaction formats and fee mechanics continue to operate as before.

The change affects what block data represents. Vote transactions will no longer contribute to transaction counts, so headline totals that include votes will fall even if user activity does not. Proof of History will no longer pace block production, and tick entries will leave the shred stream. Applications and indexers that rely on those data need to account for the changed block and timestamp behavior.

What must validators have ready for the transition?

The Foundation says validators must run an Agave-based client at version 4.3.2 and hold at least 0.8 SOL above the rent-exempt minimum in the vote account for the Validator Admission Ticket. The first fee is charged at the start of epoch 1064 and pays for participation in the following epoch; a validator that cannot pay will not vote or produce blocks in that next epoch. Firedancer and Frankendancer are not supported during the migration, according to the Foundation’s operator instructions.

Alpenglow also changes the consensus fault model. The Foundation lists tolerance for 20% malicious stake plus 20% offline stake. Those are protocol limits, not a guarantee that the network will remain unaffected under every failure pattern. CoinDesk reported that test-network work included six restarts and a failed migration that was rolled back before a later migration succeeded. That history informs the planned mainnet rollout, but it does not establish how the transition will perform under mainnet conditions.

References

• CoinDesk report on the scheduled upgrade — coindesk.com
• Alpenglow upgrade page — solana.com