Solana’s Alpenglow Upgrade Moves Validator Votes off the Chain

Anza will cut Solana over to its Alpenglow upgrade on October 21 at about 14:50 UTC, swapping TowerBFT for Votor on a live chain. The upgrade targets about 150 milliseconds of finality, down from about 12.8 seconds under the protocol Solana has run since genesis. It also pulls validator votes off the ledger, which is most of the traffic the chain currently records.

Wallets keep working. Firedancer and Frankendancer are not supported for the migration, Rotor still has no date, and any dashboard that counted vote transactions will show a sharp drop that is not a drop in user activity.

Anza Set a One-Slot Switch for October 21

On October 13, Anza, the team that builds the Agave validator client, said Alpenglow “goes live on mainnet-beta Wednesday, October 21, ~14:50 UTC,” after 18 months of work for a migration that happens in one slot. The Solana Foundation places the same switch in epoch 1064, which starts on that Wednesday at approximately 15:00 UTC. The feature gate was still marked not activated on the Foundation’s page on October 13.

Alpenglow is the biggest upgrade in Solana’s history. It combines the latest advancements in consensus research with erasure-coded data distribution. The result is a protocol built for one job: finalizing blocks on a global network as fast as physics allows.

Anza, Alpenglow product page

Anza’s page now lists mainnet-beta for 10/21 beside testnet and devnet, both marked completed, and frames the job as finalizing blocks as fast as physics allows. Proof of History is gone from consensus. Nodes run their own timers, vote to skip a silent leader, and move on. Votes become direct BLS-signed messages, aggregated into one compact certificate, so blockspace is for users.

It’s time.

Alpenglow goes live on mainnet-beta Wednesday, October 21, ~14:50 UTC.

18 months of work for a migration that happens in one slot. Finality drops from seconds to ~150ms.

Make sure to follow us @anza_xyz as we countdown to go-live.

Details: https://t.co/MEf26uzCMW

— Anza (@anza_xyz) October 13, 2026

THE ROAD TO EPOCH 1064

1. August 30, 2025: Solana said 99% of votes were in favor of Alpenglow after SIMD-0326 reached quorum.
2. September 24, 2026: Testnet completes the handoff and retires TowerBFT.
3. September 25, 2026: Devnet follows, giving app teams a cluster with deterministic finality.
4. October 9, 2026: Mainnet finishes the staged cut in slot time to a 200ms target.
5. October 13, 2026: Anza publishes the mainnet-beta time of about 14:50 UTC.
6. October 21, 2026: Epoch 1064 begins and the live switch is scheduled to run.

Operators rehearsed the same four-step sequence on a community cluster for five months before those public test networks moved. Nothing is supposed to reach mainnet-beta that has not already run identically upstream.

Vote Traffic Is Most of What the Chain Counts

Under TowerBFT every validator vote is an ordinary on-chain transaction, processed and stored like a user transfer. That is why Solana’s public transaction counts have been a mix of real activity and housekeeping. Solana Compass network data for October 10 to 12, after the 200ms slot cut, puts votes at about 3,060 per second against about 1,780 user transactions per second, so votes were about 63% of everything counted. The vote rate had been about 2,480 per second just before slots shortened on October 9, because more slots per second means more votes per second.

VOTE SHARE ON MAINNET IN EARLY OCTOBER

Once those votes leave the blocks, the throughput number people quote will describe user traffic rather than validator chores. The Foundation calls that an accounting change, not a throughput regression, and tells anyone who indexes blocks to re-baseline. Execution does not change. The SVM, transaction formats, programs, and fees stay as they are.

Four Steps, One Slot, No Restart

The cluster does not stop. SIMD-0384, written by Kobi Sliwinski, Ashwin Sekar, and Carl Lin of Anza, splits the feature-gate flip from the consensus handoff so user signatures are never sitting in blocks that might be rolled back. Anza expects the last step to take hundreds of milliseconds and describes a liveness impact that is, in the optimistic case, only one slot past the migration boundary.

THE MIGRATION SEQUENCE

