Anza Sets Alpenglow Mainnet Date: Solana's Consensus Switch Is Scheduled for October 21 at About 14:50 UTC

Anza has set the Alpenglow mainnet date. The team that builds the Agave validator client said on October 13, 2026 that Alpenglow "goes live on mainnet-beta Wednesday, October 21, ~14:50 UTC", replacing TowerBFT, the consensus protocol Solana SOL$107.62-1.4% has run since genesis. Consensus is how the network's validators agree on the order of transactions and on the point after which a transaction can no longer be reversed, known as finality. Anza says finality "drops from seconds to ~150ms".

The switch is scheduled as a handoff on a running network, with no restart. Anza's post describes "18 months of work for a migration that happens in one slot." Its Alpenglow page now lists "Mainnet-beta 10/21" beside testnet (September 24) and devnet (September 25), both marked completed, and calls the migration "the world's first swapping consensus engines on a live network."

Wallet users and most app developers have nothing to do. Validator operators have two hard requirements to meet before the date, and anyone who streams or indexes block data has changes to make.

How the Alpenglow mainnet migration works: a feature gate, 5,000 slots and an 82% genesis certificate

The migration runs in four steps, set out on Anza's page and specified in SIMD-0384, written by Kobi Sliwinski, Ashwin Sekar and Carl Lin of Anza. Mainnet-beta follows the same sequence testnet ran on September 24 and devnet ran a day later.

