Solana Alpenglow Upgrade: Live or Not? We Checked the Chain (2026)

The Solana Alpenglow upgrade is not live on mainnet. It is live on testnet and devnet. We did not read that anywhere — we asked the three clusters directly on 5 October 2026, and you can re-run every command in this article in under a minute.

That matters because almost every page ranking for this keyword quotes a date. One says late Q4 2025. One says early Q1 2026. One says 18 September 2026. One says "as early as late Q3 or early Q4". They were all published confidently, and every one of those dates has now passed with mainnet still running TowerBFT. The problem is not that writers are careless — it is that they are quoting forecasts when the chain itself will answer the question for free.

So this article does the boring thing instead. It reads the feature gates, counts the signatures on the certificate that retired TowerBFT on testnet, measures how far behind finality mainnet actually runs today, and shows the arithmetic. Where a number comes from a press report or from Anza rather than from the chain, it says so.

No on mainnet-beta, yes on testnet, yes on devnet. Measured 5 October 2026 at mainnet epoch 1050, slot 453,616,522.

Cluster	Consensus	Gate activated at slot	Alpenglow genesis block
mainnet-beta	TowerBFT + Proof-of-History	gate account does not exist	none
testnet	Alpenglow (Votor)	444,620,256	444,625,255
devnet	Alpenglow (Votor)	504,144,000	504,148,999

The two genesis slots match the numbers Anza published when it announced each handoff, which is a useful cross-check: our method and their announcement agree to the slot. The mainnet row is the one no other page states as a verified fact rather than an expectation.

Alpenglow adds a new RPC method, getAgGenesisCert, which returns the certificate that proves a cluster completed the handoff from TowerBFT to Votor. On a cluster still running TowerBFT it returns null. That is the whole status check.

curl -s https://api.mainnet-beta.solana.com -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getAgGenesisCert"}'

# mainnet-beta -> {"jsonrpc":"2.0","result":null,"id":1}
# testnet      -> result.block.slot = 444625255
# devnet       -> result.block.slot = 504148999

The testnet response carries more than a slot number. It includes a 192-byte BLS aggregate signature and a validator bitmap, and the bitmap is worth counting. On testnet it is 64 bytes wide with 363 bits set — 363 validators signed the certificate that retired TowerBFT. On devnet the bitmap is 6 bytes with 13 bits set. The width of the bitmap is itself informative: 64 bytes addresses up to 512 validators, which is the kind of set size Alpenglow's certificate design is built around.

If you prefer to check the feature gate rather than the certificate, the key is A1pengvuM6JEcyNuTnMqepBKhwHE3N6PmUrdATGawhJS, declared in Agave's feature-set crate as "SIMD-0326: Alpenglow: new consensus algorithm". A getAccountInfo call returns null on mainnet and a populated account on testnet and devnet.

One footnote for anyone reading the specification rather than the code. SIMD-0384, the migration proposal, names a different feature key in its own front matter: a1penGLz8Vm2QHYB3JPefBiU4BY3Z6JkW2k3Scw5GWP. That account does not exist on mainnet, testnet or devnet. The gate that actually fired on testnet is the SIMD-0326 key above. If you are building a status dashboard, read the key out of Agave's feature-set, not out of the SIMD.

Alpenglow replaces Solana's consensus protocol. TowerBFT and Proof-of-History go away; a new voting and finalization component called Votor takes over. SIMD-0326 is blunt about why: the current protocol has a consensus finality time of 12.8 seconds, and "does not have a security proof, which is concerning."

The mechanical changes that matter to anyone outside a validator shed:

• Votes leave the blockchain. Today every validator posts a vote transaction for every slot. Under Alpenglow, votes are sent directly between validators and aggregated into BLS certificates. They are not transactions any more.
• Two finalization paths run concurrently. Fast-finalization needs one round of notarize votes from 80% of stake. Slow-finalization needs two rounds from 60%. Whichever completes first decides the slot.
• A 20+20 resilience model. Anza describes it as tolerating up to 20% adversarial stake plus a further 20% non-responsive stake. The tradeoff, stated in the SIMD, is that this is not the 33% byzantine tolerance a two-round-only protocol could offer.
• Proof-of-History is retired. Timeouts measured locally by each node replace it. The migration spec puts the tick producer into a low-power mode with one hash per tick and turns off tick verification.

