Solana’s Alpenglow Upgrade Is Live

• Votor, the first phase of Alpenglow, took over Solana consensus at slot 459,653,000 on 21 October 2026, about 18 minutes after epoch 1064 began at roughly 13:36 UTC.
• Solana finality now targets roughly 150 milliseconds against about 12.8 seconds under TowerBFT, and an outside 24-hour mainnet sample reported by TokenPost recorded a 404-millisecond median.
• Validators send votes directly to each other and bundle them into certificates, so vote transactions, about six in every ten transactions processed in the week before the switch, have left the blocks.
• The confirmed and finalized commitment levels now describe the same state, and confirmed is scheduled for removal in a later release.
• Every voting validator pays a burned 0.8 SOL Validator Admission Ticket each epoch from its vote account, which replaced vote transaction fees.
• Firedancer and Frankendancer could not make the migration, so mainnet consensus switched over on Agave-based clients alone.

On 21 October 2026, Solana replaced the consensus protocol it had run since its March 2020 launch. The Solana Alpenglow upgrade retired TowerBFT and moved the network onto Votor, a voting system in which validators exchange votes directly and can finalize a block in one or two rounds. The switch happened on a live network carrying user traffic, and the handoff from the old protocol to the new one took about 900 milliseconds.

The number attached to the upgrade is finality, the point after which a transaction can no longer be reversed. TowerBFT took about 12.8 seconds to reach it, and Alpenglow targets roughly 150 milliseconds. Anza chief executive Brennan Watt called it, in a launch statement shared with The Block, “the largest, most ambitious blockchain upgrade since ‘The Merge'”.

How the Alpenglow mainnet switch happened

The activation was a two-stage event, which is why reported times differ by roughly 20 minutes across sources. The feature gate turned on at the start of epoch 1064, which the Solana Foundation places at approximately 13:36 UTC on Wednesday, 21 October 2026. TowerBFT then kept running for 5,000 more slots, about 18 minutes, so that every validator could converge on one handoff point.

The future of finance is here. Trade crypto and more

The last block of that window, slot 459,652,999, became the Alpenglow genesis block. Its genesis certificate carried votes from 446 of the 654 validators participating in the network, enough stake to certify it, and Votor consensus ran from slot 459,653,000 onward. Anza told The Block that consensus reached mainnet-beta at that slot at approximately 14:00 UTC.

Anyone can confirm the migration without trusting an announcement. Agave 4.3 added a getAgGenesisCert RPC method that returns null while a cluster is still on TowerBFT and returns the genesis certificate once it has migrated, and the Solana command-line tool exposes the same check through solana alpenglow-genesis-info. The Foundation recommends gating any Alpenglow-specific behavior on that call, because devnet, testnet and mainnet each switched at a different slot.

The mainnet date postpone

The mainnet date also moved during the final weeks. Anza’s Agave 4.3 release schedule, published on 12 August, had targeted 28 September for mainnet feature activation. The rollout instead completed its handoff on testnet on 24 September and on devnet on 25 September, and mainnet followed on 21 October. The table below traces the full path from whitepaper to production.

Two patterns run through that sequence. The governance mandate was unusually broad for Solana, where fee and inflation proposals have drawn far closer votes, and the identity and admission prerequisites went live three months before consensus changed. That ordering let operators fix key registration problems while TowerBFT was still producing blocks, which reduced the number of things that could go wrong on activation day.

What Votor replaced inside Solana consensus

The upgrade makes more sense once the job of consensus is clear. Consensus is the process by which validators agree on the order of transactions and on the moment a block becomes irreversible. Under TowerBFT, validators expressed that agreement by submitting vote transactions that were themselves written into later blocks, and a block became final once enough of those votes had stacked up across 32 slots, which took about 12.8 seconds.

Votor moved that exchange off the ledger. Validators now send votes directly to one another and combine them into certificates using BLS signatures, a scheme that compresses many signatures into one aggregate that anyone holding the validators’ public keys can verify. A block can become final after a single round of voting or after two, depending on how quickly stake converges.

