Solana Activates Alpenglow, Replacing TowerBFT

Solana activated Alpenglow on mainnet on October 21, replacing TowerBFT with a new consensus protocol that targets finality in roughly 150 milliseconds. The Solana Foundation’s Alpenglow documentation says the change affects how validators agree on blocks, while transaction execution, fees and programs remain the same.

The activation began at the start of epoch 1064, at approximately 13:36 UTC. The network continued running TowerBFT for 5,000 slots before handing consensus to Alpenglow at slot 459,653,000. The Block’s report on Anza’s announcement also reported the live-network switch and the target reduction from about 12.8 seconds to 150 milliseconds.

How does Alpenglow reach finality faster?

Alpenglow replaces TowerBFT’s vote-transaction path with Votor, a protocol in which validators send votes directly to one another and aggregate them into certificates. Under TowerBFT, validator votes appeared as transactions, and blocks became final after enough votes accumulated over 32 slots. Under Votor, a block can become final after one or two rounds of voting.

The handoff used a certified genesis block. Solana’s documentation says 446 of the network’s 654 validators voted on slot 459,652,999, the final TowerBFT block; Alpenglow consensus began on the next slot. The feature gate activated at the epoch boundary, but that did not itself switch consensus: TowerBFT remained active during the 5,000-slot transition window. The genesis certificate marked the handoff.

The roughly 150-millisecond figure is a finality target, not a block interval. Slot time was reduced separately, from 400 milliseconds to 200 milliseconds in stages. Faster finality means applications can receive the stronger finalized state sooner; it does not mean a new block is produced every 150 milliseconds.

What changes for validators and block data?

Validators needed an Agave-based client for the migration. The Foundation lists Agave, Jito-Solana and Harmonic Salsa at version 4.3.2; Firedancer and Frankendancer were not supported for the switch. Voting validators also need at least 0.8 SOL above the vote account’s rent-exempt minimum to pay the Validator Admission Ticket fee each epoch. Without that fee, a validator does not vote or produce blocks in the following epoch.

Because votes are no longer transactions, they disappear from blocks. Transaction counts and TPS measures that included vote transactions will fall even if user activity does not. Validator participation data now comes from certificates in the block footer, rather than Vote program instructions in the transaction stream.

Streaming consumers also need to account for multiple candidate banks in a slot. Agave 4.3 adds a bank_id to Geyser events so indexers can buffer by (slot, bank_id) and retain the bank that reaches confirmation. When combining feeds from different providers, bank_id is local to each stream; consumers must reconcile banks by blockhash.

Is the whole Alpenglow upgrade live?

Votor is live; Rotor is not. The Foundation describes Rotor as a later phase that will replace Turbine’s block-data distribution protocol with a single relay layer, but it has no scheduled release. Alpenglow’s mainnet activation therefore changes consensus and finality now, while the planned change to how block data spreads across the network remains future work.

Sources and documents

• Solana Foundation’s Alpenglow documentation — solana.com
• Block’s report on Anza’s announcement — theblock.co