Solana Alpenglow Reaches Second Public Test Network

What Alpenglow changes

Alpenglow changes the way Solana validators reach agreement about the blockchain's state.

Under the existing TowerBFT system, validators vote by sending vote transactions, and those votes become part of the ledger. Alpenglow introduces Votor, in which validators communicate votes directly and combine them into certificates. A block can then reach finality after one or two voting rounds rather than waiting for the current voting process to accumulate sufficient confirmations.

This distinction matters because Alpenglow is primarily a consensus upgrade, not a rewrite of how Solana applications execute transactions. Solana's documentation says the SVM, transaction formats, fees and account model remain unchanged. The major differences are in how validators vote, how blocks reach finality and how downstream infrastructure receives consensus information. Developers can review the official Alpenglow documentation for the migration requirements and technical changes.

Why developers need the test networks

Public test environments give application developers, validators and infrastructure providers a place to identify compatibility issues before changes reach real-value transactions.

The Solana developer network, or devnet, is commonly used for application development and testing with tokens that do not represent real economic value. The separate testnet provides an environment for testing network software and validator operations under conditions closer to those of a production blockchain.

For many application developers, the transition should require little or no direct code migration. Solana's official documentation says applications that simply send transactions and read account state can continue operating without changes. The more significant work falls on validators and infrastructure that consumes block, vote or finality data.

The upgrade is already observable on Solana's public testing infrastructure. Solana's testnet explorer currently identifies Alpenglow as the active consensus mechanism and provides a genesis slot for the migration.

Faster finality could change payment experiences

The headline performance target is approximately 150 milliseconds of finality, compared with roughly 12.8 seconds under the current consensus system.

For users, the practical effect could be shorter waits between submitting a transaction and receiving confirmation that the transaction can no longer be reversed under the protocol's finality rules. Solana specifically highlights potential applications such as near-instant payment confirmations.

However, the 150-millisecond figure should not be interpreted as a guarantee that every real-world transaction will complete an entire application workflow in 150 milliseconds. Wallet processing, exchange deposit policies, application logic and other infrastructure can introduce additional waiting time.

Solana also emphasizes that the 150ms figure is finality time, not block-production time. The network is addressing slot times separately. Its Alpenglow documentation says slot time is being reduced in stages from 400 milliseconds toward 200 milliseconds.

Vote transactions will disappear from blocks

One of the most visible changes will affect blockchain data rather than ordinary users.

With Alpenglow, validator votes will no longer be recorded as transactions inside blocks. Instead, validators will communicate votes directly and aggregate them into certificates. As a result, transaction counts and reported TPS can fall even if users continue making the same number of transfers and trades.

That means analytics platforms, explorers and other services that measure Solana activity will need to account for the change when comparing historical and post-Alpenglow data. A lower transaction count after the upgrade would not automatically mean that user activity or application throughput had declined.

Infrastructure providers that read blocks or stream Solana data will therefore need to update their assumptions. Solana's documentation specifically warns that dashboards, benchmarks, alerts and historical comparisons that included vote transactions will need to be recalibrated.

Mainnet timing remains separate

The public testing milestones do not establish a confirmed mainnet launch date for Alpenglow.

The supplied report notes that Anza's software schedule tentatively allows feature activations to resume on September 28, but that date is not presented as Alpenglow's mainnet activation date.

Solana's current documentation reinforces the distinction: there is no fixed activation time for Alpenglow, and each cluster can migrate according to its own schedule. Developers can use the getAgGenesisCert RPC method to determine whether a specific cluster has migrated. A null response means the cluster is still operating under TowerBFT, while a genesis certificate indicates that Alpenglow consensus is active.

For users, wallets and applications, the transition is intended to be largely invisible. For validators, indexers, explorers and other infrastructure operators, however, Alpenglow represents a substantial change in how Solana consensus information is produced and consumed.

The second public testing milestone therefore gives the ecosystem another opportunity to identify and resolve those infrastructure issues before any future mainnet activation.