Which route is the fast path?

The single-round route is the fast path. When at least 80% of stake votes to notarize a block, meaning those validators attest that it is valid and should be adopted, a fast-finalization certificate makes it final immediately. When notarization lands between 60% and 80% of stake, the protocol runs a second round, and a finalization certificate backed by 60% of stake completes the job. The certificates Votor can produce are summarized below.

Those thresholds are the source of Alpenglow’s resilience claim. The Foundation describes the protocol as reaching consensus while tolerating 20% of adversarial stake plus a further 20% of offline stake. The same arithmetic prevents two competing blocks from being notarized in one slot, since both crossing the 60% line would require 120% of all stake to exist.

Network latency and geography

Which route a block takes is decided by network latency and geography. The Foundation notes that a tightly clustered 60% of stake can complete two rounds before a widely dispersed 80% completes one, so the two-round path is sometimes the quicker one. Nothing in a wallet or an explorer reveals which path finalized a given transaction, and there is no new status between processed and finalized.

Buy bitcoin and stocks. Signup to Coinbase today

Votor also ended Proof of History’s role in pacing block production. Leaders no longer emit the 64 tick entries per slot that once marked time inside a slot, and the Clock sysvar timestamp, previously a stake-weighted median of the timestamps validators attached to their votes, is now set by each block’s leader inside a bounded range. Transaction execution stayed where it was. The Solana Virtual Machine, transaction formats, programs and fees are unchanged.

Alpenglow finality: the 150ms target against the first mainnet readings

With the mechanics in place, the practical question is how quickly finality arrives on mainnet. The Foundation frames 150 milliseconds as an expectation, measured against the stake distribution during testing, and says the figure moves as that distribution changes and is lower on the one-round path. Anza economist Max Resnick had told Decrypt earlier in the year that users would feel confirmation times of roughly 150 to 200 milliseconds.

Test environments ran faster than the target. Data from the Alpenglow community test cluster, collected through August 2026, showed a 54-millisecond median finalization time, with most blocks taking the fast path, according to Solana Compass figures reported by Crypto Briefing. A test cluster runs far fewer validators than mainnet, so the result works best as an optimistic lower reference for mainnet.

The first outside mainnet sample came in slower. A sample published by TokenPost, covering more than 357,000 slots across the 24 hours ending 12:30 UTC on 23 October, recorded a median observed finality of 404 milliseconds, a 90th percentile of 579 milliseconds and a 99th percentile of 765 milliseconds. The clock started when a public RPC node first reported a slot and stopped when it reported a root at or above that slot.

That method explains part of the distance from the target. An RPC node sits downstream of the validators that vote, and Anza has said that some machines receive finality information later than the validators voting directly. The 404-millisecond figure is therefore a view from the edge of the network, and it still excludes the path from a wallet submission to an exchange crediting an account. The report also cautioned that a pre-upgrade median of about seven seconds used whole-second block-time data, which makes a like-for-like before and after comparison impossible from that source alone.

What’s the biggest difference between chains?

Even with those caveats, the scale of the change is clear. The median in that sample sits roughly 32 times below TowerBFT’s 12.8 seconds, and the 99th percentile sits about 17 times below it. A safety valve covers the bad days: if a block fails to finalize for 10 seconds, validators progressively lengthen block times so that messages have more time to arrive. Slot time is a separate measure, and Solana cut it from 400 to 200 milliseconds in four stages that finished in October 2026.

Placing those figures beside other networks shows where Solana now sits. Each network reaches finality by a different mechanism, so the table compares design and observed reference points.

The table carries one lesson for readers comparing chains. A design target, a test-cluster result and an edge-of-network measurement are three different quantities, and the right figure depends on whether the reader is a validator, an application or an exchange. Independent measurements over several weeks, and under heavy load, will matter more than any single reading from launch week.

What Alpenglow changes for exchanges, wallets and payment apps

For people holding SOL in a wallet or on an exchange, the Foundation’s guidance is that nothing needs to change: signing, sending and approving transactions work exactly as before, and fees are untouched. The real differences sit with the businesses that decide when a transfer counts as received.

