Solana activated its Alpenglow consensus upgrade on October 21, 2026, at the start of epoch 1064, according to the Solana Foundation’s updated upgrade guide. The change replaces the network’s previous voting mechanism with Votor.
TL;DR: Alpenglow is live and targets roughly 150-millisecond finality. Block timing is a separate measure. Wallet transactions continue to work, while infrastructure providers need to account for changes beneath the surface.
Finality and block speed measure different things
Finality describes when the network considers a transaction settled. Slot timing describes the cadence at which validators receive opportunities to produce blocks. A faster cadence can make a transaction appear sooner, but it does not by itself establish when that transaction is final.
The Foundation’s Agave release overview explains the separate slot-time reduction from 400 to 200 milliseconds. That transition happened in four stages, with the final step taking effect on October 9. Each step depended on acceptable rates of missed blocks.
The same overview records an important release distinction: Alpenglow code was included in Agave 4.2 for testing, while mainnet activation arrived under Agave 4.3. Software containing a capability and a network enabling it are separate milestones.
Votor allows validators to exchange votes directly and collect them into certificates. The later Rotor phase, which would change how block data moves across the network, remains unscheduled. The activation leaves transaction execution and fee mechanics unchanged.
That separation means applications do not automatically gain a new execution environment. The immediate opportunity is to reconsider how long they wait before treating an accepted payment or other transaction as settled.
Why users may observe different confirmation times
Anza’s operator documentation explains that nodes outside the admitted validator set can learn about finality from certificates included in later blocks. That route can add a block interval, with longer delays possible when blocks are skipped or delayed.
Operators can instead arrange direct delivery of consensus messages from an admitted validator. In that setup, network latency between the two participants influences the delay. A protocol’s finality target therefore should not be read as a promise that every wallet or data service will display an update within exactly that time.
Activity dashboards also require care: validator votes no longer appear as transactions in blocks. Comparing headline transaction totals across the activation without adjusting the methodology can confuse an accounting change with a change in user demand.
For anyone assessing the upgrade, three measurements answer different questions: how quickly consensus finalizes, how quickly a service learns the result, and how quickly its interface presents it. Keeping them separate makes comparisons more meaningful and helps identify where any remaining delay actually occurs.
Written by the News Desk and edited by Samuel Rae.
Leave a Reply