What Alpenglow is not, in this release: SIMD-0326 explicitly excludes Rotor, the replacement for Turbine's data dissemination layer, which will get its own proposal later. Turbine stays. Lazy asynchronous execution is also a separate SIMD. If you have read that Alpenglow rebuilds Solana's networking, it does not — not yet.

Anza's design target, published in its May 2025 announcement, is "actual finality in about 150 ms (median)", occasionally as fast as 100 ms. Anza also publishes its own caveat in the same paragraph, which almost nobody quoting the 150 ms figure carries over: "These latency numbers are based on simulations with the current mainnet stake distribution, not counting computation overhead." It is a simulation result with the computation excluded, not a measurement.

This is the part of the story that no published page seems to have checked. Alpenglow is not one switch. Its prerequisites shipped as separate feature gates, and on mainnet three of them are already active. Only the consensus change itself is missing.

Gate	What it is for	Mainnet status
BLS12-381 syscalls (SIMD-0388)	the curve Alpenglow's aggregate signatures use	active, slot 425,952,004 (epoch 986)
BLS pubkey in vote account (SIMD-0387)	where a validator's Votor key is stored	active, slot 431,568,000 (epoch 999)
Validator Admission Ticket (SIMD-0357)	the fee that replaces on-chain vote fees	active, slot 434,592,000 (epoch 1006)
Alpenglow consensus (SIMD-0326)	the switch from TowerBFT to Votor	not staged — account does not exist
Fast leader handover (SIMD-0326 part two)	shorter gap between consecutive leaders	not staged on any cluster

Read that table the right way round. "Not staged" is a stronger statement than "not activated": the feature account has not even been created, so there is nothing for validators to vote on yet. But the plumbing underneath has been live on mainnet for months — the BLS syscall since epoch 986, roughly 64 epochs ago.

The Validator Admission Ticket is the economically interesting one. SIMD-0357 specifies charging every admitted validator 1.6 SOL per epoch, deducted from the vote account rather than the hot identity account, and burned to the incinerator. It replaces the roughly 2 SOL per epoch validators currently pay in vote transaction fees, and it caps the Alpenglow voting set at 2,000 validators. Mainnet currently has 6,796 vote accounts in existence and 685 of them actually voting, so the cap is nowhere near binding. SIMD-0525 notes that before Alpenglow is active, the VAT scaling section "has no effect" — the gate being on is not the same as the ticket being charged.

Here is the thing the Alpenglow coverage misses entirely. While SIMD-0326 sat in Review, a different proposal quietly shipped three times on mainnet and made Solana materially faster.

SIMD-0525, "Reduce Slot Times", steps the target slot time from 400 ms down to 200 ms in four feature-gated stages. Its status is still Draft. Three of its four gates are already active on mainnet:

Stage	Activated	Measured average slot	Leader window
400 ms (baseline)	—	415.4 ms	1.6 s
350 ms	19 Aug 2026, slot 440,208,000	378.4 ms	1.4 s
300 ms	26 Aug 2026, slot 441,936,000	320.2 ms	1.2 s
250 ms (current)	16 Sep 2026, slot 447,552,000	270.8 ms	1.0 s
200 ms	not staged	—	0.8 s

The measured column is ours, derived by dividing wall-clock time by slots elapsed across each regime using getBlockTime on epoch-boundary slots. Real slots consistently run 6-8% above target, which is what you would expect from skipped slots and propagation slack. The useful summary: 415.4 ms down to 270.8 ms, a 34.8% reduction, inside 28 days, with no new consensus protocol involved.

Two side effects worth knowing. Because SIMD-0525 keeps epochs fixed at 432,000 slots, faster slots mean shorter epochs — we measured the current epoch at 32.11 hours, against the 48 hours every Solana guide still quotes. Anyone writing about unstaking, warmup or reward cadence is working from a number that is now a third too long, which is why our pieces on Solana staking yields, Marinade and Sanctum all have to be measured rather than quoted. And the per-slot work budgets scale down with the clock: max block compute units fall from 60 million at 400 ms to 37.5 million at 250 ms, so the per-second capacity is roughly held, not increased.

Every article on this topic opens with "Alpenglow cuts finality from 12.8 seconds to 150 milliseconds". The 12.8 seconds is from SIMD-0326 and it is real — but it is a 400 ms slot number. TowerBFT roots a block 32 slots deep; 32 slots at 400 ms is 12.8 seconds. Slots are not 400 ms any more.

