\n
![](\"https:\/\/media.crypto.news\/2026\/06\/Solana1.webp\")
<\/p>\n
\n<\/p>\n
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.<\/p>\n
\n Summary<\/span>\n <\/p>\n <\/p>\n Yakovenko, in an Oct. 21 X post<\/a>, 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.<\/p>\n \u201cAlpenglow would have shipped in half the time if they just changed the vote program to the ag state machine\u201d<\/p>\n<\/blockquote>\n Anza\u2019s published design<\/a> describes a replacement for TowerBFT, the system validators have used to agree on blocks, with direct voting and compact certificates.<\/p>\n The mainnet migration has been scheduled for Oct. 21, as crypto.news previously reported while covering the planned consensus handoff<\/a>. Solana Foundation\u2019s updated guidance identifies epoch 1064 as the trigger and estimates its start at approximately 13:20 UTC.<\/p>\n Anza\u2019s 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.<\/p>\n <\/p>\n Solana Foundation\u2019s 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.<\/p>\n 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\u2019s gRPC footer message does not yet forward those certificates.<\/p>\n Developers had access to the changed behavior when Alpenglow reached devnet<\/a> 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.<\/p>\n Anza\u2019s 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.<\/p>\n Under the same documentation, the chain\u2019s 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.<\/p>\n Solana Foundation\u2019s 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.<\/p>\n 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\u2019s rent-exempt minimum, according to the same guidance.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2019s operator instructions.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Another alternative used a directed acyclic graph, with possible bandwidth savings. The proposal\u2019s authors listed latency and difficulty using bandwidth fully among its drawbacks.<\/p>\n 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.<\/p>\n\n\n
\n
Alpenglow removes votes from headline transaction counts<\/h2>\n
Validator fees move to a separate epoch charge<\/h2>\n
Two voting paths replace TowerBFT<\/h2>\n