Solana Replaces TowerBFT as Alpenglow Goes Live on Mainnet

Solana activated its Alpenglow consensus protocol on mainnet on Oct. 21, replacing TowerBFT and targeting transaction finality in about 150 milliseconds, down from roughly 12.8 seconds. The Solana Foundation’s upgrade page says the switch began in epoch 1064, with Alpenglow consensus taking over at slot 459,653,000. The change aims to make transactions irreversible much sooner; it does not make the network execute transactions faster.

What changed in the move from TowerBFT to Alpenglow?

Alpenglow changes how validators agree on blocks: they now send votes directly to one another and bundle them into certificates, instead of putting vote transactions on the chain. The Foundation says this lets a block become final after one or two rounds of voting. Under TowerBFT, finality required votes to accumulate across 32 slots and took about 12.8 seconds.

That difference matters for services that wait for finality before treating a payment or exchange deposit as settled. The Block, citing Anza, reported that the new protocol condenses the previous two-step confirmation process into one and targets about 150 milliseconds. That is roughly 99% less time than the stated TowerBFT baseline, but it remains a target, not a guarantee that every transaction will finalize in precisely that interval.

The timing also needs to be separated from Solana’s block production. The Foundation says the 150 milliseconds measures how long a transaction takes to become final, not how often blocks are produced. Slot times were cut separately from 400 milliseconds to 200 milliseconds in four stages completed in October. Alpenglow changes the agreement process; it does not change the speed at which transactions execute.

What does the upgrade leave unchanged?

Transaction execution, the Solana Virtual Machine, transaction formats and fee mechanics remain as before, according to the Foundation. Wallets and applications do not need a change to send transactions or run programs. The gain is quicker certainty about a transaction’s status; the boundary is that this does not itself increase throughput or alter what a transaction costs.

There are operational trade-offs for validators and infrastructure providers. Vote transactions are no longer included in blocks, so metrics that counted them will show fewer transactions even if user activity does not fall. Developers streaming block data must also account for bank identifiers and the possibility of multiple candidate blocks in a slot. The Foundation says validators need an Agave-based client and at least 0.8 SOL above the vote account’s rent-exempt minimum to pay the validator admission ticket each epoch. Firedancer and Frankendancer were not supported for the migration.

What should users watch after the switch?

The next test is whether the finality target holds under live network conditions and whether the client and data changes are handled cleanly by validators, applications and indexers. Anza told The Block that Alpenglow reached mainnet-beta at slot 459,653,000; the Foundation’s account says the protocol handoff followed a 5,000-slot transition after epoch activation.

Alpenglow also arrives in phases. Its voting protocol, Votor, is live; Rotor, intended to replace the Turbine block-propagation system, is planned for a later release with no schedule yet, according to the Foundation. For now, the key signals are observed finality times, validator participation and whether downstream tools adapt to the changed block and vote data. Those will show whether faster settlement translates into a practical improvement without creating new reliability or integration costs.

Sources and documents

• Solana Foundation’s upgrade page — solana.com