Solana has begun deploying the Alpenglow upgrade to its public testnet, aiming to reduce finality time from around 12.8 seconds to 150 milliseconds. Finality is the point at which a transaction is considered irreversible. If this goal is achieved, exchanges, cross-chain bridges, and merchants could confirm transactions significantly faster. However, Alpenglow is currently only in the testing phase; the mainnet software update date mentioned in the schedule is not the launch date for the upgrade.
According to CoinDesk, a testnet is a copy of Solana that uses tokens with no monetary value. Developers can test the transition, find bugs, and restart the network without putting user funds at risk. This testing phase is particularly important because a consensus upgrade requires compatibility from the many computers and services operating the network.
Alpenglow changes how validators reach consensus
Alpenglow changes more than just the number of voting rounds. Anza’s blueprint consists of two components: Rotor, which distributes block data, and Votor, which handles voting and block finalization. According to a technical explainer by Helius, Rotor retains Turbine’s erasure-coded data shredding but shifts from a multi-layer tree structure to a single relay layer, aiming to reduce the number of hops data must make between nodes. This description explains the intended design, not measured mainnet results.
Votor features two parallel finalization paths. If a block receives votes representing at least 80% of stake in the first round, it can be finalized via the fast path. If it reaches at least 60% in the first round, the protocol opens a second round; when this round also hits the 60% threshold, the block is finalized via the fallback path. This design targets finality of around 100–150 milliseconds in simulations, depending on the voting path and latency between validators. Anza notes that simulation figures are based on current stake distribution and do not account for computational overhead. They are not mainnet performance measurements.
Another change is that consensus votes are no longer recorded as individual transactions for each slot. Instead, validators exchange votes off-chain; signatures are aggregated into a BLS certificate, and only the required certification portion is anchored on-chain. This could reduce vote transaction volume, processing load, and validator operating costs. Helius notes that the reward model for voting and data relaying has not yet been finalized, so the exact economic benefits for individual validators remain to be seen.
Alpenglow also removes Tower BFT, gossip-based vote propagation, and Proof of History from the consensus workflow. Under the design described by Helius, a slot cadence of roughly 400 milliseconds alongside local timers replaces the role of PoH’s hash clock in this section; this does not mean the network has an absolutely synchronized global clock. For RPC developers, Helius predicts that a single finality certificate could streamline the handling of confirmed and finalized commitment levels, but at the same time make real-time data updates and WebSocket distribution more important to consider. This is an expected outcome that needs to be tested as software and service integrations mature.
Fault-tolerance figures also require proper context. The 20+20 model described by Anza and Helius aims to maintain safety as long as adversarial stake does not exceed 20%, while preserving liveness even if an additional, independent portion of stake—up to 20%—goes offline or becomes unresponsive. This is a protocol-level theoretical guarantee, not a promise that the network cannot halt under any circumstance; if assumptions regarding stake ratios or message delivery are breached, risks remain.
These details add context to the news that Alpenglow has begun public testing, but they do not alter its deployment status: the upgrade still needs to be verified through testing and validator software coordination. For users, the benefit—if goals are achieved—will be that services receive final confirmation sooner, rather than wallets automatically sending transactions faster in all cases. Actual speed still depends on network latency, the software running on each validator, and how exchanges, bridges, or applications choose to wait for confirmation.
The initial test still relies on a single validator client
Moving Alpenglow to a public testnet checks coordination across a broader network, following more than four months of testing on a small network created specifically for the upgrade. Participating validators must install Agave 4.3, the primary Solana validator software maintained by Anza.
One key detail to note: two alternative validator clients, Firedancer and Frankendancer—built by Jump Crypto—do not yet support this initial Alpenglow test phase. These alternative clients were developed to reduce the network’s reliance on a single codebase, so that a bug in Agave would not simultaneously affect all validators. Therefore, the first test run will rely primarily on Agave.
This does not prove Alpenglow will encounter issues, but it is a limitation to watch when evaluating the trial. Validator client diversity is crucial for resilience against widespread failures. It remains to be seen when alternative implementations will join testing and how the network performs when multiple software client bases validate transactions simultaneously.
Anza’s schedule lists September 28 as the target date to enable features packaged with Agave 4.3 on mainnet. CoinDesk emphasized that this is not yet the launch date for Alpenglow. At the time the report was updated, Anza’s tracker still listed the testnet rollout as pending, so there is no confirmed release timeline.
The significance lies in fast confirmation and reliability
For everyday users, the change may not appear as a new button. The value of faster finality lies mainly behind the scenes: applications know sooner that a transaction is complete, rather than keeping users in a pending state. This could support faster payments and asset transfers, but the actual real-world improvement depends on how services integrate the change and set their confirmation rules.
Therefore, the key signal to watch is not just whether Alpenglow reaches the 150-millisecond benchmark in testing. More important is how stably the public network operates, how other validator clients join in, and when the development team issues an official mainnet rollout schedule. For now, this remains an upgrade under testing, not an active change on mainnet.