Solana's Alpenglow upgrade will shrink its activity numbers by design

Solana's transaction counts are about to drop sharply, and the drop will not mean people stopped using the network. Alpenglow, a consensus upgrade scheduled to switch on in Solana's epoch 1064 on Oct. 21, takes validators' votes out of blocks, and those votes have been a large share of what the dashboards count.

The Solana Foundation's own video calls it "The Biggest Change to Solana's Core Protocol." Anyone who reads Solana's transaction totals or transactions per second as a sign of demand will need a new baseline from that day. The Solana Foundation says the count "drops sharply without any drop in real activity."

Scheduled, not yet live

As of 10:12 a.m. ET on Oct. 19, Alpenglow is scheduled but not active on Solana's main network. The Solana Foundation's upgrade page lists mainnet as "Not activated" and gives the expected start as epoch 1064, beginning "at approximately 13:20 UTC" on Wednesday, Oct. 21. That is about 9:20 a.m. ET.

An epoch is a fixed stretch of slots on Solana over which the validator set and its stakes stay the same. A validator is one of the computers that produce and confirm blocks.

The upgrade is already running on Solana's test networks. The Foundation's status table marks it "Active" on testnet and devnet, and says devnet switched on Sept. 25, 2026.

The design documents are still marked as under review. SIMD-0326, the main Alpenglow proposal on GitHub, and SIMD-0384, the migration plan written by engineers at Anza, both carry the status "Review." A SIMD is a Solana Improvement Document, the network's format for proposing protocol changes.

The software is out. Anza, the firm that maintains the Agave validator client, published Agave v4.3.0 on Sept. 18, 2026, and the Foundation says Alpenglow "ships in Agave 4.3."

How the counting changes

Today Solana runs a consensus system called TowerBFT. Under it, validators "vote by sending transactions," the Foundation says, and those vote transactions sit inside blocks next to users' payments and trades.

Alpenglow's first phase, called Votor, ends that. Validators "send votes directly to each other instead of as transactions, aggregate them into certificates, and finalize a block in one or two rounds," the Foundation's page says. A certificate here is a bundle of votes that proves enough validators agreed on a block.

Once votes leave blocks, any tally of transactions in a block loses them. The Foundation calls this "an accounting change, not a throughput regression." It warns that "benchmarking tools that have not been updated will report the change as a collapse in network activity."

The Foundation's page tells data providers: "Re-baseline transaction counts and TPS dashboards." Pipelines that already filter out the vote program "keep working," it says, because "they have nothing left to filter."

Rotor comes later

Alpenglow's second phase, Rotor, would change how a block's data spreads between validators. It would replace Turbine, the current system, with "a single relay layer."

Rotor is not part of the Oct. 21 change. The Foundation says it is planned "once Votor is adopted, and is not yet scheduled." SIMD-0326 says Solana will "initially" stay with Turbine and that Rotor "will get its own SIMD."

What users and builders see

For people sending transactions, the Foundation says little changes on the surface. "Execution is untouched: the SVM, transactions, programs, and fees stay the same," its page says.

The main visible gain is speed to finality, the point where a transaction can no longer be reversed. The Foundation says that takes "about 12.8 seconds" today and that Alpenglow "targets roughly 150 milliseconds." That figure is a design target, since Alpenglow has not yet run on mainnet.

Validators face firmer requirements. The Foundation says they must run a client built on Agave 4.3.0 and that "Firedancer and Frankendancer are not supported during the migration."

Data tools that track validators also have to change. Anything that measures which validators voted by reading vote instructions out of blocks needs a new source, the Foundation says, because participation "now lives in the block footer's certificates."

Apps that wait for finality get a simpler picture. Once Alpenglow is live, the "confirmed" and "finalized" levels that apps can wait on "become the same thing," the Foundation says. It tells builders not to switch code to "finalized" before then, because on TowerBFT it "still means a 12.8-second wait."

The switchover itself has a brief, unusual phase. The migration plan says that from a boundary slot set 5,000 slots after the feature activates, validators stop packing "anything other than simple vote transactions in blocks" until a so-called genesis certificate is formed. Data covering that window will look odd for a second reason.

What is not yet known

Whether activation happens on schedule is not yet known. The Foundation says "approximately" and its status table will show when the feature gate flips.

How large the drop will be is not known from any primary we have. The Foundation says only that vote traffic "has been a large share" of block transactions.

How long the migration window lasts is not set in the plan, which depends on reaching the vote thresholds it describes.

Whether major data providers will re-baseline their dashboards on day one, or show the cliff, is not known.

When Rotor ships, and whether it changes any other public metric, is not yet scheduled.

Sources

1. Solana Foundation, "Alpenglow," upgrade page, updated October 2026: https://solana.com/upgrades/alpenglow
2. SIMD-0326, "Alpenglow": https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md
3. SIMD-0384, "Alpenglow migration": https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0384-alpenglow-migration.md
4. Anza, Agave v4.3.0 release, Sept. 18, 2026: https://github.com/anza-xyz/agave/releases/tag/v4.3.0

Holding the Corner.

Not financial advice.