Solana Votor: Votes Left the Transaction Stream
Consensus moved. Execution did not.
On October 21, 2026, Solana activated Alpenglow’s first phase, Votor. The feature activated at the start of epoch 1064, but the actual consensus handoff occurred at slot 459,653,000: the last TowerBFT block was 459,652,999, and the first produced Votor block was 459,653,008 at 13:54:03 UTC.[1]
Votor did not eliminate validator voting. It changed how votes travel and how they are represented. Under TowerBFT, validators submitted normal Vote Program transactions. Under Votor, validators send signed votes directly to one another and aggregate them into BLS quorum certificates. Routine consensus votes therefore no longer occupy transaction entries inside blocks.[1][6]
The accurate summary is:
Consensus votes are no longer ordinary ledger transactions. Validators still vote, and certificates derived from those votes determine which blocks become final.
The short version
Our equal 24-hour indexer windows found:
Most of the transaction-count break is mechanical. In 25 sampled blocks on each side, legacy vote transactions averaged 742 per block before Votor and 0 after it. This is not evidence that user throughput fell by 60%.
What is Votor?
Alpenglow replaces TowerBFT as Solana’s consensus protocol. Its first phase, Votor, handles voting and finalization. Rotor, the planned replacement for Turbine’s block-distribution system, is not part of this first deployment.[1][6]
Votor runs two finalization routes concurrently:
- an 80%-stake fast path that can finalize after one voting round;
- a two-round path using 60%-stake thresholds.
Whichever route completes first wins. The target is approximately 150ms finality, rather than TowerBFT’s roughly 12.8-second process. This is finality latency, not block time.[1][10]
Transaction execution did not move off-chain. The SVM, transaction format, programs, state changes, failed transactions, and fee mechanics continue to operate normally.
The exact activation boundary
There were two distinct moments:
Feature activation
slot 459,648,000
2026–10–21 13:36:05 UTC
Last TowerBFT / Alpenglow genesis block
slot 459,652,999
2026–10–21 13:54:00 UTC
Votor begins
slot 459,653,000
First produced Votor block
slot 459,653,008
2026–10–21 13:54:03 UTC
Slots 459,653,000–459,653,007 were skipped. The first produced Votor block points directly to the certified TowerBFT genesis block.
Our primary census uses equal 24-hour UTC windows around the first indexed Votor block, rather than equal slot ranges. This avoids bias from changes in slot duration and produced-block count.
Transaction count: a structural break, not a user exodus
The indexer recorded 441.6 million transactions in the 24 hours before the switch and 178.4 million afterward.
The sampled block decomposition makes the cause visible:
The disappearance of routine vote transactions is causally attributable to Votor. The simultaneous change in non-vote transactions is not. It may reflect user demand, bots, application activity, congestion, leaders, schedulers, or time-of-day effects.
Any TPS dashboard that historically included votes must therefore be re-baselined at slot 459,653,000.
Block compute units
The RPC sample measured actual meta.computeUnitsConsumed, not requested CU limits:
Votes represented more than half of recorded transactions but only a small portion of consumed compute. They were numerous and comparatively cheap.
Votor unquestionably removes their on-chain CU usage, signature verification, transaction entries, and associated bandwidth. It does not follow that all freed resources are immediately filled by user transactions. Solana blocks may instead be constrained by account locks, data size, scheduler behavior, network limits, or user demand.
The decline in sampled non-vote CU is correlational, not a measured causal effect of Votor.
Fees and validator revenue
Solana transaction fees contain:
- a base fee charged per required signature;
- an optional priority fee derived from the transaction’s compute-budget configuration.[2]
The base fee in this window was 5,000 lamports per signature.[2] Under TowerBFT, routine vote transactions paid signature fees. Once those votes left the ledger, that recurring stream disappeared.
In the RPC sample:
The means are sensitive to fee spikes, so the corresponding median priority fees are also useful: 9.57M lamports before versus 7.94M after.
The complete indexer census measures the block’s leader Fee reward, not gross transaction fees. Median leader reward moved from 0.00851 SOL to 0.00676 SOL per block; total 24-hour leader rewards moved from 6,453.55 SOL to 5,600.17 SOL.
Priority-fee movement cannot be assigned to Votor from this event window. Priority fees respond to user demand, account contention, requested CU limits, bidding behavior, and scheduler conditions. Votor did not change the fee formula.[1][2]
Validators no longer pay one transaction fee for every consensus vote. Instead, admitted validators pay the current 0.8 SOL Validator Admission Ticket per epoch from their vote account.[3] Older draft material mentioning 1.6 SOL per epoch is not the live value.
What can be concluded?
The clean effects are structural:
- Routine vote transactions fell to zero after the boundary.
- Recorded transaction count fell sharply because those votes disappeared.
- Vote signature fees and vote CU consumption disappeared from blocks.
- Leader fee revenue fell over this particular comparison window.
- Non-vote load and priority fees remained demand-driven; their changes are not causally identified by a before/after chart.
- Validator voting continues through direct messages and aggregate certificates.
Appendix A: How the migration was made safe
A controlled handoff
SIMD-0384 specified a migration boundary 5,000 slots after feature activation. During the transition, validators restricted TowerBFT blocks so ordinary user transactions could not enter the rollback region. They then waited for a strongly confirmed final TowerBFT ancestor and voted on it as the Alpenglow genesis block.[7]
Get Onchain Divers’s stories in your inbox
Join Medium for free to get updates from this writer.
Because transitional blocks carried no new user transactions, incompatible descendants could be discarded without rolling back newly accepted user activity.
The 82% genesis certificate
Validators switched only after receiving a BLS genesis certificate representing at least 82% of stake. The migration argument assumes at most 19% malicious stake: two contradictory certificates above 82% could not both be formed without honest validators signing conflicting genesis blocks.[7]
The certificate was rebroadcast and embedded in initial Alpenglow metadata. A validator starting from a snapshot could verify the migration-success state, while a lagging validator could recover after observing a valid finalization certificate.
Prerequisites and rehearsals
Before the switch:
- BLS public-key registration activated on mainnet;
- registrations required proof of possession bound to the vote account, protecting aggregate signatures from rogue-key attacks;
- validators without an eligible BLS key were excluded from consensus;
- the migration was rehearsed on a community cluster, testnet, and devnet;
- the initial migration required a compatible Agave-based client.[1][3][8]
Security model
Alpenglow uses a “20+20” model. Its core safety assumption is strictly less than 20% Byzantine stake; the additional offline tolerance applies under the protocol’s stronger network conditions. This differs from conventional one-third-BFT assumptions.[6][10]
The white paper supplies safety and liveness arguments, but we found no separately published machine-checked proof or named external audit report.
Appendix B: Can the votes still be explored?
Historical votes
Yes. Before slot 459,653,000, routine votes remain ordinary historical transactions involving:
Vote111111111111111111111111111111111111111They can be inspected using an archival getBlock, Solana Explorer, Solscan, or a transaction indexer.[5]
Post-Votor individual votes
Not through ordinary transaction history. Individual votes now:
- travel directly between validators;
- live in validator consensus data structures;
- do not receive transaction signatures;
- do not appear in getTransaction or explorer transaction counts.
Vote accounts still exist on-chain. Administrative changes, withdrawals, commission changes, and BLS-key registration can still produce Vote Program transactions. These are not routine per-slot consensus votes.
Certificates and footers
Agave’s Geyser interface provides an opt-in block-footer callback. A footer may expose a finalization certificate and reward-related certificates, together with the bank hash and producer metadata.[1]
Certificate fields are optional, and a footer normally carries the latest certificate the leader knew while constructing the block — not a certificate finalizing the same block. Standard JSON-RPC does not expose every Votor vote, and a full certificate feed currently requires validator or Geyser-level instrumentation.
The activation itself can be checked using the Alpenglow feature account, while compatible nodes expose the certified migration genesis through getAgGenesisCert.
Methodology and limitations
- Indexer census: every produced block in equal 24-hour UTC windows around the first indexed Votor block.
- Event chart: hourly aggregates from the same Solana block indexer.
- RPC decomposition: 25 evenly spaced blocks on each side, approximately one every 30 minutes.
- Vote classification: presence of the native Vote Program in static transaction account keys.
- Priority-fee estimate: meta.fee − 5,000 × required signatures, floored at zero.
- CU metric: actual meta.computeUnitsConsumed; requested limits were not measured.
- “Non-vote” includes user transactions and non-vote system transactions.
- This is an event study, not a causal experiment.
Sources
[1] Alpenglow | Solana — https://solana.com/upgrades/alpenglow
[2] Fees | Solana — https://solana.com/docs/core/fees
[3] BLS Pubkey and the Validator Admission Ticket | Solana — https://solana.com/upgrades/bls-pubkey-vat
[5] getBlock RPC | Solana — https://solana.com/docs/rpc/http/getblock
[6] SIMD-0326: Alpenglow — https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md
[7] SIMD-0384: Alpenglow migration — https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0384-alpenglow-migration.md
[8] SIMD-0387: BLS pubkey management — https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0387-bls-pubkey-management-in-vote-account.md
[10] Solana Alpenglow Consensus White Paper v1.1 — https://www.anza.xyz/alpenglow-1-1
OnChain Divers provides decoded Solana data: launch, swap and migration data for researchers building lifecycle-aware market models. Subscribe for schema updates, reproducible SQL and delayed research examples.
Connect with us:
- Website: onchaindivers.com
- Twitter: @onchain_divers
- Discord: Join our community