You can measure the gap directly. Ask any mainnet RPC node for its current slot at confirmed and at finalized commitment and subtract:

for C in confirmed finalized; do
  curl -s https://api.mainnet-beta.solana.com -X POST \
    -H "Content-Type: application/json" \
    -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"getSlot\",\"params\":[{\"commitment\":\"$C\"}]}"
  echo
done

Across 12 samples on 5 October 2026 the gap was 31 slots median (range 31 to 32) — exactly the rooting depth TowerBFT implies. At the measured 270.8 ms slot, that is about 8.4 seconds, not 12.8. Roughly a third of the finality gap Alpenglow is advertised as closing has already closed, and it closed through a Draft proposal about clock speed rather than through a new consensus protocol.

We ran the same two calls against testnet and devnet, where Votor is live. The gap there was median zero slots, and occasionally negative — the finalized tip reading one or two slots ahead of the confirmed tip. That is not an error. SIMD-0326's own Impact section says "optimistic confirmation is superseded by faster (actual) finality", and a negative gap is what that sentence looks like from outside: finality now arrives before the optimistic-confirmation tracker that was built to front-run it.

For reference, press coverage reported a 54 ms median finalization on testnet shortly after the handoff. We did not measure that number and we are not adopting it; our own measurement only establishes that the confirmed-to-finalized gap collapsed from 31 slots to zero. Anza's published design target remains roughly 150 ms median, from simulation.

The headline benefit of Alpenglow is usually framed as speed. The more measurable one is that it deletes a huge amount of on-chain work.

From five consecutive getRecentPerformanceSamples windows on 5 October 2026, mainnet was running 4,602 to 5,142 transactions per second in total and 2,104 to 2,631 non-vote transactions per second. Vote transactions were 48.8% to 54.3% of everything on the chain. Alpenglow moves all of that off-chain, into direct validator-to-validator BLS messages.

The economics change with it. Validators currently pay roughly 2 SOL per epoch in vote fees — a real cost that also acts as a soft cap on validator count. The Validator Admission Ticket replaces it with a flat charge that is burned rather than paid out, and SIMD-0525 scales it with the clock so the daily cost stays near 0.8 SOL: 1.6 SOL per epoch at 400 ms slots, 1.2 at 300 ms, 1.0 at the current 250 ms, 0.8 at 200 ms. If you hold a liquid staking token, this is the line item behind your yield — the same accounting we walk through in the real Solana staking APY, where validator commission and fee streams matter far more than the headline rate.

One caveat the SIMD states and we will repeat: non-Alpenglow vote transaction costs are not reduced by the slot-time gates. Until Votor activates, faster slots mean validators pay vote fees more often per wall-clock hour. The cost relief arrives with the consensus switch, not before it.

The migration procedure in SIMD-0384 is where mainnet's real constraint shows up. The handoff requires a block past the migration boundary to reach "strong optimistic confirmation" — vote transactions from at least 82% of stake — and then an 82% genesis certificate before validators switch to Votor.

Anza has been explicit that Firedancer and Frankendancer do not support the Alpenglow migration, and that testnet operators running either had to move to Agave v4.3.0 before the gate activated. So the question for mainnet is simple: how much stake is on a client that cannot make the jump?

We joined getClusterNodes to getVoteAccounts to get stake-weighted client shares across all 685 mainnet validators and 441,738,541 SOL of activated stake:

Client	Share of stake	Ships Alpenglow?
Agave 4.3.x	83.78%	yes
Firedancer 26.09.x	13.18%	not for the migration
Frankendancer	1.86%	no, support ending
Agave 4.2.x and older	0.50%	no, needs upgrade
Other / not in gossip	0.58%	unknown

The Firedancer family holds 15.04% of mainnet stake today. If none of that stake moved to Agave before activation, the maximum participating stake would be about 84.96% — above the 82% the migration needs, and above Alpenglow's 80% fast-finalization path, but with only about 3 points of headroom on the migration threshold.

That is a bound, not a prediction. Operators can and did switch on testnet, and 363 validators signed the testnet certificate without drama. But it explains the shape of the rollout better than any date does: the number to watch going into a mainnet activation window is not a calendar entry, it is the Firedancer stake share. You can compute it yourself with the two RPC calls above.

