Solana Prepares to Test 150ms Finality as Alpenglow Awaits Testnet Activation
Key Takeaways
- •Anza placed Alpenglow, identified as SIMD-0326, under "Pending Testnet Activation" in its feature-gate tracker updated on September 22, with no activation epoch or date published.
- •Alpenglow targets reducing Solana's finality from approximately 12.8 seconds to around 150 milliseconds, a roughly 85-fold speedup, according to Solana's official upgrade documentation.
- •The upgrade introduces Votor, which replaces TowerBFT's transaction-based voting with direct vote exchange and finalization certificates that can complete in one or two voting rounds.
- •The current feature-gate entry assigns Alpenglow to Agave v4.30 and marks the Firedancer and Frankendancer clients as unsupported, with no dates for adding their support.
- •Faster finality could benefit exchanges, bridges, and merchants, but service release timing and potential differences between testnet and mainnet conditions mean the 150ms target does not guarantee end-to-end payment speed.

Solana is preparing to put a dramatically faster finality target to the test on its public testnet. Anza, the development studio behind the Agave validator client, placed Alpenglow under “Pending Testnet Activation” in its official feature-gate tracker, which was updated on September 22. The listing means the feature now awaits public testnet activation, with no activation epoch published so far.
The entry identifies the feature as “SIMD-0326: Alpenglow: new consensus algorithm” and assigns it to Agave v4.3.0. The fields for its testnet activation epoch and activation date remain empty. Agave v4.3.0 is also listed as the next expected testnet version floor — the oldest software release validators can run while remaining compatible with that network. Anza describes its schedule as tentative, so the listing is not a guaranteed activation date.
What the 150ms Target Actually Measures
According to Solana's official upgrade documentation, Alpenglow aims to reduce finality from approximately 12.8 seconds to around 150 milliseconds. If reached, that would make finality roughly 85 times faster.
Finality is the point at which validators have reached enough agreement for a block to be treated as irreversible. It is not simply the moment a transaction first appears on the network. Today, an application can see a Solana transaction as “confirmed” before it receives the network's stronger “finalized” status. Alpenglow is designed to make those two stages converge, because a finalization certificate could arrive within roughly the period now associated with an initial confirmation.
Three Clocks Can Govern One Payment
- Execution: the transaction runs and initially appears in a block.
- Protocol finality: validators establish that the block should no longer be reversed.
- Service release: an exchange, bridge or merchant decides when to credit the deposit, release assets or complete the order.
Alpenglow would shorten the second clock. Each business would still control the third, meaning a 150ms protocol target would not guarantee that every customer-facing payment finishes in 150 milliseconds.
How Alpenglow Changes Solana's Consensus
The first stage of Alpenglow introduces Votor, a replacement for the voting process used by Solana's current TowerBFT consensus system. Validators currently submit votes as transactions and build finality over a sequence of slots. Under Votor, they would exchange votes directly and combine them into certificates showing that enough stake has approved a block.
A block could finalize after one voting round when participation arrives quickly. A second round would be available when network conditions prevent the faster route.
🚨 Testnet operators: Alpenglow activation on testnet only runs on Agave. If you're on Firedancer or Frankendancer today, switch over to an Agave node before the migration window so your stake counts toward activation. Details in the thread below 👇
— Anza (@anza_xyz) September 22, 2026
The upgrade does not change how smart contracts execute, how balances are calculated or how users submit ordinary transactions. It changes how validators agree that the resulting block is final.
Solana has also been changing what transactions can contain. Its recent increase in maximum transaction size created more room for signatures, instructions and proofs. That upgrade changes what can fit inside a transaction; Alpenglow changes how quickly the network can consider it irreversible.
Where Faster Finality Could Make a Difference
- Exchanges: a platform could credit a Solana deposit sooner, although identity checks, wallet screening and internal risk controls may still delay access to the funds.
- Bridges: a bridge could verify the Solana side of a transfer sooner, but its relayers and the destination blockchain would continue operating on separate timelines.
- Merchants: if blockchain finality is the slowest part of checkout, a payment processor could confirm an irreversible payment sooner and begin fulfilling the order.
The improvement would be most visible where a service currently waits for Solana's strongest settlement assurance. It would have less effect when compliance checks, another blockchain or an offchain payment system already causes the larger delay.
The Tracked Activation Currently Supports Only Agave
Solana can be operated through independently developed validator clients. Agave is maintained by Anza, while Firedancer and Frankendancer provide alternative implementations. The current Alpenglow entry assigns the feature to Agave v4.3.0 and marks both Firedancer and Frankendancer as unsupported.
The entry describes the pending testnet feature gate; it does not establish which clients will support Alpenglow by the time any mainnet activation is considered. No date for adding support to either alternative client appears in the tracker. Their readiness therefore remains an open rollout question rather than evidence that they have been permanently excluded.
What the Testnet Activation Needs to Prove
- Migration: can validators switch consensus systems without interrupting block production?
- Observed speed: does measured finality approach 150ms rather than merely meeting the target in controlled tests?
- Network delays: does finality remain reliable when validators or internet connections respond slowly?
- Infrastructure delivery: do RPC providers and indexers receive the new finality data quickly and consistently?
- Client readiness: when can additional validator implementations support the new consensus system?
The 150ms figure is an expectation, not a constant. Solana's documentation says finality can vary with stake distribution and whether a block requires one voting round or two. Some infrastructure may also learn that a block has finalized later than the validators directly producing the certificate.
Even a successful testnet result would not guarantee identical performance on mainnet. Validator participation, stake distribution and network traffic can differ between the two environments.
An Activation Epoch Will Begin the Real Test
The next verifiable milestone will be a published activation epoch or an official notice that the feature gate has opened. Public testnet data can then show how close Alpenglow comes to its target and how quickly the resulting finality signal reaches wallets and infrastructure.
For payment companies, faster validator agreement is useful only if they receive that information quickly enough to change when funds are released. The activation epoch will begin that test; it will not settle the question by itself.
This article is provided for informational purposes only. Network schedules, validator-client support and measured finality can change as testing progresses.
Source: Solana Prepares to Test 150ms Finality — Coindoo