Solana Begins Testing Alpenglow, the Upgrade That Would Cut…

Solana's core developer Anza has begun public testnet testing of Alpenglow, the largest consensus overhaul in the network's history, replacing the TowerBFT voting mechanism it has used since launch with a new protocol called Votor. The upgrade targets finality of roughly 150 milliseconds, down from the current 12.8 seconds, and moves validator voting entirely off-chain to free the block space that on-chain vote transactions currently consume.

What Activates and What a Feature Gate Means

Anza published the Agave 4.3 release schedule on 12 August, targeting 28 September as the date when it resumes processing queued feature gates on mainnet, and all dates on that schedule are marked tentative. A feature gate is Solana's mechanism for activating protocol changes at epoch boundaries: a feature is registered as a unique on-chain account. When enough validators signal support by upgrading to software that contains the feature, a coordinated activation flips consensus rules network-wide at the start of an epoch.A correction issued on 23 September by CoinDesk clarified that 28 September is the feature-gate processing date, not the Alpenglow activation date. The upgrade must first pass observation periods on testnet and devnet before reaching mainnet-beta, and Alpenglow entered public testnet testing on 23 September. Agave 4.2 shipped the complete Alpenglow codebase earlier, with activation withheld, allowing the code to undergo adversarial review before any live deployment.The staged validator migration followed a separate timeline: 10% of validators on 8 September, 25% on 14 September, and general adoption recommended on 21 September, after which Agave 4.2 becomes unsupported. A 50,000 SOL bug bounty ran from 5 to 19 August with adjudication through 2 September, drawing over 300 submissions across four repositories covering the voting engine, certificate types, BLS signature verification, and stake-threshold checks.

Votor's Two-Round Design: 80% Fast Path, 60% Fallback

Votor replaces TowerBFT's 32-round confirmation chain with a direct voting protocol. Instead of validators recording votes as on-chain transactions, which currently account for roughly 75% of all Solana transactions according to Chainstack documentation, validators exchange signed messages directly and produce compact BLS12-381 certificates anchored on-chain.The protocol runs two concurrent finalization paths, and the first is the fast path, which finalizes a block in a single round when 80% or more of the stake participates. The slow path requires two rounds at 60% stake participation per round and handles notarisation and skip decisions when participation drops below the fast-path threshold. Whichever threshold is crossed first finalises the block. Test cluster data showed 96% of blocks achieving fast-path finalisation at a median of 214 milliseconds, according to Anza's internal benchmarks.

Finality Maths and What It Changes for Payments and Market-Making

Under TowerBFT, finality requires validators to confirm a slot across a 32-round chain, producing an effective wait of roughly 12.8 seconds. Alpenglow compresses this to a target of 100 to 150 milliseconds for certificate finality, a reduction that Anza described as "faster than a Visa card authorisation."The practical implications land in two areas. Payment applications on Solana currently require merchants or processors to wait multiple seconds for settlement confirmation, a gap that sub-second finality would close to the point where on-chain settlement competes directly with card network authorisation speeds. Market makers, who price the risk of a transaction reversing during the confirmation window, could tighten spreads if finality drops below the threshold at which reversal risk becomes negligible. The move of vote transactions off-ledger also frees the block space they currently occupy. Helius estimates that validator operating costs could fall from approximately 1 SOL per day to roughly 0.8 SOL per day under a fixed Validator Admission Ticket model of 1.6 SOL per epoch, potentially lowering the minimum profitable stake from roughly 4,850 SOL to around 450 SOL.

Fault Tolerance Shifts From 33% to 40%

TowerBFT maintains safety as long as no more than 33% of the stake is controlled by adversarial validators. Alpenglow introduces what Anza calls a "20+20 model": the protocol tolerates up to 20% adversarial stake plus an additional 20% of validators that are offline or crashed, yielding approximately 40% total non-responsive tolerance. The pure Byzantine fault threshold drops from 33% to 20%, but the addition of stronger crash-fault tolerance means the network can survive larger outages without halting, a scenario Solana has faced in past incidents.A coordinated adversarial attack by a minority holding just above 20% of the stake could theoretically compromise safety under the new model, whereas the same attacker would need above 33% under TowerBFT. Anza's position is that real-world network failures more closely resemble crash faults than coordinated Byzantine attacks, making the 20+20 split a more practical safety model for a production network.

What Can Still Slip and How to Watch for It

The Firedancer and Frankendancer validator clients do not yet support the testnet migration, meaning initial activation runs entirely through Agave clients. If Alpenglow reaches mainnet before Firedancer adds support, the network would temporarily lose the client diversity it has spent two years building.Infrastructure providers face their own adjustment. RPC providers and block explorers must update indexing systems to account for the elimination of on-chain vote transactions, a change that alters the transaction data they serve to applications. The Ripple XRPL batch upgrade, the other major ledger shipping a consensus-level change this month, faces a similar infrastructure coordination challenge. Validators that have not upgraded to Agave 4.3 by the time feature gates resume processing risk forking off the network.  The observation periods on testnet and devnet will determine whether Alpenglow's activation proceeds on its current trajectory or is delayed to address issues surfaced during testing.