Solana schedules Alpenglow consensus switch for Oct. 21

Solana has scheduled Alpenglow, its replacement consensus protocol, to begin activating on Oct. 21, with a target of roughly 150 milliseconds for transaction finality. The CoinDesk report on the schedule says the change replaces TowerBFT and moves validator votes out of blocks.

The Solana Foundation’s Alpenglow upgrade documentation places activation at epoch 1064, expected to start around 15:00 UTC. That is the feature’s activation point, not the instant consensus changes: validators will continue using TowerBFT for the epoch’s first 5,000 slots, about 18 minutes, before Alpenglow takes over.

How does Alpenglow finalize a block?

Alpenglow’s first phase, Votor, replaces TowerBFT’s on-chain vote transactions with direct messages between validators. Validators aggregate those votes into certificates, and a block becomes final after one or two voting rounds.

Under TowerBFT, validators cast votes as transactions, and enough accumulated votes across 32 slots establish finality. The Foundation puts current finality at about 12.8 seconds. With Votor, direct validator votes and certificates shorten the consensus path. The 150-millisecond figure is a target for finality, not a new block interval; Solana’s slot time was separately reduced to 200 milliseconds.

Alpenglow changes consensus, while transaction execution remains the same. The Solana Virtual Machine, transaction formats, programs and fee mechanics do not change. The Foundation says wallets and applications continue to work as before.

What changes when vote transactions leave blocks?

Validator votes will no longer appear as transactions on-chain. That can lower reported transaction counts at activation even if user activity stays flat, so analytics systems that count every transaction will need a new baseline.

The switch also changes validator costs. Under TowerBFT, voting costs about 1 SOL per epoch in vote transaction fees. Under Alpenglow, validators instead pay a flat 0.8 SOL per epoch through the Validator Admission Ticket, taken from the vote account. Operators must keep that amount above the account’s rent-exempt minimum; if the fee is not paid, the validator does not vote or produce blocks in the following epoch.

Which validators need to prepare?

Before epoch 1064, operators must use an Agave-based client built on version 4.3.0. The Foundation lists Agave, Jito-Solana and Harmonic Salsa as supported for the migration. Firedancer and Frankendancer are not supported during the switch, so their operators must change clients temporarily.

Infrastructure that reads validator streams also faces changes. Agave 4.3 adds a bank_id field to Geyser events because a slot can contain more than one candidate block. Stream consumers that key data only by slot risk merging candidates; the Foundation says they should buffer by both slot and bank ID, then keep the bank that reaches confirmation.

Alpenglow’s later Rotor phase is planned to replace Turbine, Solana’s block propagation protocol, but it is not part of this activation. The Oct. 21 migration is the consensus change: Votor replaces TowerBFT, while block data propagation remains on its existing path for now.

Sources and documents

• CoinDesk report on the schedule — coindesk.com
• Alpenglow upgrade documentation — solana.com