Alpenglow explained: what Solana’s consensus upgrade means for institutional stakers
Alpenglow is planned to replace TowerBFT on Solana mainnet in epoch 1064. Here’s what changes for finality, validator costs, and infrastructure, and what to ask your operator.
Alpenglow is the biggest change to Solana’s core protocol since mainnet launched. It replaces TowerBFT, the consensus mechanism Solana has run from the start, with a new voting system called Votor.
Execution stays the same. The SVM, programs, transactions, and fees do not change.
The switch is planned for epoch 1064, which begins on Wednesday, October 21, 2026. If you stake SOL, your stake account does not change. What changes is how fast your transactions become final, how validators pay to take part in consensus, and what your operator had to do to stay in the active set.
Here’s what you need to know, and what to ask your operator before and after the switch. For the protocol design in depth, read our earlier explainer, Alpenglow: Solana’s leap toward real-time consensus.
Alpenglow ships in two phases
Phase 1 is Votor. Validators send votes directly to each other instead of as transactions, combine them into certificates, and finalize a block in one or two rounds. Votor ships in Agave 4.3, and it is what is planned to activate in epoch 1064 (Solana Foundation).
Phase 2 is Rotor. It replaces Turbine, the protocol that spreads block data across the network, with a single layer of relay nodes. Rotor is planned for a later release and is not yet scheduled (Solana Foundation). Turbine stays in place for now.
When it happens
- July 8, 2026: BLS public keys in vote accounts (SIMD-0387) went live on mainnet (Solana Foundation).
- July 22, 2026: The Validator Admission Ticket (VAT, SIMD-0357) went live on mainnet (Solana Foundation).
- September 25, 2026: Alpenglow activated on devnet (epoch 1167, Solana Foundation).
- October 2026: Slot times finished dropping from 400ms to 200ms, in four stages (Solana Foundation). This is a separate change from Alpenglow.
- October 21, 2026: Alpenglow is planned to activate on mainnet at the start of epoch 1064.
- Later: Rotor. Not yet scheduled.
How the switch works
The feature gate is set to turn on at the start of epoch 1064. TowerBFT keeps running for the first 5,000 slots, about 18 minutes at current slot times (Solana Foundation). During that window, validators vote on an Alpenglow genesis certificate. Anza says that certificate needs votes from 82% of stake. Once it forms, consensus hands off to Votor at slot 459,653,000 (Solana Foundation).
Watch the epoch, not the clock
The Solana Foundation estimates epoch 1064 starts around 13:20 UTC. Anza has posted about 14:50 UTC. Epoch start times drift with slot timing, so track the epoch and the slot number rather than a clock time.
How to confirm the switch
Call the getAgGenesisCert RPC method, or run solana alpenglow-genesis-info. It returns null while the cluster still runs TowerBFT, and the Alpenglow genesis certificate once it has switched. An RPC node older than v4.3 returns a “Method not found” error instead (Solana Foundation). On October 20, mainnet RPC still returned null.
Status at a glance
As of October 20, 2026. Sources: Solana Foundation Alpenglow and BLS pubkey and VAT pages.
| Item | Status | Notes |
| TowerBFT on mainnet | Live until the switch | Ends at slot 459,653,000 in epoch 1064 |
| Votor on mainnet | Planned for October 21, 2026 | Epoch 1064, handoff about 18 minutes in |
| Alpenglow on devnet | Live since September 25, 2026 | Epoch 1167 |
| BLS pubkeys (SIMD-0387) | Live since July 8, 2026 | Required for VAT admission |
| VAT (SIMD-0357) | Live since July 22, 2026 | 0.8 SOL fee per epoch, first charged at epoch 1064 |
| Required client | v4.3.2, Agave-based | Agave, Jito-Solana, or Harmonic Salsa |
| Firedancer and Frankendancer | Not supported during migration | Operators switch to an Agave-based client |
| Rotor | Later phase | Not yet scheduled. Turbine stays for now. |
Votor: finality in about 150 milliseconds
What it solves
Under TowerBFT, validators vote by sending transactions. A block is final once enough votes stack up over 32 slots, which takes about 12.8 seconds (Solana Foundation). That is slow for any use case that needs settlement certainty in under a second.
What changes
Validators send votes to each other, and the votes combine into certificates.
- Fast path: a block finalizes in one round if at least 80% of stake votes to notarize it.
- Second round: if not, a second round finalizes it at 60% thresholds.
- Resilience: Votor tolerates 20% adversarial stake plus another 20% offline (Solana Foundation).
The Solana Foundation targets finality of about 150 milliseconds, down from about 12.8 seconds. It calls 150ms an expectation, not a constant. Anza’s simulations of the full design, Rotor included, put the median at about 150ms, and sometimes as low as 100ms.
A few more things move:
- Vote transactions leave the block. Validator participation now shows up in certificates in the block footer.
- Proof of History no longer paces block production. Tick entries leave the shred stream.
- The leader sets the block timestamp within a bounded range, instead of a stake-weighted median of vote timestamps.
- confirmed and finalized become the same state. confirmed will be removed in a later release. Until the cluster switches, finalized still means the 12.8-second wait, so don’t change commitment levels early.
- A slot can carry more than one candidate block. Agave 4.3 adds a bank_id to Geyser streams. Indexers and stream consumers need to track each (slot, bank_id) pair on its own.
What it means for you
- Ask how your operator and custodian will treat confirmed and finalized after the switch, and what that does to your accounting and custody workflows.
- Re-baseline TPS and participation dashboards. Vote transactions make up a large share of reported transactions. When they leave the block, transaction counts drop. That is an accounting change, not a fall in real activity (Solana Foundation).
- Gate any “Alpenglow is live” logic on getAgGenesisCert, not on a date or a version number.
BLS keys and the Validator Admission Ticket
What it solves
Votor’s certificates rely on aggregate BLS signatures, so every voting validator needs a registered BLS key. The network needs a bounded, known set of validators before the consensus switch.
What changes
BLS public keys (SIMD-0387) went live on July 8, 2026. The Validator Admission Ticket (SIMD-0357) went live on July 22, 2026.
VAT caps the admitted set at 2,000 validators (Solana Foundation). Validators without a registered BLS key are left out of that set and stop taking part in consensus. VAT does not turn Alpenglow on by itself.
The validator cost model changes too, per the Solana Foundation:
- Today: voting costs about 1 SOL per epoch in vote transaction fees, paid from the identity account.
- Under Alpenglow: those fees go away. Each voting validator pays a flat 0.8 SOL per epoch from its vote account instead, and the fee is burned.
- Funding: the 0.8 SOL sits on top of the vote account’s rent-exempt minimum.
- Timing: the fee is paid one epoch ahead. The first charge comes at the start of epoch 1064 and covers epoch 1065.
- If the vote account can’t pay, the validator doesn’t vote or produce blocks in the next epoch, and it loses that epoch’s rewards.
An epoch is 432,000 slots. At 200ms per slot, that is about 24 hours, so the fee comes due about once a day.
What it means for you
- Confirm your validator’s BLS key is registered and its vote account is in the admitted set.
- Confirm the vote account holds at least 0.8 SOL above rent-exempt before epoch 1064, and that your operator has a process to keep it funded every epoch after.
Agave 4.3 and the client question
What changes
Every validator must run v4.3.2 of an Agave-based client before epoch 1064 (Solana Foundation): Agave v4.3.2, Jito-Solana v4.3.2-jito, or Harmonic Salsa v4.3.2-harmonic.
Firedancer and Frankendancer are not supported during the migration. Operators running either one must move to an Agave-based client before the epoch starts.
That matters for the switch itself. Solana Compass estimated on October 13 that Firedancer-family clients run by the 500 largest validators carried about 15.8% of stake. Any of that stake that hasn’t moved can’t vote toward the 82% genesis certificate. If none of it moved, about 84% of stake would be left to clear an 82% bar.
Fast leader handoff, which makes multiple candidate blocks per slot more common, ships later in Agave 4.4. Anza expects it in under 1% of slots (Solana Foundation).
What it means for you
- Ask which client and version your operator will run through the switch, and what the rollback plan is.
- If your operator runs Firedancer in normal times, ask when they expect to move back, and what that means for client diversity in the meantime.
- Follow Anza and the Solana Foundation for upgrade cues, not secondary blogs.
What Alpenglow does not change (yet)
- Rotor is a later phase. Turbine stays in place at activation.
- The 200ms slot time is a separate change. Slot time is about how often blocks are produced. The 150ms figure is about how long a block takes to become final.
- Users who only sign and send transactions don’t need to do anything. Wallets and apps keep working.
- Infrastructure teams do need a plan. Anything that streams blocks, merges data from several providers, or indexes votes is affected.
A checklist for institutional stakers
- Confirm your operator runs v4.3.2 of Agave, Jito-Solana, or Harmonic Salsa.
- Confirm BLS registration and VAT admission on each vote account.
- Confirm each vote account holds at least 0.8 SOL above rent-exempt, every epoch.
- Check getAgGenesisCert on an RPC you trust. null means TowerBFT is still running.
- Move to finalized only after the switch.
- Re-baseline indexers and dashboards that counted vote transactions.
- Keep Turbine assumptions until Rotor is scheduled.
The bigger picture
Alpenglow is Solana’s first full consensus replacement (Solana Foundation). Execution stays put. Consensus, validator economics, and the data around each block all change.
For institutions, the fundamentals don’t move. Staking still rests on operator quality, client choices, and clean custody workflows. What grows during a migration like this is the operational surface area, and that’s where an experienced operator earns its keep.
We’ll update this briefing once getAgGenesisCert confirms mainnet has switched.
Stake Solana with stakefish
stakefish runs institutional-grade Solana validators with a focus on uptime and transparent reporting.
- Stake SOL with stakefish
- Talk to us about institutional staking
- Read the Solana staking API docs
Sources
Facts checked October 20, 2026.
- Solana Foundation: Alpenglow upgrade
- Solana Foundation: BLS pubkey and VAT
- Anza: Agave v4.3 release schedule
- Anza: Alpenglow, a new consensus for Solana
- Solana Compass: Anza sets Alpenglow mainnet date
- stakefish: Alpenglow, Solana’s leap toward real-time consensus
Building staking into a platform? The stakefish Multi-Chain Staking API and SDK cover Ethereum, Solana and more. Read the API docs.
Stake now at: stake.fish/stake
About stakefish
Founded in 2018 by Ethereum and Bitcoin veterans, stakefish is the leading validator for Proof of Stake blockchains. With support for 20+ networks, we combine institutional‑grade infrastructure with intuitive dashboards, transparent reporting, and a spotless slashing record so individuals and institutions alike can stake confidently while strengthening decentralized networks.
Visit our website 🐠 | Telegram | X | YouTube | LinkedIn
