Solana Alpenglow Goes Live, Aiming to Cut Transaction Finality to 150ms

Solana’s Alpenglow consensus upgrade is now live on mainnet, putting a new validator voting system into operation with a target of reducing transaction finality to about 150 milliseconds. That would be a sharp change from the seconds users have historically had to wait for confirmation. The scale of the shift could make settlement feel much closer to the response times people expect from conventional online services, where an action usually draws an immediate response.

But a target is not a result. The early figures reported after activation show that Alpenglow has begun operating; they don’t establish that the network can sustain its intended finality time across changing loads and conditions.

Votor starts the consensus overhaul

The Solana Foundation’s activation dashboard recorded Alpenglow going live at about 1:54 pm UTC on Wednesday. Its first phase, Votor, replaces the network’s existing voting and finalization mechanism with direct validator votes and a certificate-based system. In practical terms, that changes how validators coordinate that a block can be treated as final. The goal is to reduce the time spent waiting for that agreement.

The Foundation said in July that the design aims to bring finality down from roughly 12.8 seconds to 150 milliseconds, a reduction of about 99%. Alpenglow replaces TowerBFT, Solana’s current consensus model. A later phase is set to add Rotor, a block data distribution protocol intended to take the place of Turbine. The two phases address related parts of network operation, but the activation now reported concerns Votor; Rotor remains a planned addition.

At the time reported, the dashboard showed 6.6-second finality and throughput of 4,721 transactions per second. Those figures offer an early mainnet snapshot, not proof of the eventual performance target. The 150-millisecond figure remains the upgrade’s aim, and the gap between it and the reported finality is substantial. Cointelegraph said it had asked the Solana Foundation about testnet measurements and expected performance in live applications.

Solana Alpenglow activation dashboard. Source: Solana.com

Responsiveness is the practical test

Faster finality could shorten waits for payments and trade settlements, while giving applications quicker confirmation that a transaction is complete. For users, that may mean less uncertainty after submitting an action; for developers, it could change how long an application must wait before showing a result or allowing a follow-up step. The benefit depends on finality being both quick and dependable. A fast confirmation that users can’t rely on is a poor substitute for a slower one they can trust.

Anza researchers Quentin Kniep, Kobi Sliwinski and Roger Wattenhofer wrote on May 19 that 150-millisecond latency could let Solana match Web2 infrastructure’s responsiveness and support new application categories. That’s an ambitious comparison, because users judge a service by the full interaction they experience, not one protocol measurement in isolation. Still, reducing the delay at the consensus layer could remove a meaningful constraint for applications built around rapid responses.

This is more significant than it looks: latency shapes what an application can ask users to tolerate. If you’re working in this space, the relevant question isn’t simply whether a dashboard can show a lower number, but whether the improvement changes product behavior under ordinary network conditions.

The researchers described Alpenglow as the biggest change to Solana’s core protocol since genesis. The network has also been working to reduce latency through shorter block slots: it began that effort in August, with a plan to halve slot times to 200 milliseconds, and completed the plan’s fourth stage in October. Slot timing and transaction finality are related performance concerns, but they describe different parts of the process. Faster slots alone don’t establish how quickly validators reach final agreement.

More protocol changes are planned

Validators are expected to continue work on Agave 4.5 after Alpenglow. The proposed upgrade would raise the account limit for versioned transactions from 64 to 96, which the Solana Foundation says could improve swap routes and execution prices. That change speaks to a different constraint than consensus latency: it concerns how much account data a transaction can include. For applications that need to coordinate more accounts in one transaction, a higher limit could create room for more complex routes.

Agave 4.5 remains in development, with a December 2026 target listed on the Foundation’s upgrade schedule. A target date indicates intended sequencing, while development work and validator adoption still have to carry a proposal into operation. Alpenglow’s activation makes the schedule more than a list of ideas, but each upgrade will need to be judged on its own deployment and results.

The measure that matters next

Alpenglow’s value will come down to whether its faster confirmation target holds under real network conditions. The dashboard’s early snapshot is a starting point, and the reported 6.6-second finality leaves a clear distance to the 150-millisecond goal. Here's the thing: the target matters because it could change how quickly applications respond, but sustained performance is what would make that change useful.

That said, users don’t experience consensus systems directly. They experience a payment that completes, a trade that settles, or an interface that stops waiting. The upgrade’s promise is straightforward: less time between submitting a transaction and knowing it has settled. The proof will be in whether that wait falls consistently as the system runs on mainnet. A sharper dashboard reading. Then, actual application behavior.

Related: Solana Foundation targets settlement in seconds with DvP launch

Magazine: Solana’s fee overhaul increases burn and makes resource hogs pay