Solana Alpenglow Activates October 21: What Changes for You
Short answer: Solana’s Alpenglow consensus upgrade activates on mainnet at epoch 1064, expected around 15:00 UTC on Wednesday, October 21, 2026. If you hold or stake SOL, you do nothing. Wallets, transactions and fees work exactly as before. Validators are the ones with a deadline. They must be on an Agave 4.3.0-based client and keep at least 0.8 SOL above rent-exempt in the vote account, or they stop voting and producing blocks the following epoch. Expect reported TPS to drop sharply afterward. That is an accounting change, not a slowdown.
Four days from now Solana swaps out the consensus layer it has run on since launch. Finality is supposed to fall from about 12.8 seconds to roughly 150 milliseconds. The Solana Foundation’s own page calls that figure “an expectation, not a constant,” which is the right level of caution for a change this size.
Most of the coverage this week has been about speed. This article is about the boring question underneath it. Who actually has to do something before Wednesday, and what will look different on your screen afterward.
Not investment advice. Technical details are from the Solana Foundation’s Alpenglow upgrade page and Anza’s October 13, 2026 announcement as relayed by Solana Compass. Activation timing is tied to an epoch boundary and can shift by minutes. Nothing here is a view on SOL’s price.
Jump to a Section
- When exactly does Alpenglow activate on Solana mainnet?
- Do SOL holders or stakers need to do anything?
- What actually changes under Alpenglow?
- Who Has to Act, and by When
- Why will Solana’s TPS look lower after October 21?
- Will staking rewards or your validator’s costs change?
- How do you check that Alpenglow is actually live?
- What could go wrong on activation day?
- Tips
- Warnings
- FAQ
- Sources
When exactly does Alpenglow activate on Solana mainnet?
Alpenglow activates on Solana mainnet-beta in epoch 1064, which the Solana Foundation expects to begin on Wednesday, October 21, 2026 at approximately 15:00 UTC, with the old TowerBFT consensus continuing for the first 5,000 slots of that epoch before Alpenglow takes over at slot 459,653,000 (Solana Foundation, Alpenglow upgrade page).
Anza, the core developer firm, gave a slightly earlier estimate of about 14:50 UTC in its October 13 announcement. Solana Compass worked the recent epoch durations and put the epoch boundary between roughly 14:55 and 15:10 UTC, with the actual consensus handoff 15 to 20 minutes after that once the 5,000-slot countdown runs.
The Foundation’s advice is to “track the epoch, not the clock.” Epoch boundaries drift with slot times, so a fixed hour is only ever an estimate.
Devnet has been running Alpenglow since epoch 1167 on September 25, 2026. Testnet activation was still pending as of mid-October.
Do SOL holders or stakers need to do anything?
SOL holders and stakers do not need to take any action for the Alpenglow upgrade, because signing, sending and approving transactions work exactly as they do today and no wallet migration, token swap or re-delegation is involved.
That sentence matters because the opposite message is about to appear in your inbox. Upgrades of this size attract impostor campaigns that tell users to “migrate” or “re-sign” to keep their SOL. There is no such step. Any message asking you to sign a transaction to prepare for Alpenglow is a scam.
When I checked the Foundation page for staker-specific instructions, I found that there were none, and that is the point. Your stake stays delegated to the same validator. Your rewards keep accruing per epoch. The only thing that might change is whether your validator makes the migration cleanly, which is covered below.
This part is simpler than people expect.
What actually changes under Alpenglow?
Alpenglow replaces Solana’s TowerBFT consensus with Votor, a protocol in which validators exchange votes directly and aggregate them into certificates instead of posting each vote as an on-chain transaction, which is how finality drops from about 12.8 seconds to a target near 150 milliseconds while the execution layer stays untouched.
| Component | Before October 21 | After Alpenglow |
|---|---|---|
| Consensus | TowerBFT | Votor (direct votes, aggregated certificates) |
| Finality | About 12.8 seconds | Target of about 150 ms (an expectation, not a constant) |
| Block time | 400 ms, cut to 200 ms during October 2026 | 200 ms (a separate change, already complete) |
| Vote transactions in blocks | Yes, roughly 63% of all transactions | None |
| Fault tolerance | TowerBFT thresholds | 20% adversarial plus 20% offline stake |
| Execution (SVM, programs, fees) | Unchanged | Unchanged |
| Commitment levels | confirmed and finalized differ | confirmed and finalized converge; confirmed removed later |
| Block propagation (Rotor) | Turbine | Still Turbine. Rotor is phase 2 and has no date |
Two things in that table are easy to miss. Rotor, the block-propagation half of the original Alpenglow design, is not shipping on Wednesday. And the 200 ms block time is a separate upgrade that already landed in October, so some of the speed people will credit to Alpenglow was there before it.
Who Has to Act, and by When
The work is concentrated on validators and infrastructure teams. Here is the full list by role, with the deadline that applies to each.
| Role | Required action | Deadline |
|---|---|---|
| SOL holder | None. Ignore any “migrate” or “re-sign” request. | — |
| Staker | None. Optionally confirm your validator is on an Agave 4.3.0-based client. | — |
| Validator | Run Agave, Jito-Solana or Harmonic Salsa built on Agave 4.3.0. Hold at least 0.8 SOL above rent-exempt in the vote account. Have a BLS pubkey registered. | Before epoch 1064 starts, October 21 |
| Firedancer or Frankendancer operator | Switch clients. Neither is supported during the migration. | Before epoch 1064 |
| Jito BAM operator | Expect BAM nodes to enter maintenance mode in the days before activation. Do not run FireBAM or FrankenBAM through the transition. | Per Jito’s October 9 changelog |
| RPC or indexer team | Buffer by (slot, bank_id). Re-baseline TPS dashboards. Plan the move from confirmed to finalized, but only after activation. | Before and after October 21 |
| Exchange user | Check your exchange’s status page. No deposit or withdrawal pauses had been announced by Binance, Coinbase or Kraken as of October 17. | October 21 |
The validator requirements are not new. The BLS public key requirement under SIMD-0387 activated on July 8, 2026, and the Validator Admission Ticket under SIMD-0357 activated on July 22. What is new is that Wednesday is when a validator without them is excluded from consensus.
Why will Solana’s TPS look lower after October 21?
Solana’s reported transactions per second will fall after Alpenglow activates because validator vote transactions, which Solana Compass measured at about 3,060 TPS against roughly 1,780 TPS of user transactions between October 10 and 12, 2026, leave the blocks entirely under Votor, so dashboards that count all transactions will show a drop of roughly 60% with no change in user activity.
The Foundation calls this “an accounting change, not a throughput regression.” Expect a wave of posts on Wednesday night claiming Solana’s throughput collapsed. Read the user-transaction line, not the total.
There is a second metric change that will catch out automated tooling. Proof of History stops pacing blocks, so tick entries disappear from the ledger stream. And Clock.unix_timestamp is no longer the stake-weighted median of vote timestamps. The leader sets it within a bound of the parent timestamp plus twice the elapsed slot duration. Any program logic that leaned on the old behaviour should be re-checked.
Will staking rewards or your validator’s costs change?
The Solana Foundation’s Alpenglow page does not describe any change to the staking reward formula for delegators, while the cost side for validators does change: the Validator Admission Ticket is a flat 0.8 SOL per epoch, burned, with the first payment taken at the start of epoch 1064 to cover epoch 1065.
Solana Compass notes that this replaces roughly 1 SOL per epoch that validators currently pay in vote-transaction fees out of their identity accounts. So the per-epoch cost of participating in consensus goes down a little and moves from the identity account to the vote account.
When I compared the two mechanisms, I noticed that the failure mode is different. Under TowerBFT a validator short of fees simply votes less. Under the VAT a validator that cannot pay “does not produce blocks in the next epoch.” It is a full epoch out, not a gradual degradation.
Operators can route block revenue to the vote account under SIMD-0232 so it tops itself up. That takes two epochs to apply, so it does not substitute for funding the account before Wednesday.
If you delegate, this is the one thing worth checking. A validator that misses an epoch earns nothing for you that epoch.
How do you check that Alpenglow is actually live?
Alpenglow’s activation on Solana can be confirmed by calling the getAgGenesisCert RPC method or running the CLI command solana alpenglow-genesis-info, where a null result means the cluster is still on TowerBFT and a certificate means the handoff has happened.
The Foundation is explicit that applications should gate on this call rather than on a date or a client version string. The epoch boundary can drift. The 5,000-slot countdown then runs. Only the genesis certificate tells you consensus has switched.
For a human watching on Wednesday, the practical signal is finality time on a block explorer. If confirmed and finalized start showing the same slot within a fraction of a second, Votor is running.
Here is where developers get tripped up. Do not switch your application’s commitment level to finalized before activation. On TowerBFT that still means a 12.8-second wait. Switch after the genesis certificate exists.
What could go wrong on activation day?
The main activation-day risk for Alpenglow is stake that has not migrated, because the genesis certificate forms only once validators holding 82% of stake sign the genesis block, and about 15.8% of top-500 stake was still on Firedancer-family clients as of October 13, 2026 according to Solana Compass.
That 15.8% was 6.8% Firedancer, 7.1% Harmonic Firedancer, 1.6% FireBAM and 0.3% Frankendancer. Those operators had eight days from the announcement to switch. If most do, the threshold is comfortable. If a large share does not, the handoff waits.
Anza designed the migration so that every block past the boundary carries only validator votes and “can be rolled back without losing anything a user signed.” The actual handoff, once the certificate forms, is expected to take hundreds of milliseconds.
The devnet run on September 25 is the only full rehearsal so far. Testnet had not activated as of the October 13 announcement. That is thinner than most chains would want before a consensus swap, and it is worth knowing before you plan anything time-sensitive for Wednesday afternoon UTC.
Tips
- ✅ If you stake, look up your validator on a dashboard the day before and confirm the client version starts with 4.3. Switching delegation takes an epoch to apply, so do it early or not at all.
- ✅ Avoid scheduling large transfers for 14:30 to 16:00 UTC on October 21. Not because anything is expected to break, but because it is the one window where a surprise is possible.
- ✅ If you run a bot or trading tool against Solana RPC, add a getAgGenesisCert check and treat a null result as “still on TowerBFT.”
- ✅ Bookmark the Foundation’s upgrade page. The feature gate status on that page is the authoritative record of whether activation happened.
- ✅ Treat any email, DM or pop-up asking you to “prepare your wallet for Alpenglow” as fraud. There is nothing to prepare.
Warnings
- The 150 ms finality figure is a design target. The Foundation says it is “an expectation, not a constant.” Mainnet performance after activation has not been measured yet.
- Activation time is an estimate tied to epoch 1064. It can land earlier or later than 15:00 UTC.
- Validators without 0.8 SOL above rent-exempt in the vote account at the start of epoch 1064 will not vote or produce blocks in epoch 1065. Delegators to that validator earn nothing for that epoch.
- This article describes a software upgrade. It says nothing about whether SOL is a good or bad investment.
FAQ
Will Solana stop processing transactions during the Alpenglow switch?
No pause is planned. TowerBFT runs for the first 5,000 slots of epoch 1064, then Votor takes over once validators holding 82% of stake sign the genesis certificate. Anza expects the handoff itself to take hundreds of milliseconds, and blocks in the handoff window carry only votes so nothing a user signed can be lost.
Does Alpenglow change Solana transaction fees?
No. The Solana Foundation states that execution is unchanged, meaning the SVM, transaction format, programs and fees all stay the same. Only the consensus layer, which decides how validators agree on blocks, is replaced.
Can a Firedancer validator keep running through the upgrade?
Not during the migration. The Foundation says Firedancer and Frankendancer are not supported while Alpenglow activates, so those operators must switch to Agave, Jito-Solana or Harmonic Salsa built on Agave 4.3.0 before epoch 1064. Firedancer support is expected to return after the migration, but no date has been given.
Sources
- Solana Foundation — Alpenglow upgrade page (activation epoch, validator requirements, developer changes)
- Solana Compass — Anza sets Alpenglow mainnet date, October 13, 2026 (client stake breakdown, vote TPS share, VAT details)
- Decrypt — Solana set for major speed boost via Alpenglow upgrade
🔗 Related guides
Fact-checked against the Solana Foundation’s Alpenglow upgrade page and Solana Compass’s October 13, 2026 report on Anza’s announcement, as of October 17, 2026. Activation timing is an estimate tied to epoch 1064. This is not investment advice.
