Solana activates Alpenglow, replacing its consensus protocol

Solana activated Alpenglow on mainnet on Oct. 21, replacing the TowerBFT consensus protocol that had run since the network’s 2020 launch. The Solana Foundation’s Alpenglow documentation says the live first phase, Votor, targets finality in roughly 150 milliseconds, down from about 12.8 seconds under TowerBFT.

The change affects how validators agree that a block is final. It does not change how programs execute or how users sign and send transactions. Solana’s SVM, transaction formats and fee mechanics remain the same.

How does Alpenglow make transactions final faster?

Alpenglow replaces TowerBFT’s vote transactions with direct validator-to-validator votes, which validators aggregate into certificates. Under TowerBFT, a block became final after enough votes accumulated over 32 slots. With Votor, it becomes final after one or two rounds of voting, according to the Foundation.

The protocol activated at the start of epoch 1064, at approximately 13:36 UTC. Solana’s documentation identifies slot 459,652,999 as the genesis block for the handoff, certified by votes from 446 of the network’s 654 validators; Alpenglow consensus began at slot 459,653,000. Decrypt’s report on the mainnet activation also describes the switch as a live-network handoff.

The roughly 150-millisecond figure is a finality target: how long until a transaction can no longer be reversed. It is not Solana’s block interval. Slot times were reduced separately, from 400 milliseconds to 200 milliseconds in four stages completed in October, the Foundation says.

What changes for wallets, apps and data services?

Wallet users do not need to migrate. Signing, sending and approving transactions work as before, and applications that only send transactions or read account state require no change. Faster finality means apps can treat transactions as settled sooner; the Foundation points to near-instant confirmation at a point of sale as a possible use.

Infrastructure that reads block data has compatibility work. Vote transactions no longer appear in blocks, and Proof of History no longer paces block production, so tick entries are removed from the shred stream. Geyser and gRPC consumers must also account for multiple candidate banks in a slot: Agave 4.3 adds a bank_id field, and stream processors should buffer by both slot and bank ID. When merging data from multiple providers, the Foundation cautions that bank IDs are node-local; consumers should reconcile on blockhash instead.

Alpenglow also makes confirmed and finalized describe the same state. The Foundation advises new code to use finalized; it says the confirmed commitment will be removed in a later release.

What must validator operators do, and what remains to come?

Validators must run an Agave-based client: Agave, Jito-Solana or Harmonic Salsa v4.3.2. Firedancer and Frankendancer were not supported for the migration. 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. If the fee is unpaid, the validator will not vote or produce blocks in the next epoch.

Alpenglow’s rollout has a second phase, Rotor, which is planned for a later release and has no scheduled date. Votor, now live, changes voting and finality. Rotor is intended to replace Turbine, the protocol that spreads block data across the network. The mainnet activation therefore completes the consensus handoff, while the planned block-propagation change remains ahead.

Sources and documents

• Solana Foundation’s Alpenglow documentation — solana.com
• Decrypt’s report on the mainnet activation — decrypt.co