The future of finance is here. Trade crypto and more

Finality is the moment an exchange, bank or merchant waits for before treating an asset as moved, and on Solana that wait used to be 12.8 seconds. Many applications sidestepped it by acting on the earlier confirmed status, which arrived quickly but carried a theoretical risk of rollback. Under Votor, confirmed and finalized describe the same state, so a service can take the stronger guarantee without the old delay. The Foundation now tells developers to point new code at finalized, because confirmed will be deprecated and later removed.

Faster crediting becomes possible as a result, and the decision still rests with each venue. An exchange could credit a SOL or stablecoin deposit sooner and let a customer trade with the funds, but its crediting rules, risk checks and internal batching determine what the customer actually sees. The same layering appears in crypto derivatives clearing, where the clearing house fixes when an obligation is settled and each broker sets its own rules for when clients can use the proceeds.

Payment flows built on stablecoins gain the most visible benefit, because a merchant holds an unsettled transfer for a far shorter window. Price stability is a separate matter, and the reasons stablecoins depeg sit in reserves, redemption and market structure, all of which a consensus upgrade leaves untouched.

The most affected stakeholders are data providers

Data providers face the most immediate work. Vote transactions made up roughly 62% of everything Solana processed in the week before the switch, about 263 million a day between 14 and 20 October against 145 million to 175 million non-vote transactions, according to Solana Compass figures reported by Memeburn. With votes gone from blocks, raw transaction counts and throughput charts fell sharply with no fall in real activity, and every dashboard, alert threshold and historical comparison that included votes needs a new baseline.

Indexers and streaming pipelines carry a subtler change. A slot can now hold more than one candidate block, so Agave 4.3 tags every Geyser streaming event with a bank_id identifying which candidate it belongs to. A pipeline that keys on the slot number alone can fuse two competing candidates into one block without noticing. Anza expects multiple candidates in under 1% of slots once fast leader handoff ships in Agave 4.4, and it is asking teams to adopt the field now, while mistakes are cheap.

Perpetual futures venues, where positions are marked continuously and funding payments settle on tight clocks, are the clearest candidates to benefit from faster finality, and Solana starts from a small base in that market. On 22 October, Solana perpetuals open interest stood at about $285.6 million, roughly 3.6% of Hyperliquid’s $7.91 billion, with about three quarters of it on GMX’s Solana deployment, according to the same Memeburn report.

Validator economics: the 0.8 SOL Validator Admission Ticket

Removing vote transactions also removed the fees validators paid to cast them, and Alpenglow replaced those fees with a flat charge. Under TowerBFT, voting cost about 1 SOL per epoch in transaction fees, paid from a validator’s identity account, according to the Foundation. Under SIMD-0357, the Validator Admission Ticket, known as the VAT, charges each voting validator 0.8 SOL per epoch from its vote account, and that SOL is burned.

Estimates of the saving vary with the baseline. ChainCatcher’s launch coverage put pre-switch vote fees at about 2 SOL a day, a figure it said had doubled after slot times were halved, and projected a cost reduction of roughly 60%. The Foundation’s own figure is the more conservative anchor, and on either reading the cost of participation fell and became predictable.

The ticket is paid one epoch in advance. The first charge came at the start of epoch 1064 and paid for participation in epoch 1065, and each epoch since, the fee charged at the start of epoch N pays for epoch N plus one. A vote account that cannot cover the fee is not admitted for the next epoch, so the validator neither votes nor produces blocks and forfeits that epoch’s rewards. Operators can route block revenue to the vote account under SIMD-0232 so the balance refills automatically, although the change takes two epochs to apply and the Foundation advises funding the first fee manually.

Buy bitcoin and stocks. Signup to Coinbase today

The software requirements on Solana tightened

Mainnet validators must run version 4.3.2 of an Agave-based client, which means Agave itself, Jito-Solana or Harmonic Salsa. Validators that never registered a BLS public key have been excluded from the admitted set since 22 July. The table below summarizes the shift for operators.

