Solana Activates Alpenglow on Devnet, Targets 150ms Finality

Alpenglow Switch Is Confirmed on Two Test Networks

Daily Crypto Briefs independently queried Solana’s public testnet, devnet and mainnet endpoints at 19:04 UTC on September 26. Testnet returned an Alpenglow genesis certificate naming slot 444,625,255; devnet returned one naming slot 504,148,999. Mainnet returned null.

The Foundation’s documented test distinguishes a completed migration from installed software. A certificate identifies the first block produced under Alpenglow; a null result means the queried cluster remains on TowerBFT. These are timestamped observations of those endpoints, rather than a guarantee about every service connected to them.

Anza’s feature tracker now places SIMD-0326, the Alpenglow consensus change, under pending mainnet activation. It records testnet epoch 1042 and devnet epoch 1167, with Agave v4.3.0 as the supporting version.

The same entry marks Firedancer and Frankendancer as unsupported for this feature. That is a compatibility restriction on this consensus transition, rather than evidence that those clients have stopped supporting Solana generally.

Quicknode’s maintenance record provides a separate operator timeline. It scheduled devnet’s switch for September 25 at epoch 1167 and marked the maintenance completed at 21:30 UTC. Its completion notice corroborates the rollout window; it is not a published speed benchmark.

Development networks allow teams to exercise software without treating test tokens as production assets. The immediate consequence is a place to check deposits, account updates and data services against the changed consensus behavior before a mainnet decision.

150ms Finality Remains a Performance Target

Anza’s original research announcement estimated median finality of about 150 milliseconds, compared with approximately 12.8 seconds under TowerBFT. It explicitly based those latency figures on simulations using the then-current mainnet stake distribution and excluded computation overhead.

Activating the protocol on test networks does not independently prove that median will hold under production traffic. Nor is a median a maximum wait promised for every transaction or every application’s infrastructure.

Votor, Alpenglow’s voting component, offers a one-round path when 80% of stake participates and a two-round path when 60% responds. Anza says the paths run concurrently, allowing the faster successful route to finalize a block.

That design changes the permanence guarantee an application can read. Under TowerBFT, Anza’s commitment table separates confirmation by more than two-thirds of stake from finalization, which requires at least 31 confirmed blocks built above the transaction’s block.

Under Alpenglow, confirmed and finalized have equivalent permanence guarantees. A processed transaction remains distinct: observing that a node received a block does not by itself show that consensus permanently committed it.

For an exchange deposit or merchant payment, the potential benefit is a shorter interval before that stronger guarantee becomes available. Crediting a customer’s balance still involves the service’s own infrastructure and policies, so network finality alone cannot establish an end-to-end payment deadline.

Solana’s earlier capacity expansion addresses a different constraint. Compute capacity measures how much work fits into blocks; finality measures when the network’s agreement becomes permanent. Neither metric alone describes the complete user experience.

Solana Mainnet Timing and Data Handling Remain Open

Anza’s Agave 4.3 schedule lists September 28 as a tentative date to resume mainnet feature activation. It does not identify that date as a confirmed Alpenglow launch, and its dates remain subject to change.

The schedule records general mainnet adoption being recommended on September 21, following earlier staged adoption targets. Running the release and activating its consensus feature are separate steps. Today’s test-cluster results settle the latter question only for those clusters.

Infrastructure also has its own latency limits. Anza’s operator guidance says unstaked nodes can learn finalization from certificates included in subsequent blocks. That default route typically adds up to one produced-block interval and can take longer when blocks are skipped or delayed.

An unstaked node can instead partner with an admitted validator to receive consensus messages more directly. The additional delay then primarily reflects network latency between the partners, according to Anza. Faster network agreement and faster delivery of that information therefore require separate measurement.

The migration also removes validator vote transactions from blocks, changing comparisons that included that traffic. Data providers must adjust their baselines before interpreting a lower total transaction count as falling user demand.

That distinction is relevant to services such as the Solana merchant-payment trial in Korea. Testing consensus can inform future integrations, but the test-network switch does not establish that any particular merchant service has deployed Alpenglow.

Broader sentiment remained positive: Alternative.me’s Bitcoin-focused Fear and Greed Index read 74, or Greed, for September 26, compared with 71 the previous day. It does not measure SOL-specific sentiment or validator readiness.

The remaining milestones are a specific mainnet activation decision and published performance results under operating conditions. As of the September 26 check, the evidence confirms two migrated test networks while production activation and delivered mainnet latency remain unresolved.