Cabinet
Back to Technology Insights
2026.09.22

[Follow-up] Solana's Alpenglow Is Live on Testnet and Devnet, and "September 28" Was Never Its Mainnet Date: Prepare for Merged Commitment Levels and Vanishing Vote Transactions

[Follow-up] Solana's Alpenglow Is Live on Testnet and Devnet, and "September 28" Was Never Its Mainnet Date: Prepare for Merged Commitment Levels and Vanishing Vote Transactions

What happened

On September 22, Anza announced that Alpenglow activation was starting on testnet. The day before, Triton One's guide for data consumers had identified the feature gate as SIMD-0326, activating at epoch 1042.

The migration ran as a 5,000-slot countdown, about 17 minutes. Anza reported that at 18:12 UTC on September 24, validators with 82% of stake confirmed a final TowerBFT block, and the Alpenglow genesis block formed at slot 444625255. On devnet, the gate flipped at epoch 1167 on September 25, and the handoff at slot 504148999 was confirmed at 20:01 UTC. That is roughly 26 hours after testnet.

Anza said only: "Devnet is next. Mainnet-beta after our observation period." Meanwhile, the Agave v4.3 release schedule published on August 12 listed September 28 for mainnet-beta "Resume feature activation." That date was widely read as Alpenglow's mainnet date, including in this series' September 4 article. It appears instead to be the date for resuming work through queued feature gates, and the schedule never names Alpenglow. The v4.4 schedule published on September 22 lists mainnet-beta feature activations resuming on November 9, and it does not mention Alpenglow either.

Only Agave 4.3 took part in the testnet handoff. Anza stated that Firedancer and Frankendancer do not support the Alpenglow migration, and told testnet nodes running them to switch to Agave v4.3.0.

What changes: votes leave blocks

Why this design? Finality time is only part of the answer. According to Solana Compass, Votor combines a one-round fast path at 80% of stake with a two-round path at 60%. Co-founder Anatoly Yakovenko has said the network can survive "to 40% down." Under TowerBFT, finality stops once more than a third of stake is offline. On August 12, a routing failure at hosting provider Teraswitch pushed 28.83% of stake offline, 4.5 points short of that threshold. Widening tolerance to infrastructure concentration looks like one of Alpenglow's design goals.

Phase one replaces TowerBFT with Votor. Under TowerBFT, validators write votes into blocks as transactions, and finality accrues as votes stack up across 32 slots. Under Votor, validators exchange votes directly, aggregate them into certificates, and finalize in one or two rounds. The Solana Foundation's migration guide targets finality of roughly 150 milliseconds, down from about 12.8 seconds.

The execution layer is essentially untouched. The guide states that "Alpenglow changes consensus, not execution"; the SVM, transaction formats and fee mechanics do not change. What changes is everything that reads the chain around them.

First, commitment levels converge. In the guide's words, "confirmed and finalized become the same thing." New code should target finalized, and confirmed will be deprecated and removed in a later release.

Second, votes leave blocks. Solana Compass data shows votes making up 54% to 59% of daily mainnet transactions from September 18 to 24. On September 24 there were 217.1 million vote transactions against 168.8 million non-vote transactions, or about 56%. Once mainnet migrates, vote-inclusive TPS and transaction counts will fall by roughly half with no change in user activity.

Third, a slot can carry more than one candidate block. The guide tells streaming and Geyser consumers to key buffers on (slot, bank_id) instead of slot alone. Proof of History ticks leave the shred stream. The Clock timestamp is now set directly by the leader within a bounded range, replacing the stake-weighted median of votes. The getAgGenesisCert RPC, which returns null under TowerBFT, tells you which regime a cluster is running. Per Triton One, vote accounts now carry a BLS public key, readable via getAccountInfo with jsonParsed.

Pitfalls to watch

The biggest pitfall is dashboards and alert thresholds. Alerts built on vote-inclusive TPS or transaction counts will read the migration as a sudden halving and fire falsely. Organizations that report transaction counts as a business metric risk misreading the drop as falling usage. Devnet already uses the new accounting, so the definitions can be fixed and tested there first.

Next is logic that waits on confirmed. Two-stage designs, such as crediting deposits at confirmed and allowing withdrawals at finalized, lose their meaning when the two states become identical. The same code behaves differently before and after migration, so test it in both regimes.

Third is planning for operators on Firedancer-family clients. On testnet, switching to Agave was mandatory. Whether a Votor-capable Firedancer build is under development has not been announced. If mainnet imposes the same constraint, client diversity would take a temporary step backwards. The mainnet conditions, however, have not yet been stated.

Fourth is code that switches behavior by date. With no mainnet date set, any "after this timestamp, use the new mode" logic is guaranteed to be wrong. The migration happens through an epoch-boundary feature gate and a 5,000-slot countdown. As the guide suggests, detect the running regime from getAgGenesisCert (null under TowerBFT) and branch on that, so schedule changes cannot break you.

[Technical Insights & Actions]

  1. A date in a published release schedule is not a planning input until you have confirmed, in the original, which feature and which stage it refers to. Here a "resume feature activation" date was read across the industry as "Alpenglow mainnet day." [Product teams / Node operators] This week, reconcile the Solana dates in your internal migration plans against Anza's primary announcements, and record Alpenglow's mainnet date as "TBD, after the observation period."
  2. A consensus redesign can change the definition of your observability data even when execution is untouched. Vote-inclusive metrics depended on an implementation detail of the consensus protocol. [Integrators / Data platform teams] Before the mainnet migration, redefine TPS, transaction counts and alert thresholds on a non-vote basis, and validate old and new figures side by side on devnet.
  3. The implicit assumption "one slot, one block" no longer holds. Deduplication and buffers keyed on slot number will confuse candidate blocks. [Integrators] During the observation period, change Geyser and gRPC consumer keys to (slot, bank_id), standardize commitment on finalized, and run regression tests on devnet.

[Sources]

This article is a technical commentary based on publicly available information and is not investment advice.

Previous ArticleA "Block Validation Flaw" on Meter Mints Unbacked MTR and MTRG That Leak to BNB Chain via Passport: A Bridge Can Be No Safer Than the Source Chain's ValidationNext Article Avalanche Helicon Goes Live on Mainnet: C-Chain Acceptance and Execution Are Now Decoupled, and `latest` No Longer Means Final