1. Activation. The migration feature gate activates at an epoch boundary. In Anza's words, "Nothing migrates immediately."
2. The boundary. 5,000 slots after activation, blocks stop carrying user transactions and hold only validator votes. Anza says this is what makes the handoff safe: "every block past the boundary can be rolled back without losing anything a user signed."
3. Genesis. Validators wait for one block past the boundary to receive votes from 82% of stake in the following slot. That block's last ancestor before the boundary becomes the Alpenglow genesis block. Validators sign a vote for it, and once 82% of stake has signed, a genesis certificate forms. Blocks typically receive more than 95%, per Anza, so it expects TowerBFT to produce one more block before the handoff.
4. The handoff. Validators roll back everything after the genesis block, hand consensus to Votor (Alpenglow's voting protocol) and start accepting user transactions again. Anza expects this step "to take hundreds of milliseconds."

SIMD-0384 describes "a liveness impact for the duration of the migration, which is optimistically only one slot past the migration boundary slot." In plain terms, user transactions wait from the boundary until the handoff completes. If the certificate does not form at once, the proposal has validators keep running TowerBFT on vote-only blocks and re-send their genesis votes until it does.

Epoch 1064 and the 14:50 UTC time: what Solana Compass epoch data shows

Anza has not said whether ~14:50 UTC marks the feature gate activating or the handoff itself. Solana Compass epoch data suggests the former. Epochs have lasted about 26.2 hours since the 200ms slot time went live at epoch 1053, and epoch 1056 began at 21:18 UTC on October 12. At that pace, epoch 1064 would begin between roughly 14:55 and 15:10 UTC on October 21, within minutes of Anza's time. The 5,000-slot countdown adds about 17 to 18 minutes at current slot times, which would put the handoff between roughly 15:10 and 15:30 UTC. That is our arithmetic from three completed epochs at the new slot time, and epoch lengths drift by a few minutes.

Validator requirements before October 21: an Agave-based 4.3 client and 0.8 SOL in the vote account

Validator operators must do two things before Alpenglow activates, according to the Solana Foundation's Alpenglow upgrade page, which defers to Anza's operator documentation as the authoritative checklist.

• Run an Agave-based client: Agave, Jito-Solana or Harmonic Salsa, "on a release built on Agave 4.3.0." The page states that "Firedancer and Frankendancer are not supported during the migration" and tells operators running either to switch and "give yourself time to run the new client in production before the feature gate flips."
• Hold at least 0.8 SOL in the vote account, above its rent-exempt minimum. The balance pays the Validator Admission Ticket, a flat 0.8 SOL per epoch that is burned. The Foundation says a validator that cannot pay "does not produce blocks in the next epoch." The fee replaces the roughly 1 SOL per epoch that validators pay today in vote transaction fees from their identity accounts.

Neither page names a minimum patch release beyond 4.3.0. Jito JTO$0.542+0.2% wrote in its October 9 BAM changelog that "Anza and the Solana Foundation have not yet specified the mainnet transition version," and that it would confirm its own minimum before activation. The same changelog says all mainnet BAM (Block Assembly Marketplace) nodes will go into maintenance mode in the days before activation and tells operators not to run FireBAM or FrankenBAM during the transition, as we reported on October 10.

How much Solana stake still runs Firedancer-family clients

The client requirement is the one with the most stake attached. In Solana Compass validator data pulled at 15:24 UTC on October 13 (the live view is our validator dashboard), among the 500 largest validators, those labelled as running Firedancer held about 6.8% of total activated stake. Validators labelled HarmonicFiredancer held about 7.1%, FireBAM about 1.6% and Frankendancer about 0.3%. Together that is roughly 15.8% of stake.

The Foundation's page names Firedancer and Frankendancer as unsupported and Jito's changelog covers FireBAM; neither addresses the HarmonicFiredancer label by name. The genesis certificate needs 82% of stake. By our arithmetic, if none of that 15.8% took part in the genesis vote, about 84% of stake would be left, roughly two points above the threshold before counting any validator that is offline for another reason. Operators have eight days to change clients, and a client label can trail an operator's actual switch, so the share on October 21 may be lower.

RPC providers, indexers and Geyser consumers: bank_id, vote transactions and commitment levels

Sending transactions and running programs are unaffected, because Alpenglow changes consensus and leaves execution alone. The Foundation's page lists what does change for infrastructure that reads block data. Triton One covered the same ground for its customers, which we summarised in our write-up of its integrator guide.

• Streaming through Geyser or gRPC: Agave 4.3 tags every event with a bank_id, because a slot can carry more than one candidate block. Pipelines should buffer per slot and bank_id, keep the candidate that is confirmed, and reconcile feeds from different providers on the blockhash.
• Commitment levels: confirmed and finalized become the same state. Nothing breaks on activation day. The Foundation advises moving to finalized only after Alpenglow is live, because on TowerBFT "finalized still means a 12.8-second wait."
• Transaction counts: vote transactions leave blocks at activation, so any dashboard that counts them will show a sharp fall. The Foundation calls it "an accounting change, not a throughput regression."
• Time: Proof of History no longer paces blocks, so tick entries leave the data stream and the Clock sysvar's timestamp is set by the block leader within bounds.

Votes are a large share of what is counted today. On Solana Compass network data, vote transactions averaged about 3,060 per second from October 10 to 12, against about 1,780 user transactions per second, which makes votes about 63% of the total. The vote rate stepped up from about 2,480 per second when slots shortened on October 9, since more slots per second means more votes per second.

What changes for Solana users: finality from 12.8 seconds to about 150ms

For users, the change is how quickly a transaction becomes irreversible. The Solana Foundation puts finality today at about 12.8 seconds and Alpenglow's target at roughly 150 milliseconds, and says "wallets and apps keep working as they do today." Nothing about signing or sending a transaction changes.

The Foundation attaches a qualification to the headline number: "The 150ms is an expectation, not a constant." It was measured against the stake distribution at the time of testing. Votor finalizes a block in one round of voting if 80% of stake responds, or in two rounds at 60%, and whichever finishes first wins. The 150ms is also separate from block time, which the Foundation says was cut from 400ms to 200ms in four stages that completed in October 2026.

Anza says the design tolerates 20% of stake acting maliciously and another 20% being offline at the same moment, where TowerBFT tolerated under 33% adversarial stake. Because votes become signed messages passed directly between validators, the block space they used is freed for user transactions.

From testnet and devnet to Rotor: where October 21 sits in the Alpenglow rollout

The October 21 migration is scheduled as the last step of Alpenglow's first phase. The Foundation's page records the groundwork on mainnet: validator BLS keys (the signature scheme Votor's certificates use) activated on July 8, 2026, and the Validator Admission Ticket on July 22. Agave 4.3 carries Votor itself. Anza says operators rehearsed the migration on a community cluster over five months, and it counts nine successful migrations at scale and simulations across 1,500 nodes.

The second phase is Rotor, which is planned to replace Turbine, the protocol that spreads block data across the network, with a single relay layer. The Foundation says Rotor "is not yet scheduled." Fast leader handoff, which lets a leader start building before the previous block is final, is slated for Agave 4.4, according to the same page.

On the day, the cluster itself is the reference. Agave 4.3 adds a getAgGenesisCert RPC method that returns null while a cluster is on TowerBFT and the genesis certificate once it has migrated, and the Solana CLI wraps it as solana alpenglow-genesis-info. The Foundation advises gating any Alpenglow-specific behaviour "on this call rather than on a date or a client version string." Its page still showed the mainnet feature gate as "Not activated" on October 13.