Solana has entered the final stage of its Alpenglow mainnet-beta migration, marking the network’s planned transition from TowerBFT to the new Votor consensus protocol. The upgrade targets roughly 150-millisecond transaction finality, compared with approximately 12.8 seconds under the previous consensus architecture.
According to the Solana Foundation’s Alpenglow upgrade documentation, the feature gate activates with epoch 1064 before the actual consensus handoff occurs several thousand slots later. Votor takes control at migration slot 459,653,000, after which validators begin using Alpenglow certificates rather than TowerBFT’s on-chain voting process.
The transition follows the previously announced October 21 Alpenglow rollout and successful deployments across Solana’s public testing environments. Testnet and Devnet had already moved to Alpenglow before the mainnet migration, providing operational evidence for the consensus system without establishing how it would perform under production workloads.
Votor Moves Solana Validator Votes Off-Chain
Votor fundamentally changes how validators agree on blocks. Validator votes are sent directly between participants and aggregated into BLS-signed certificates instead of appearing as ordinary blockchain transactions, reducing the consensus traffic previously included in Solana’s raw transaction statistics.
Under Alpenglow’s fast-finalization path, a block can finalize after one voting round when at least 80% of stake supports it. A slower two-round path can finalize blocks using 60% stake thresholds, allowing the protocol to preserve liveness when the fast path is unavailable.
Removing vote transactions will also change how Solana’s headline activity metrics appear. Raw TPS and transaction counts can fall substantially without any corresponding reduction in application activity, because consensus votes that were previously counted as transactions disappear from blocks.
That accounting distinction has become increasingly relevant as Solana has already posted record non-vote transaction activity. Non-vote transaction metrics provide a cleaner baseline for evaluating user and application activity after Alpenglow, although they can still include failed transactions and automated traffic.
The protocol change does not alter the Solana Virtual Machine, smart contract execution or normal transaction formats. Alpenglow replaces the consensus layer rather than the execution environment, allowing most applications and ordinary users to continue operating without migrating contracts or changing transaction construction.
Validator Requirements Change With Alpenglow
Validator operators face more direct operational changes. Solana requires an Agave 4.3.2-based client for the migration, with Agave, Jito-Solana and Harmonic Salsa supported while Firedancer and Frankendancer are excluded from this specific transition.
Alpenglow also introduces the Validator Admission Ticket, or VAT. Each voting validator must maintain at least 0.8 SOL above the rent-exempt minimum in its vote account, with the fee charged every epoch and burned rather than paid through recurring on-chain vote transactions.
The migration delivers only the Votor portion of the broader Alpenglow architecture. Rotor, which is designed to replace Solana’s Turbine block-distribution system, remains scheduled for a later phase with no confirmed activation date.
Alpenglow previously reached Devnet and Testnet alongside Solana’s expanding network activity, but mainnet provides the first production environment for evaluating its performance claims. The approximately 150-millisecond finality figure remains a protocol target until sustained mainnet measurements demonstrate that level of performance under real network conditions.
The immediate milestone is therefore not simply the activation date but the successful formation of the Alpenglow genesis certificate at slot 459,653,000. Once that certificate forms, TowerBFT gives way to Votor and Solana begins operating under its first major consensus replacement since launch.