Worth noting for context: 83.78% of mainnet stake already runs Agave 4.3.x, and Agave 4.3.0 is the release that contains Alpenglow — the alpenglow feature module with that A1pengvu… key is in its feature-set crate. The code is deployed on most of mainnet's stake. Only the switch is missing.

Walk the timeline and the pattern is obvious.

• 19 May 2025 — Anza publishes the Alpenglow announcement and white paper.
• 25 July 2025 — SIMD-0326 created. It was merged into the proposals repository on 9 September 2025.
• September 2025 — the governance vote passes. Reported support figures differ across outlets (94%, 98%, 99%), which is a fair warning about how precisely this story has been covered. SIMD-0357 simply records that "the general VAT concept has already been accepted with the governance vote on SIMD 326."
• 21 October 2025 — SIMD-0384, the migration spec, created; merged 21 November 2025.
• Through 2026 — Alpenglow runs for over four months on a separate community cluster, per Anza, rehearsing the migration repeatedly.
• 18 September 2026 — Agave v4.3.0 ships as a stable release.
• 24 September 2026 — testnet migrates. The gate activated at slot 444,620,256 and the genesis certificate formed at 444,625,255, a gap of 4,999 slots, matching SIMD-0384's "activation slot + 5,000" boundary. Anza described the countdown as about 17 minutes; at mainnet's current 270.8 ms slot the same 5,000 slots would run about 22 minutes.
• 25 September 2026 — devnet migrates at slot 504,144,000.
• Mainnet — "after our observation period", per Anza. No date.

Two things that kept being misread. The 28 September date that circulated widely came from Agave's v4.3 release schedule, where it marks the resumption of general feature activations on mainnet — it never named Alpenglow. The v4.4 schedule similarly lists devnet activations resuming 7 October and mainnet from 9 November, and also does not name Alpenglow. A window in which switches may be flipped is not a date for a specific switch.

And all four Alpenglow proposals still carry status: Review in their front matter, with SIMD-0525 at Draft. The status field is not a reliable progress indicator — the governance vote passed and testnet has migrated while the documents still say Review — but it is a useful reminder that the paperwork and the chain are two different sources, and only one of them is queryable.

Be careful here, because two different latencies get conflated constantly.

Execution latency is how long it takes your transaction to reach a leader and land in a block. Finality latency is how long until that block can no longer be reverted. Alpenglow attacks the second one. It does very little for the first, which is the one that decides whether you got the fill. When a Solana trading bot advertises sub-400ms execution, that is a claim about the path from signal to submitted transaction — not about consensus depth.

Where finality genuinely matters:

• Anything that settles across a trust boundary. Exchange deposits, bridges, and off-chain systems that wait for finalized before crediting you. Those waits are the 8.4 seconds we measured, and they are what collapses to sub-second.
• Oracle freshness and anything that reads time in slots. SIMD-0525 names oracle consumers and market makers explicitly: a shorter slot means less quantization error when you interpret "how stale is this price". Relevant to perps venues and on-chain orderbooks alike.
• The leader's reordering window. SIMD-0525's stated motivation includes market structure: a leader controls a nominal 1.6 s window at 400 ms slots, 1.0 s today, and 0.8 s at 200 ms. That is the worst-case time a leader can delay, reorder or selectively include your transaction — which is exactly the window sandwich bots and MEV extraction operate inside. Shorter windows shrink it.
• Fee dynamics. Removing roughly half of all transactions from blocks changes what competing for blockspace looks like. We priced today's version of that competition in what a Solana trade really costs; it will need re-measuring after any activation.

Where it changes less than people expect: short-horizon trading. Our own production data in the Solana copy trading statistics puts the median holding time of a copied position at 24 seconds. A strategy whose average position is opened and closed inside half a minute is not waiting on 8.4-second finality in any meaningful way — it is bounded by how fast the trade is detected and submitted. That is also why sniper bots compete on RPC placement and priority fees rather than on consensus. If you are choosing a Solana trading platform or evaluating how to copy trade on Solana, Alpenglow should not move your decision much. Your RPC provider should — which is why Helius, QuickNode and Triton matter more to your fills than any consensus upgrade.

The honest summary: Alpenglow is a large, genuine improvement to settlement assurance and a real reduction in validator overhead. It is not a trading-speed upgrade, and anyone selling it to you as one is reading the press release rather than the specification.

Four commands, no API key, about ten seconds. Run them and you will never need to trust a date in a headline again.

