CRYPCryptoExplainer NO. ---
Solana Alpenglow upgrade: Votor's 150ms finality target explained
Solana is scheduled to replace TowerBFT with Votor, the first half of Alpenglow, on October 21, 2026. Here is what changes, which figures are design rules and which are still targets, and what validators and users should watch.
Key takeaways
- Solana is scheduled to replace its TowerBFT consensus with Votor, the first half of the Alpenglow design, on mainnet-beta on Wednesday, October 21, 2026. Anza, the developer of the Agave validator client, gave the go-live time as about 14:50 UTC.
- The Solana Foundation says finality should fall from about 12.8 seconds to a target of roughly 150 milliseconds. The Foundation calls that figure "an expectation, not a constant."
- Anza says Votor tolerates 20% adversarial stake and another 20% offline stake at the same time. TowerBFT tolerated under 33% adversarial stake.
- Rotor, the second half of Alpenglow, would replace the Turbine block-propagation layer. It is not part of today's switch and has no release date.
- The handoff happens on a running network with no restart. It needs 82% of stake to sign a "genesis certificate," and only Agave-based clients can take part in the migration.
What Alpenglow is
The Solana Alpenglow upgrade starts on October 21, 2026, when Votor is scheduled to replace TowerBFT consensus on mainnet-beta. The Solana Foundation says finality should fall from about 12.8 seconds to a target of roughly 150 milliseconds, "an expectation, not a constant."
Alpenglow splits the job into two components. Votor handles voting and finality. Rotor handles how block data moves between validators. Anza describes the October 21 switch as Phase 1: Votor goes live while the existing Turbine propagation layer stays in place. Validators approved the overall Alpenglow proposal in a governance vote in September 2025. Decrypt reported that about 98% of the votes cast were in favour.
Anza calls the migration "the world's first swapping consensus engines on a live network," according to Solana Compass's report of its announcement. That is Anza's own claim, and Bullquill has not verified it independently. The company also described the effort as 18 months of work for a migration that happens in one slot.
How Votor changes consensus
The Solana Foundation's upgrade page sets out three main changes.
Votes leave the chain
Under Votor, validators send votes directly to each other rather than as transactions. Those votes are then aggregated into compact certificates using BLS signatures. Validator BLS keys were activated on mainnet on July 8, 2026, as groundwork. The certificates are recorded in a block "footer" instead of as individual vote transactions.
Two paths to finality
Votor runs two voting paths at the same time, and the first one to finalize a block wins. In the fast path, a block is final after one round if at least 80% of stake votes to notarize it. If that threshold is not met, a second round finalizes the block at 60% of stake. The same 60% thresholds apply to notarization and skip certificates. Anza's Alpenglow page says geography affects which path wins, because the speed of votes depends on where validators are located.
Proof of History stops pacing blocks
The Foundation says ticks leave the ledger and the Clock sysvar timestamp is set by the block leader within bounds. Proof of History therefore no longer sets the pace of block production. Separately, slot times were cut from 400 ms to 200 ms in four stages during October 2026. The Foundation stresses that block time and finality are different measures.
The numbers: confirmed design figures versus targets
The table below lists the main figures and says what kind of claim each one is. "Design parameter" means a rule written into the protocol specification. "Target" means a performance goal that has not yet been measured on mainnet.
| Item | TowerBFT (before) | Alpenglow / Votor (after) | Status of claim | Source |
|---|---|---|---|---|
| Time to finality | ~12.8 seconds | ~150 ms | Target; "an expectation, not a constant" | Solana Foundation |
| Fast-path finality threshold | n/a | 80% of stake, one round | Design parameter | Solana Foundation, Anza |
| Slow-path finality threshold | n/a | 60% of stake, two rounds | Design parameter | Solana Foundation, Anza |
| Fault tolerance | Under 33% adversarial stake | 20% adversarial + 20% offline, simultaneously | Design claim by Anza | Anza |
| Validator voting cost | ~1 SOL per epoch in vote fees | 0.8 SOL per epoch Validator Admission Ticket, burned | Protocol rule | Solana Foundation |
| Migration certificate threshold | n/a | 82% of stake | Specification (SIMD-0384) | SIMD-0384 |
| Block (slot) time | 400 ms | 200 ms (cut in October 2026, separate from Alpenglow) | Completed | Solana Foundation |
Data as of the research time for this article on October 21, 2026, from the sources listed below.
If the target is reached, a drop from 12.8 seconds to 150 milliseconds would make finality roughly 85 times faster. In May 2026, Anza lead economist Max Resnick told Decrypt that time to finality "came down ~100x" when test clusters switched from TowerBFT to Alpenglow. Neither figure has yet been measured under full mainnet load.
How the switch is meant to happen
The migration procedure is defined in SIMD-0384, written by Kobi Sliwinski, Ashwin Sekar and Carl Lin of Anza. The Solana Foundation's page and the specification describe the following sequence:
- Feature gate. The Alpenglow feature activates at the start of epoch 1064. Anza says "nothing migrates immediately." TowerBFT keeps running for the first 5,000 slots of the epoch.
- Vote-only blocks. After those 5,000 slots, blocks may contain only validator votes. User transactions pause during this window. The Foundation places the consensus takeover at slot 459,653,000.
- Genesis certificate. Validators pick a recent block as the starting point, or "genesis block," for Alpenglow and sign BLS votes for it. When at least 82% of stake has signed, a genesis certificate forms.
- Rollback and handoff. Validators discard the vote-only blocks after the genesis block, hand consensus to Votor and resume user transactions. SIMD-0384 says the effect on user transactions is "optimistically only one slot past the migration boundary slot." Anza expects the handoff to take hundreds of milliseconds.
The timing is an estimate
Published times differ. The Solana Foundation estimates that epoch 1064 starts at about 13:20 UTC. Anza's announcement, as reported by Solana Compass, gives about 14:50 UTC for the go-live. Solana Compass noted that Anza did not say whether 14:50 UTC refers to the feature-gate activation or the handoff. Epoch boundaries depend on how fast slots are produced, so the exact moment can move. Anza's Alpenglow page also says the mainnet migration "will be announced" after its observation period confirms the earlier test runs. When this article was written, Bullquill had not found a public confirmation that the mainnet genesis certificate had formed.
The date itself also changed. In late September, reports said activation could happen on September 28. Solana co-founder Anatoly Yakovenko and Anza research head Roger Wattenhofer pushed back against those reports on X, according to KuCoin News. Testnet then migrated on September 24 and devnet on September 25, before the October 21 date was set.
What validators need to have in place
- Client. The Solana Foundation says validators must run v4.3.2 of Agave, Jito-Solana or Harmonic Salsa before epoch 1064. Firedancer and Frankendancer are not supported during the migration.
- Vote account balance. Validators must keep at least 0.8 SOL above the rent-exempt minimum in the vote account (not the identity account) to pay the Validator Admission Ticket. The first ticket is charged at the start of epoch 1064 and covers epoch 1065. A validator that cannot pay does not vote or produce blocks in the next epoch.
- Stake outside supported clients. On October 13, Solana Compass counted about 15.8% of stake among the top 500 validators on Firedancer-family clients. By its arithmetic, that leaves about 84% on supported clients, just above the 82% genesis threshold. That snapshot is a week old, and operators may have switched clients since then.
- Jito BAM. According to Solana Compass's reading of Jito's changelog, Jito said mainnet BAM nodes would enter maintenance mode before activation and advised against running FireBAM or FrankenBAM during the transition.
What developers and users will notice
- Lower transaction counts that do not reflect lower activity. Votes leave blocks, so dashboards that count all transactions will show a sharp drop (our guide on how to read on-chain data explains what such activity metrics can and cannot tell you). In October 10–12 data cited by Solana Compass, votes averaged about 3,060 per second against about 1,780 user transactions per second. The Foundation calls this "an accounting change."
- Commitment levels.
processed,confirmedandfinalizedall remain, and no code change is required on activation day. After activation,confirmedandfinalizeddescribe the same state, andconfirmedwill be removed in a later release. The Foundation advises switching code tofinalizedonly after Alpenglow is live. - Checking whether the switch has happened. The
getAgGenesisCertRPC method returnsnullwhile the cluster runs TowerBFT and returns a certificate after migration. RPC nodes older than v4.3 return a "Method not found" error. The Foundation advises gating Alpenglow-specific logic on this call rather than on a date. - Data pipelines. A slot can now contain more than one candidate block. The Foundation advises Geyser and gRPC consumers to buffer data per slot and
bank_id.
For ordinary users, the main expected change is that transactions reach full, irreversible finality much faster. The Foundation does not promise any specific change to fees or throughput from Votor alone. Ethereum developers are working on the same problem: see our explainer on Ethereum's four-minute fast finality proposal, EIP-8453, and our report on why Ethereum postponed its Glamsterdam upgrade on the Hoodi testnet.
What is confirmed, what is scheduled, what is unverified
| Category | Items |
|---|---|
| Confirmed | Testnet (Sept 24) and devnet (Sept 25) migrations completed; BLS keys (July 8) and Validator Admission Ticket (July 22) activated on mainnet; slot time cut to 200 ms; validator requirements published. |
| Scheduled | Mainnet feature activation at epoch 1064 on October 21; Votor takeover at slot 459,653,000; fast leader handoff slated for Agave 4.4; removal of the confirmed commitment level in a later release. |
| Not yet scheduled | Rotor (Phase 2) and Firedancer support for Alpenglow. |
| Not yet verified on mainnet | ~150 ms finality; the 20+20 fault-tolerance behaviour under real attack or outage; the length of the user-transaction pause during handoff. |
What it means
Alpenglow is the largest change to Solana's core protocol so far. It replaces the voting system the network has used since launch. If Votor meets its targets, applications that need settlement certainty, such as payments, exchanges and cross-chain bridges, could treat transactions as final in a fraction of a second instead of waiting more than ten seconds. Removing votes from blocks also changes how network activity is measured, so comparisons of transactions per second before and after October 21 will not be like-for-like.
There are also real execution risks. The handoff depends on 82% of stake running supported software at the right moment, which leaves a narrow margin given the share of stake on Firedancer-family clients. Client diversity is reduced while the migration runs. The fault-tolerance model is new, and it has been tested only on test networks. The 150 ms figure will depend on stake distribution and geography. The things to watch are whether the genesis certificate forms on schedule, how long user transactions pause, what finality times look like in the first days, and when Firedancer and Rotor get dates.
Related coverage
- Zcash NU7 Explained: 25-Second Blocks and a New Fee Reserve
- Tokenized Stocks and 24/7 Trading: How They Work and the Risks
- Crypto brief: bitcoin near $82,700, ether lags as ETF flows split
- Crypto market check: bitcoin near $83K as ETF flows split
Frequently asked questions
What is Solana's Alpenglow upgrade?
Alpenglow is a new consensus protocol for Solana designed by Anza. It has two parts: Votor, which handles voting and finality, and Rotor, which handles block propagation. The October 21, 2026 mainnet switch activates Votor only.
How fast will finality be after Alpenglow?
The Solana Foundation gives a target of about 150 milliseconds, compared with about 12.8 seconds under TowerBFT. It describes 150 ms as an expectation rather than a constant, because the figure depends on stake distribution and geography.
What does 20+20 fault tolerance mean?
Anza says Votor can keep working with up to 20% of stake acting maliciously and another 20% offline at the same time. TowerBFT tolerated under 33% adversarial stake.
When does Rotor go live?
Rotor, which would replace the Turbine propagation layer, is planned for a later release after Votor is adopted. Neither Anza nor the Solana Foundation has scheduled it yet.
How can developers check whether Alpenglow is active?
The getAgGenesisCert RPC method returns null while the network runs TowerBFT and returns a certificate after the migration. The Solana Foundation recommends gating Alpenglow-specific logic on this call rather than on a date.
Sources
- Solana Foundation: Alpenglow upgrade page
- Anza: Alpenglow
- SIMD-0384: Alpenglow migration (Solana Improvement Documents)
- Solana Compass: Anza sets Alpenglow mainnet date
- Decrypt: Solana Alpenglow upgrade begins testing ahead of full rollout
- KuCoin News: Solana developers deny Alpenglow mainnet activation on September 28
- Jito BAM changelog, September 23 to October 9
This article is for information only and is not investment advice.
