The Alpenglow, Solana's new consensus system, is already active on devnet and testnet, bringing to public test environments a change that aims to reduce the network's finality from about 12.8 seconds to approximately 150 milliseconds. Mainnet has not yet made the transition.

If this performance holds when real capital, congestion and production infrastructure are involved, the main change will not simply be a “faster” Solana. Alpenglow drastically reduces the interval between a transaction appearing on the network and it being able to be treated as final — while at the same time changing the very way activity and throughput are accounted for.

150 ms reduces the wait for certainty, not all latency

The distinction is important: 150 ms is a finality target, not a target for total time for any operation on Solana. The network's own documentation separates finality from block production and states that SVM execution, transaction format and fees remain unchanged.

Today, applications can offer fast experiences using commitment levels prior to finalization. Solana's documentation has even historically recommended the confirmed level for many uses, precisely because it is more recent than finalized, although there is still a small exposure to chain reorganizations.

Alpenglow's gain appears mainly when irreversible certainty matters.

A payment processor could reduce the interval before considering a transfer definitively settled. Exchanges could, in principle, shorten waits for operations that depend on finality. Systems for collateral, settlement and cross-chain infrastructure would also spend less time operating within a window in which state is not yet final.

This does not mean these services will automatically start operating at 150 ms. External systems keep their own risk controls, queues, RPCs and operational policies. But the consensus component would no longer impose a wait measured in seconds.

Trading gains faster certainty, but not magic latency

For trading, the consequence is also more specific than simply making trades “100 times faster”.

Alpenglow changes consensus, not execution. Order submission speed, access to leaders, RPC quality, data propagation and traders' own infrastructure continue to influence perceived latency.

What changes is the speed with which the market can gain certainty about the resulting state.

This can reduce the period during which systems need to treat a transaction as confirmed but not yet fully final. For applications that move capital quickly between positions, protocols or external systems, reducing this window reduces a specific source of operational risk.

There is also a relevant technical change: with Alpenglow, confirmed and finalized begin to converge. Solana already advises developers to review integrations built around these commitment levels when the new consensus arrives on mainnet.

Solana can appear slower on dashboards without processing fewer users

The change most easily misinterpreted will probably be in the metrics.

In TowerBFT, validators record their votes as transactions inside blocks. Votor, the first phase of Alpenglow, moves these votes to direct messages between validators and aggregates them into certificates. Vote transactions therefore no longer appear in the ledger.

The statistical effect can be large.

Data compiled by Solana Compass for mainnet between September 18 and 24 show that validator votes accounted for between 54% and 59% of daily transactions. On September 24, there were about 217.1 million vote transactions versus 168.8 million non-vote transactions.

If similar proportions exist on the migration date, charts based on total transactions or aggregate TPS may record an abrupt drop without any equivalent reduction having occurred in use by people, bots or applications.

This creates an important methodological break: Total TPS before and after Alpenglow will no longer be directly comparable when the historical series includes votes.

To measure economic activity and network utilization, metrics such as non-vote transactions, fee payers, compute units, fees and application activity become more useful references. Solana itself already separates total transactions, vote transactions and non-vote transactions in its data dashboard.

Mainnet remains the decisive test

Devnet and testnet confirm that the architecture has already moved past the purely theoretical stage. Solana officially records Alpenglow as active in both environments and still not activated on mainnet.

But they do not demonstrate, by themselves, that 150 ms will be the sustained behavior of a network carrying billions of dollars, heterogeneous infrastructure and real economic traffic.

The migration also requires adaptations outside consensus. Systems that consume data via Geyser or gRPC need to handle bank_id; indexers need to stop looking for votes inside transactions; and monitoring tools need to recalibrate TPS and transaction count baselines.

Therefore, the next relevant signals will be concrete: when mainnet will be migrated, what the real distribution of finality times under load will be, how often the protocol will need to resort to the slower voting path and how data providers will update their metrics.

If Alpenglow maintains finality close to 150 ms under these conditions, Solana will have reduced an important gap between blockchains and traditional financial infrastructure. But comparing the network with its own past will also need to change: after Alpenglow, a drop in displayed TPS may mean only that millions of votes stopped being counted as transactions — not that the blockchain is being used less.

More from Radar