RPC=https://api.mainnet-beta.solana.com
POST='-X POST -H Content-Type:application/json'

# 1. Has the cluster handed off to Votor? null = still TowerBFT
curl -s $RPC $POST -d '{"jsonrpc":"2.0","id":1,"method":"getAgGenesisCert"}'

# 2. Is the SIMD-0326 gate even staged? null value = no
curl -s $RPC $POST -d '{"jsonrpc":"2.0","id":1,"method":"getAccountInfo",
  "params":["A1pengvuM6JEcyNuTnMqepBKhwHE3N6PmUrdATGawhJS",{"encoding":"base64"}]}'

# 3. How far behind is finality? compare confirmed vs finalized
curl -s $RPC $POST -d '{"jsonrpc":"2.0","id":1,"method":"getSlot",
  "params":[{"commitment":"finalized"}]}'

# 4. Which client version is this node running?
curl -s $RPC $POST -d '{"jsonrpc":"2.0","id":1,"method":"getVersion"}'

On 5 October 2026 those returned, in order: null; a null account value; a slot 31 behind confirmed; and solana-core 4.3.0 with feature-set 3383571666. If call one ever returns a block, mainnet has migrated — and you will know before the articles do.

What is Alpenglow in Solana?

Alpenglow is a replacement for Solana's consensus protocol. It retires TowerBFT and Proof-of-History and introduces Votor, which finalizes blocks in one round of voting when 80% of stake participates and two rounds when 60% does. Validator votes stop being on-chain transactions and become direct BLS-signed messages between validators. It is specified in SIMD-0326.

Is the Alpenglow upgrade live on Solana mainnet?

Not as of 5 October 2026. The SIMD-0326 feature gate account does not exist on mainnet-beta, and the getAgGenesisCert RPC call returns null there. Alpenglow is live on testnet, which handed off at slot 444,625,255 on 24 September 2026, and on devnet, which handed off at slot 504,148,999 the following day.

What is the Solana Alpenglow upgrade date?

There is no announced mainnet date. Anza's guidance is "mainnet-beta after our observation period". The 28 September 2026 date that circulated came from Agave's v4.3 release schedule and referred to general feature activations resuming, not to Alpenglow; the v4.4 schedule lists mainnet activations resuming from 9 November and likewise does not name Alpenglow. Rather than trust any date, run the one RPC call above.

How fast will Solana be after Alpenglow?

Anza's design target is roughly 150 ms median finality, occasionally near 100 ms — but Anza states those figures come from simulations using the current mainnet stake distribution and exclude computation overhead. What we can confirm by measurement is that on testnet and devnet under Votor, the gap between the confirmed and finalized slot is zero, against a median of 31 slots on mainnet today.

Is Solana finality really 12.8 seconds today?

No, and this is the most-repeated stale number in the coverage. The 12.8 seconds in SIMD-0326 is 32 slots at 400 ms. Mainnet slots now target 250 ms, and we measured an average of 270.8 ms across the current regime. The confirmed-to-finalized gap measured 31 slots on 5 October 2026, which works out to about 8.4 seconds.

Will Firedancer support Alpenglow?

Not for the initial migration. Anza stated that Firedancer and Frankendancer do not support the Alpenglow migration and that testnet validators running either had to switch to Agave v4.3.0 before the gate activated; Frankendancer support is reported to be ending after mainnet activation. This matters because the Firedancer family holds 15.04% of mainnet stake and the migration needs 82% of stake to confirm the final TowerBFT block.

Does Alpenglow make copy trading or bot trading faster?

Barely. Alpenglow reduces finality latency, not execution latency — the time for your transaction to reach a leader and land. Fills are decided by RPC placement, priority fees and detection speed, not by consensus depth. The clearer trading benefits are indirect: a shorter leader window, which is the window in which a leader can reorder or delay your transaction, and faster settlement for anything that waits on finalized commitment.

None of the numbers in this article are ours to assert — they are three RPC endpoints, a GitHub repository of proposals, and arithmetic you can redo. That is the point. Solana's roadmap is unusually legible if you stop reading forecasts and start reading feature gates, and the same instinct applies to picking the tools you trade with: verifiable on-chain history beats a claim on a landing page. It is why uwuu's trader leaderboard is auditable on-chain and why the fee is performance-based — you pay only when a copied trade actually makes you money.