The Solana Foundation has scheduled the network's Alpenglow consensus transition for epoch 1064, expected to start on October 21 at approximately 15:00 UTC. The change would replace TowerBFT, the voting system Solana has used since launch, with a certificate-based protocol designed to make blocks final in roughly 150 milliseconds. The time is an estimate rather than a fixed appointment because epoch boundaries move with slot timing, and the Foundation's status page still showed mainnet as not activated when this article was verified.

Votor changes how validators agree

Alpenglow's first phase, called Votor, moves validator votes out of ordinary onchain transactions. Validators will exchange votes directly, aggregate them into certificates and finalize a block after one or two voting rounds. Solana says execution remains unchanged: the Solana Virtual Machine, programs, transactions and fee mechanics continue to operate as before. The advertised 150-millisecond figure is a finality target, not a new block time, and actual performance will depend on network conditions.

Related reporting: Solana Activates 200ms Slots as Validator Clock Speeds Up

The switch is staged inside the epoch

The feature gate is due to activate at the start of epoch 1064, but the cluster will continue running TowerBFT for the first 5,000 slots, about 18 minutes at the expected pace. Alpenglow is then scheduled to take over at a designated migration slot. That distinction matters for anyone monitoring the event: feature activation alone will not prove that the new consensus is producing finalized blocks. Operators can check the cluster's Alpenglow genesis certificate through the new RPC method once the switch has completed.

Validators face a software and funding deadline

Before the epoch begins, validators must use Agave, Jito-Solana or Harmonic Salsa software built on Agave 4.3.0. Firedancer and Frankendancer are not supported during the migration, so operators using those clients will need a temporary compatible setup. Voting transaction fees will disappear under Alpenglow, but each admitted validator will instead pay a flat 0.8 SOL Validator Admission Ticket from its vote account each epoch. The first charge at epoch 1064 pays for participation in the following epoch.

Apps and data services may see different metrics

Wallet users are not expected to take action, but infrastructure providers have work to do. Removing vote transactions could make Solana's headline transaction count fall even if user activity is unchanged. Streaming and indexing services also need to handle multiple candidate banks within a slot and should reconcile data from different providers by blockhash rather than by a node-local bank identifier. For merchants and bridges, faster finality could shorten the wait for a strong assurance that a payment cannot be reversed, if the live network reaches the target.

A major upgrade with execution risk

Alpenglow has already run on testnet and devnet, but mainnet migration remains a future event. The Solana improvement proposal describes the consensus replacement as incompatible with the old voting logic and identifies implementation risk as its main drawback. The later Rotor phase, which would replace Solana's Turbine block-propagation system, is not part of the October switch and has no scheduled date. The immediate test will therefore be narrower: whether Votor activates cleanly, validators stay coordinated and observed finality approaches the Foundation's sub-second target.

Sources

AI-generated editorial image; not a photograph of the reported event. Prepared with AI assistance and source verification.