Solana transactions take 12.8 seconds to finalize today. Starting October 21, 2026, that's dropping to 150 milliseconds, mainnet-wide.

The change is Alpenglow, Solana's biggest consensus upgrade since launch. It tears out Proof of History and Tower BFT, the two systems that have defined how the network reaches agreement since day one, and replaces them with a simpler, much faster design. It passed governance with 98.27% approval and is set to go live on mainnet in epoch 1064, which starts around 13:20 UTC on October 21, with Votor taking over at slot 459,653,000, about 18 minutes in.

Here's what to expect when the switch happens, how Alchemy is preparing, and what's actually different under the hood. For the protocol-level source of truth, see the Solana Foundation's Alpenglow upgrade page and SIMD-0326, the governance proposal that specifies it.

What to expect when the mainnet switch happens

A new epoch (Solana's roughly two-day scheduling window) starts around 13:20 UTC on October 21. Because epochs always run the same length, we already know the exact slot where the switch happens: 459,653,000. But the network won't flip the instant the epoch starts. For the first 18 minutes or so, it keeps using the old consensus method, Tower BFT, before switching over to Votor, Alpenglow's replacement, right at that slot. This only changes how the network agrees on transactions internally, not how you talk to it, so RPC, WebSocket, and gRPC endpoints are expected to keep working normally the whole time.

The switch itself is expected to take about two blocks, roughly 400 milliseconds, while enough of the network confirms it's ready. During that brief window, new blocks will only contain validator votes, no user transactions. Nothing should be rejected: a transaction sent right then should just land a moment later, once the switch finishes.

One side effect worth flagging to your team ahead of time: transaction counts and TPS on public dashboards will look lower right after activation. That won't be less usage, it's validator votes no longer counting as transactions. That's also why Alpenglow frees up 75% of block space: votes used to take up most of it, and now they don't.

Once activation happens, you can check whether a given network has switched over yet by calling getAgGenesisCert. It returns nothing before the switch and a result (with details like the exact slot) after.

How Alchemy prepared for Alpenglow

All of Alchemy's Solana RPC nodes already run an Alpenglow-ready client ahead of activation, so RPC, WebSocket, and Yellowstone gRPC endpoints won't need any changes on your end. Our transaction routing also already retries against another backend when a validator briefly lags behind new finality timing, the same protection that handles ordinary lagging servers today.

Leverage Alchemy for best-in-class Solana RPC, archival data, and gRPC streaming, used by leading teams on Solana like Phantom, Solflare, Cielo Finance, and more:

9.21ms average read latency, about 26% faster than the next provider, measured over the 24 hours ending September 29, 2026
Up to 20x faster archival queries and 10x faster on heavy calls like getProgramAccounts, with sub-200ms response times on large historical queries (validated in production by Solflare)
99.99% uptime SLA and 2x higher throughput than the previous-generation stack
Yellowstone-compatible gRPC at 5-15ms average delivery with 48-hour block replay, roughly 5x more affordable than alternatives

If you stream Solana data directly, this is also a good moment to check your Yellowstone gRPC client version and confirm you're committing only confirmed data during any migration window. And since confirmed and finalized now resolve at the same point, flows that previously waited on finalized, like deposit crediting, can likely move faster.

Get a free Solana RPC endpoint →

All about Alpenglow

How Votor and Rotor replace Tower BFT and Turbine

Alpenglow runs on two new protocols: Votor, which handles voting and finalization, and Rotor, which handles block propagation. The research came out of Professor Wattenhofer's distributed systems lab at ETH Zurich, with Anza leading implementation and Jump Crypto's Firedancer team working on multi-client compatibility.

How finality gets 85x faster

Tower BFT needs 32 incremental confirmations, each one adding a lockout period. Votor collapses that into one or two rounds of voting.

Fast path (~100ms): 80%+ of validators approve in the first round, done.
Slow path (~150ms): 60-80% approve in round one, a second round clears it with a 60%+ threshold.

Both paths run at once, whichever finishes first wins. In simulations, 65% of stake finalizes within 50ms of raw network latency.

Validators send votes as small messages directly to each other instead of as transactions on the network. Votor then compresses thousands of those votes into a single ~1,000-byte proof using a signature-combining technique called BLS aggregation, so only that one small proof gets recorded, replacing the ~500KB of vote data recorded per block today.

If you're indexing or querying that state directly, heavier calls like getProgramAccounts already run up to 10x faster on Alchemy's Solana API, independent of the Alpenglow timing improvements.

How Alpenglow frees up 75% of block space

Right now, about 75% of all Solana transactions are validator votes. Alpenglow moves voting off-chain entirely, so that space goes back to real users. Not a tweak, three-quarters of network capacity returned to actual usage, with lower fees and less congestion during busy periods.

How Alpenglow retires Proof of History

Alpenglow also drops Solana's original cryptographic clock. Instead of a continuous hash chain, validators now use simple timers tied to how long a block should take: block arrives in time, approve it; timer runs out with nothing, skip it. Clock drift is handled proportionally, 5% drift just needs a 5% longer timeout.

The time it takes to produce each block is a separate number from finality, and it moved too: four staged cuts brought it from 400ms to 200ms, completed this October ahead of Alpenglow's activation.

How finality drops from three levels to one

This might be the change developers feel most. Solana currently gives you three ways to check if a transaction went through: processed (fastest, least certain), confirmed (~500ms, still has a small chance of reversal), and finalized (~12.8s, guaranteed permanent). Anything that can't tolerate even a small chance of reversal, exchange deposits, bridge confirmations, liquidations, has to wait for finalized. Everything else settles for confirmed and accepts that small risk.

Alpenglow collapses confirmed and finalized into one: 100-150ms, and every transaction is permanent the moment it's confirmed. Processed stays as the earliest, least certain observation stage, so don't treat it as final. No more trading speed for certainty.

That opens up patterns that didn't work before. Order books with tighter spreads because market makers know a quote is final in 150ms. Cheaper JIT auctions on perp exchanges. Cross-chain bridges without a Solana-side finality bottleneck. Exchange deposits that go from a 13-second wait to instant. And for banks and fintechs, transactions that settle fast enough to compete with traditional payment rails for stablecoin settlement and cross-border transfers.

Fast, deterministic finality also makes gasless transactions a cleaner experience to build on Solana, since sponsors and end users both get a final answer in one step instead of waiting out a confirmation window.

How Alpenglow changes validator economics

Vote fees, about 1 SOL/day per validator, go away. In their place: a Validator Admission Ticket at roughly 0.8 SOL/day, fully burned. The network caps out at 2,000 validators, highest stake first. Minimum profitable stake drops from ~4,850 SOL to ~450 SOL, about a 90% lower bar to run a validator, and overall operating costs fall 20-50%. Identity keys can also move into hardware security modules now that they're not signing votes constantly.

How Alpenglow trades security for speed

Alpenglow uses a "20+20" security model. On its own, it can tolerate fewer outright malicious validators than before, 20% of the network instead of 33%. But combined with offline or unresponsive validators, it can tolerate up to 40% of the network failing in some way, more than the old 33% limit. Since real-world outages are usually a mix of malicious and simply offline validators, that combined number is the more realistic measure.

The math still guarantees no two conflicting versions of history can both get approved, since the two approval thresholds (80% and 60%) add up to more than 100% of the network.

How the Alpenglow rollout got here

Alpenglow was unveiled at Solana Accelerate in May 2025, passed governance that September (SIMD-0326), moved through private cluster testing and the Agave 4.1 release, hit devnet in September 2026, and is scheduled to activate on mainnet at epoch 1064 this October 21. A few pieces from the original whitepaper, smart sampling, async execution, and further Rotor refinements, are saved for future proposals.

Net result: a full consensus swap on a live network, transactions that are permanent in under 200ms, 75% of block space freed up, and a 90% lower bar to run a validator.

FAQ

When does Alpenglow activate on Solana mainnet?

Epoch 1064, about 13:20 UTC on October 21, 2026. Votor is set to take over at slot 459,653,000, roughly 18 minutes into the epoch.

Will Alpenglow cause downtime?

No downtime is expected. RPC, WebSocket, and gRPC traffic should work normally throughout. There's expected to be a brief pause in new user transactions, about 400ms, right at the switch, but nothing sent then should be dropped, it should just land once the switch completes.