• Activation: The Alpenglow feature gate turns on at an epoch boundary, and nothing migrates immediately.
• The 5,000-slot wait: Blocks then stop carrying user transactions and hold only votes, so every block past the boundary can be rolled back without losing anything a user signed.
• Genesis certificate: Validators wait for one block past the boundary to collect votes from 82% of stake; that block’s last ancestor before the boundary becomes the Alpenglow genesis block, and Anza says blocks typically already carry more than 95%.
• Handoff: Validators roll back everything after that genesis block, hand consensus to Votor, pack the certificate into the first Alpenglow block and an on-chain account, then accept user transactions again.

If the certificate does not form at once, the proposal keeps TowerBFT running on vote-only blocks and has validators re-send genesis votes until it does. After the handoff, TowerBFT is retired and Alpenglow runs from that genesis block forward. Agave 4.3 adds a getAgGenesisCert RPC method, also wrapped as solana alpenglow-genesis-info, that returns null while a cluster is still on TowerBFT and the certificate once it has moved. The Foundation says to gate Alpenglow-specific behavior on that call rather than on a date or a version string, because each cluster flips at its own slot.

Why Firedancer Operators Must Switch Clients

Wallet users have nothing to install. Validator operators have two hard requirements before epoch 1064 begins, and the Foundation’s upgrade guide tells them to run an Agave-based client before epoch 1064 on a release built on Agave 4.3.0. The allowed clients are Agave, Jito-Solana, or Harmonic Salsa. Firedancer and Frankendancer are not supported during the migration.

Solana Compass validator data pulled at 15:24 UTC on October 13, among the 500 largest validators, labelled about 6.8% of activated stake as Firedancer, about 7.1% as HarmonicFiredancer, about 1.6% as FireBAM, and about 0.3% as Frankendancer, or about 15.8% together. The Foundation names Firedancer and Frankendancer as unsupported and does not address the HarmonicFiredancer label by name. The genesis certificate still needs 82% of stake. Operators who are on an unsupported client have to move before that vote, and a dashboard label can trail a real switch, so the share on October 21 may be lower than the October 13 snapshot.

FIREDANCER-FAMILY LABELS AMONG THE 500 LARGEST VALIDATORS

The second requirement is cash in the vote account. Operators must hold at least 0.8 SOL above the rent-exempt minimum to pay the Validator Admission Ticket, a flat fee that is burned. The first fee is charged at the start of epoch 1064 and pays for epoch 1065. If it is not paid, the validator does not vote or produce blocks in the next epoch, and VAT is due at the start of each epoch E for inclusion in epoch E + 1. Off-chain voting no longer generates per-slot vote fees, so the ticket is the new barrier to sit in the set.

VALIDATOR REQUIREMENTS BEFORE EPOCH 1064

• Client: Run Agave, Jito-Solana, or Harmonic Salsa on a release built on Agave 4.3.0.
• Unsupported: Firedancer and Frankendancer are not supported for the migration.
• Vote-account balance: Keep at least 0.8 SOL above rent-exempt to pay the burned VAT, or the validator is out of the next epoch.

The 150ms conversation on X barely touched that client split. Speed is the recap. The operators who still need to move are the ones who can shrink the margin over the 82% genesis threshold.

The 150ms Target Is Separate From Block Time

Finality is the point after which a transaction can no longer be reversed. It is not the interval between new blocks. Solana already finished a separate cut in block production, with slot times cut from 400ms to 200ms in four stages that completed in October 2026. Compass epoch data put the first full epoch at that target, epoch 1053, at an average 218.3ms per slot and 26.2 hours long. Alpenglow does not redo that work. It replaces how a produced block becomes irreversible.

Votor, Alpenglow’s voting protocol, runs two modes at once. One round finalizes a block if 80% of stake responds. Two rounds finalize at 60%. Whichever finishes first wins, and which path is faster depends on where a node sits in the world. The Foundation’s page states 99% faster finality than TowerBFT as the comparison against today’s 12.8 seconds. The 150ms figure is a target from design work, not a live mainnet stopwatch.

Roger Wattenhofer, an Alpenglow co-author, wrote on September 30 that the Alpenglow white paper on Votor had reported an expected median of about 150ms, and that test environments were already coming in faster on a narrower clock.

Back when we wrote the Alpenglow whitepaper, we reported an expected median finalization time of about 150 ms. That number has been paraded around ever since. But we don’t have to guess anymore. Alpenglow is already running in three different test environments, so let’s have a look. 54 ms!?

