Solana’s Yakovenko questions Alpenglow build as vote transactions exit

Solana co-founder Anatoly Yakovenko has said Alpenglow could have shipped in half the time through a simpler vote-program change, ahead of the Oct. 21 consensus migration that will remove validator vote transactions from blocks.

Summary

• Yakovenko said a simpler vote-program change could have halved Alpenglow's development time.
• Removing validator vote transactions will lower headline TPS counts without necessarily changing user activity.
• A burned 0.8 SOL admission fee per epoch will replace individual voting fees.
• Some RPC nodes may receive finality updates later than Alpenglow's 150-millisecond target.

Yakovenko, in an Oct. 21 X post, made the remark while quoting a comment celebrating the planned removal of on-chain votes and mocking the recurring criticism that most Solana transactions per second consist of validator votes.

"Alpenglow would have shipped in half the time if they just changed the vote program to the ag state machine"

Anza's published design describes a replacement for TowerBFT, the system validators have used to agree on blocks, with direct voting and compact certificates.

The mainnet migration has been scheduled for Oct. 21, as crypto.news previously reported while covering the planned consensus handoff. Solana Foundation's updated guidance identifies epoch 1064 as the trigger and estimates its start at approximately 13:20 UTC.

Anza's migration page separates feature activation from the consensus handoff. The migration boundary comes 5,000 slots later, when blocks temporarily carry only votes while validators complete the transition.

Alpenglow removes votes from headline transaction counts

Solana Foundation's migration guidance tells explorers and analytics services to reset transaction-count and TPS baselines because vote transactions will disappear from blocks. A total that includes votes will fall even if payments, trades, and other non-vote transactions remain unchanged.

The Foundation says services tracking validator participation must replace their reading of Vote program instructions with certificate data in block footers. Its guidance notes that Yellowstone's gRPC footer message does not yet forward those certificates.

Developers had access to the changed behavior when Alpenglow reached devnet in September, after the testnet transition. The Sep. 26 coverage described how explorers must keep competing candidate blocks separate until confirmation, retaining the selected block instead of combining their transactions.

Anza's operator documentation explains how plugins obtain the replacement metadata. Agave 4.3 provides an optional block-footer notification, which services must enable and implement if they need footer data. Those notifications retain their ordering relative to entry notifications.

Under the same documentation, the chain's clock keeps its existing format and whole-second precision. During transaction execution, its timestamp estimates when the parent block ended, and operators are told to keep treating that value as approximate.

Validator fees move to a separate epoch charge

Solana Foundation's fee documentation says removing on-chain votes ends fees paid on individual vote transactions. Validators instead pay a flat 0.8 SOL admission charge per epoch, with the entire amount burned.

The money comes from the vote account, replacing the identity account as the source of voting-related payments. Operators must hold the charge above the account's rent-exempt minimum, according to the same guidance.

Payment is made one epoch ahead. The first charge at the start of epoch 1064 covers participation in epoch 1065, and a validator that cannot pay loses permission to vote or produce blocks in the following epoch.

The Foundation says BLS public-key registration became available on mainnet July 8, while the admission feature activated July 22. Those preparatory changes did not themselves activate Alpenglow consensus.

Before the migration, its checklist requires version 4.3.2 of Agave, Jito-Solana, or Harmonic Salsa. Firedancer and Frankendancer are not supported during the handoff, according to the Foundation's operator instructions.

Two voting paths replace TowerBFT

Anza describes Votor as running two voting paths at the same time. One finalizes a block in a single round with responses from 80% of stake, while the second uses two rounds and 60% thresholds.

Votes become direct messages signed with BLS cryptography, allowing multiple signatures to be combined into a compact certificate. Anza says validators use their own timers to identify an unresponsive leader and vote to skip it.

The published SIMD-0326 proposal documents alternatives considered during development. A design without single-round finality offered simpler operation and 33% Byzantine fault tolerance, but its authors listed worse latency and lower crash resilience among the disadvantages.

Another alternative used a directed acyclic graph, with possible bandwidth savings. The proposal's authors listed latency and difficulty using bandwidth fully among its drawbacks.

The proposal caps the admitted set at 2,000 validators, prioritizing the highest-staked operators. Its authors explain that the limit helps keep certificates small enough for a single UDP message, while participation records support rewards for validators that actively vote.

Governance approval preceded implementation. In September 2025, the Alpenglow proposal passed with 98.27% support among votes cast, while participating stake represented 52% of the total, according to the completed ballot's published figures.

RPC delivery can lag behind consensus finality

Anza's operator documentation qualifies the roughly 150-millisecond finality target by explaining that nodes outside the admitted validator set may receive the result later.

Through the default path, those nodes learn finality from certificates included in a subsequent block. Anza says that can add up to one produced-block interval, with longer waits when blocks are skipped or delayed.

An admitted validator can send consensus messages directly to a partner node, leaving network latency between the partners as the main added delay. If every configured partner becomes unreachable, the recipient falls back to learning finality from later block footers.