Solana has advanced its largest consensus redesign since launch by activating Alpenglow on public testnet on Sept. 24 and on devnet a day later. The upgrade replaces TowerBFT with a new system called Votor and is intended to cut transaction finality to roughly 100 to 150 milliseconds.
The rollout marks a significant step, but the headline speed targets have not yet been demonstrated under full mainnet conditions. Other validator clients also still need to add support before any broader network transition can be considered complete.
Testnet and devnet complete the switch
According to Anza, the team behind Solana’s Agave validator client, the public testnet activation followed a 5,000-slot countdown that lasted about 17 minutes. The transition completed at slot 444,625,255, with the final TowerBFT block carrying 82% of stake before an Alpenglow genesis block took over finalization on that cluster.
Devnet completed its own migration on Sept. 25 at slot 504,148,999. The move was not the first live rehearsal of the design: a community cluster has been testing the change since May, including an earlier failed attempt that required a restart.
The underlying protocol change, SIMD-0326, was approved through governance in September 2025 with 98.27% of participating votes.
How Votor changes Solana’s confirmation process
Under the current design, validators cast votes as onchain transactions and wait through a 32-slot confirmation chain. The source article says those vote transactions account for about 75% of Solana’s transaction count.
Alpenglow shifts those votes offchain. Instead of writing them into blocks, Votor aggregates peer-to-peer votes into compact BLS certificates. Two confirmation paths run in parallel: a fast path that aims for about 100 milliseconds when 80% of stake agrees in one round, and a fallback path that targets about 150 milliseconds when 60% agrees first and a second round follows.
The security assumptions also change, with the model designed to tolerate 20% adversarial stake and another 20% being offline. Other parts of the network are not changing in this step: the Solana Virtual Machine, transaction format, programs and fees remain the same, and wallet users are not expected to migrate anything.
Faster finality creates new operational demands
A much shorter settlement window could affect how exchanges, custodians and bridges process deposits, because many of those systems are built around longer confirmation periods. Even if protocol-level finality drops sharply, outside infrastructure may take longer to adapt.
Anza has warned infrastructure providers to prepare for the new behavior. Indexers will need to track competing candidate banks until final certification, while Geyser and gRPC users are receiving a new bank_id field to help handle those distinctions.
The shift will also change how Solana activity appears in public metrics. Because validator votes are being removed from blocks, reported transaction counts are expected to fall even if actual user demand stays unchanged.
Mainnet timing remains open
Solana Foundation’s Ilan Gitter said the post-activation testnet cluster showed more than 25,000 transactions per second with 150-millisecond finality. Still, that figure comes from a test environment rather than mainnet.
The reported 100 to 150 millisecond targets are based on simulations and smaller-scale testing, not on a full public validator set processing live market activity. Client support is another outstanding issue: Firedancer and Frankendancer have not yet implemented Votor, leaving the current public transitions reliant on Agave 4.3.
Anza has said developers should keep testing integrations during an observation period before any move to mainnet-beta. No activation date has been confirmed. While Sept. 28 appears in Agave schedules as a window for resuming feature activations, the source article says it is not a confirmed Alpenglow launch date.
Source: news.bitcoin.com