That table frames the economics for a network with a large staked base. A Bitwise staking report covered by Solana Compass found 69% of SOL staked at the end of the third quarter, with a 5.99% gross yield across 659 validators. A flat, burned admission fee bears hardest on small validators relative to their revenue, which makes delegation size a closer question for operators near the margin.

Client diversity after Alpenglow: the Firedancer gap

The client requirement carries a second cost, measured in network resilience. Firedancer, the independent validator client built by Jump Crypto, and Frankendancer, its hybrid predecessor, could not carry out the TowerBFT to Alpenglow migration, so operators running either had to move to an Agave-based client to keep voting. Jump’s team had already said it would end Frankendancer support once Alpenglow went live, citing maintenance and security overhead.

The exposure was material. Estimates of the stake running Firedancer-family clients a week before the switch ranged from about 13% of active stake, in a 15 October count by Furlpay, to roughly 15.8% among the 500 largest validators in Solana Compass data from 13 October, and those operators had to move to Agave-based software before activation. The genesis certificate needed 82% of stake, according to Solana Compass, so readiness among those operators bore directly on whether the handoff could proceed on schedule.

A return path exists. Firedancer’s v26.10.0 release on 7 October added Alpenglow support and enabled it in the default testnet and devnet configurations, while stating that migration from Tower would not be supported and labeling the build a testnet release unsuited to mainnet. Galaxy has written that the release lets operators go back to Firedancer after the transition.

Until a mainnet Firedancer build supporting Votor ships and operators adopt it, Solana’s consensus runs on clients that share one codebase. A bug in that codebase would reach every voting validator at once, which is the scenario an independent client exists to prevent. The timing of Firedancer’s mainnet return is therefore one of the more important open items for network resilience in the coming months.

SOL price and ETF flows around the activation

Markets treated the switch as a known, scheduled event. SOL traded near $109 on 21 October and fell about 5.2% to around $103 the following day, according to 24/7 Wall St., and it stood at $100.65 on 27 October, according to Investing.com data reported by ad-hoc-news. The token had begun October near $121.

Fund flows moved in the same direction. Spot Solana ETFs listed in the United States recorded outflows in every session from 5 October through 19 October, with the largest single exit of $12.7 million on 16 October, before a modest inflow of about $585,000 on activation day. Cumulative net flows since launch remained positive at roughly $1.54 billion in Farside Investors’ data.

A consensus upgrade changes how fast transactions settle and leaves the token’s supply schedule and fee formula as they were, aside from the SOL that the admission ticket burns. Price moves in the days around activation therefore say more about positioning and macro conditions than about the protocol, and any lasting effect would have to arrive through usage that faster finality enables.

The future of finance is here. Trade crypto and more

What Alpenglow has not delivered yet

The upgrade that went live is the first of two planned phases, and several related changes remain on the roadmap. Rotor, the second phase, would replace Turbine, the system that spreads a block’s data across the network, with a single relay layer designed to cut propagation latency. The Foundation describes it as planned for a later release, and it has no scheduled date.

Other items sit closer. Fast leader handoff, which lets a leader start building optimistically on a parent it expects to be notarized, arrives in Agave 4.4, and an Agave 4.4 schedule published in September targeted 9 November for mainnet feature activation. The confirmed commitment level is due for removal in a later release, so applications still reading it have a finite window to migrate.

Anza has also outlined geographically aware leader rotation, intended to reduce delays between consecutive block producers, and a research design called Quantumglow that would replace Alpenglow’s elliptic-curve signatures with hash-based ones to address post-quantum security. Neither has a release date. Separately, Jump’s Firedancer team has proposed, under SIMD-0370, removing Solana’s 60 million compute-unit block limit once Alpenglow was live, and Agave 4.5, planned for December 2026, would raise the number of accounts a versioned transaction can reference from 64 to 96.

Those open items set the watch list for the next quarter. Independent finality data under heavy load, exchange crediting policies that reflect the new finality, a mainnet Firedancer build with Votor support, and a date for Rotor will show how much of Alpenglow’s design reaches users in practice.