What Alpenglow changes for SOL stakers

What changes on October 21, 2026

As of today, October 18, 2026, Alpenglow is scheduled to activate on mainnet at the start of epoch 1064 (an epoch is about 2 days), around October 21, 2026. It's already live on testnet and devnet. Nothing below has happened on mainnet yet — this block will be updated once it does.

What is Alpenglow, actually?

Alpenglow replaces the part of Solana that decides when a block is final — today's TowerBFT, based on Proof of History — with a new protocol called Votor. Instead of voting through on-chain transactions, validators exchange votes directly and bundle them into certificates, so a block can be considered final after one or two rounds instead of waiting ~12.8 seconds. Solana's own page targets about 150ms for finality under normal conditions.

What doesn't change: the SVM, transactions, programs and fees. Alpenglow is a consensus change, not an execution change. Block propagation (the part called Turbine, which spreads a block across the network) is untouched for now too — a separate future piece called Rotor is meant to replace that later, with no date set yet.

Source: solana.com/upgrades/alpenglow; SIMD-0326.

When does it activate?

Epoch 1064, starting around October 21, 2026, roughly 15:00 UTC. As of today (October 18, 2026) it's live and active on testnet and devnet; mainnet itself is still "not activated" — it switches on at the start of that epoch. Source: solana.com/upgrades/alpenglow.

Do you need to do anything as a delegator?

No. Solana's own migration checklist is explicit: "For Users: No action needed." Wallets and apps keep working as they do today — you'll just notice transactions confirm faster. Source: solana.com/upgrades/alpenglow.

Why you might see mentions of "BLS keys" and a new validator fee

Two validator-side changes are getting attention, and it's worth knowing what they are even though neither is something you do. Both live on the validator's own vote account — a separate account the validator itself controls, not your stake account, so neither touches your SOL:

• A BLS key. Alpenglow's vote certificates use a different kind of cryptography (BLS12-381) than the key validators vote with today, so every validator has to register a separate BLS public key on its vote account to keep voting once Alpenglow is live. This has already been possible since July 8, 2026, and a validator without one stops voting and stops earning inflation rewards. Source: SIMD-0387; solana.com/upgrades/bls-pubkey-vat.
• A per-epoch fee called the VAT ("Validator Admission Ticket" — not a tax, just Solana's own name for this fee). Once Alpenglow is live, every validator included in the next epoch's voting set is charged a flat 0.8 SOL per epoch, burned, taken from the validator's own vote account one epoch ahead. It's what a validator pays to be allowed to vote — it isn't taken from your delegation. Source (canonical, activation page): solana.com/upgrades/bls-pubkey-vat.

Note on the figure: earlier drafts of this proposal mentioned 1.6 SOL per epoch; the live solana.com page now says 0.8 SOL, so this guide uses that figure.

Why only 2,000 validators?

Alpenglow caps the voting set at the 2,000 highest-staked validators. A validator with a registered BLS key that falls outside the top 2,000 by stake is excluded from voting for that epoch — not banned or slashed, just left out of consensus until its stake rank rises again. Source: SIMD-0326; SIMD-0357; solana.com/upgrades/bls-pubkey-vat.

What happens to your stake if your validator isn't ready?

A validator has to do three things before epoch 1064: run upgraded, Alpenglow-compatible validator software, register its BLS key, and keep at least 0.8 SOL in its vote account to cover the VAT fee. Source: solana.com/upgrades/alpenglow; solana.com/upgrades/bls-pubkey-vat.

If a validator misses any of those, it's excluded from the voting set: it doesn't vote, doesn't produce blocks, and stops earning inflation rewards for that period. This is automatic, with no stated grace period beyond the one-epoch head start the VAT billing already gives it.

For you as a delegator: your SOL stays in your stake account the whole time. As we understand it, a validator that isn't earning inflation rewards can't pass any on to its delegators either, so a non-admitted validator would generate no rewards for the delegators behind it that period — Solana's own documentation doesn't spell this out for delegators specifically, so this is our reading of how admission and rewards connect, not a direct quote. In practice this looks and behaves exactly like a validator going offline for any other reason, which our offline-validator guide already covers.

What should you check, if you want to?

Nothing is required of you either way. Until a dedicated readiness check per validator exists, the only practical signal is the existing offline/delinquent detection — a validator excluded for not being ready simply stops voting, which that detection already watches for.

Two more upgrades you might hear about (not part of Alpenglow)

These sometimes get mentioned alongside Alpenglow news but are separate, unrelated proposals, both still at the discussion stage:

• SIMD-0550 ("double disinflation"). A proposal to speed up Solana's issuance taper, from −15%/year to −30%/year — a proposal under review, not scheduled. Source: SIMD-0550.
• SIMD-0123 ("block revenue sharing"). A proposal letting a validator optionally share part of its block-fee revenue with its delegators — a proposal under review, not scheduled. Source: SIMD-0123.