Roger Wattenhofer, Alpenglow co-author, on X

He flagged that the 54ms testnet median starts when a validator receives the last shred it needs, so it measures Votor, while the white paper clock started when the leader sent the last shred and therefore covered data spread plus voting. On that testnet the fastest 10% of finalizations were around 25ms and the 90th percentile around 90ms, which he tied to location. Even adding propagation back in, he said he still expected to come in under 150ms. That remains his reading of test clusters, not a mainnet guarantee.

TOWERBFT VERSUS VOTOR ON DAY ONE

Anza’s resilience pitch is that 20% adversarial stake plus 20% offline is tolerated at the same time, which it describes as covering up to 40% of stake misbehaving or missing, against TowerBFT’s under-33% adversarial handling. That is a different shape of failure, not a simple raise of the old threshold.

Rotor Still Has No Schedule After Votor

Alpenglow was designed as two parts. Votor is the voting engine shipping in Agave 4.3. Rotor is the second half of the white paper, meant to replace Turbine’s multi-layer tree with a single relay hop so blocks are erasure-coded into slices and every node relays a share in proportion to stake. Throughput would then draw on the network’s total bandwidth instead of the leader’s upload. The Foundation says Rotor is planned for a later release once Votor is adopted, and is not yet scheduled.

Validators approved the proposal replacing Proof of History and TowerBFT in 2025, with authors Quentin Kniep, Kobi Sliwinski, and Roger Wattenhofer. That SIMD covers Votor and the related economic changes. Rotor needs its own process. Fast leader handover, which lets a leader start building before the previous block is final, is slated for Agave 4.4, and Anza also lists a later geo-aware handoff that would cut the physical distance between leaders. October 21 is the voting-engine swap. It is not the full Alpenglow diagram from the paper.

What Indexers Must Change Before the Switch

Sending a transaction and running an on-chain program are not affected. Reading the chain is. A slot can carry more than one candidate block, and Agave 4.3 tags every streamed event with a bank_id so pipelines can buffer per slot and bank, keep the candidate that is confirmed, and drop the rest. bank_id is local to a node, so anyone merging two RPC or gRPC feeds has to reconcile on the blockhash, never on that counter. Fast leader handoff in 4.4 will make multiple banks per slot more common; Anza still expects that case in under 1% of slots, which is why the field lands a release early.

BREAKING CHANGES FOR DATA PIPELINES

• Commitment: confirmed and finalized become the same state after Alpenglow is live; the Foundation says to move new code to finalized only after the switch, because on TowerBFT finalized still means a 12.8-second wait.
• Transaction counts: vote transactions vanish from blocks, so TPS dashboards that included them fall without a matching fall in user activity.
• Time: tick entries leave the shred stream with Proof of History, and Clock.unix_timestamp is set by the leader within bounds rather than as a stake-weighted median of vote timestamps.
• Participation: validator voting no longer lives in Vote program instructions inside the block; it lives in certificates on the block footer.

Yellowstone gRPC v16.0.0-rc10+solana.4.3.0 buffers bank_id for whole-block subscribers. Geyser plugins have to leave four legacy callbacks that Agave 4.3 deprecates. For users, Anza’s pitch is internet-capital-markets settlement, payments without a 1-to-3-day reconciling middle, and apps that can treat the chain more like a database. None of that requires a wallet update on October 21. It does require the people who count, stream, and index blocks to stop treating Solana’s old vote traffic as a measure of load, and it requires unsupported validator clients to be gone before the 82% genesis certificate is supposed to form.

On October 13 the Foundation’s page still showed the mainnet feature gate as not activated. The cluster, not the calendar, will show when Votor actually took over.

Disclaimer: This article is news reporting and technical analysis of a scheduled Solana protocol change. It is informational only and is not investment advice, trading advice, or a recommendation to buy, sell, or stake SOL or any other token. Readers who are considering a position in cryptocurrency, or who operate validator or staking infrastructure, should consult a qualified financial adviser and, where relevant, a qualified systems engineer familiar with Solana client operations before acting. Figures, client-support rules, activation times, and network status reflect the Anza, Solana Foundation, SIMD, and Compass materials cited here as of the dates on those materials and may change before or after epoch 1064.