Solana's TPS Fell After Alpenglow as Validator Votes Left the Transaction Count
Key Takeaways
- •Solana activated the Alpenglow upgrade on October 21, replacing TowerBFT with the Votor protocol, under which validator votes are bundled into certificates in block footers rather than recorded as transactions.
- •Roughly three in five transactions, 649 in total, in the final TowerBFT block were validator votes, while the first Alpenglow block contained none yet was still the larger of the two.
- •The Solana Foundation characterizes the post-upgrade TPS drop as an accounting change rather than a throughput regression, but numbers published after October 21 are compiled on a different definition than all earlier figures.
- •In the first Alpenglow block, 844 of 1,701 transactions hit execution errors, so even vote-free tallies still include failed transactions that paid fees but completed no payment or trade.
- •Monitoring tools that tracked validator participation through Vote-program instructions must be rewired to read voting certificates from block footers, and any TPS chart spanning October 21 mixes the bookkeeping change with real changes in use.
Solana's transaction count and, with it, its headline transactions-per-second (TPS) figure dropped when the network activated Alpenglow on October 21. The Solana Foundation upgrade documentation calls the decline "an accounting change, not a throughput regression." That framing still leaves a question for anyone reading a Solana chart: did activity actually fall, or only the count? The answer reaches beyond a single upgrade day, because TPS is among the most quoted throughput figures in blockchain coverage, and Solana's post-October 21 tally is compiled on a different definition than every number published before it.
What Alpenglow Removed From the Transaction List
Under TowerBFT, the consensus system Solana ran until October 21, validators cast their votes as ordinary transactions. Blocks carried hundreds of them alongside payments, swaps and other application traffic, and every tally of total transactions included that vote traffic. Because those votes originated with validators rather than users, part of every pre-upgrade TPS figure reflected the network's consensus machinery rather than demand for its applications.
Alpenglow replaces the mechanism with Votor, a protocol in which validators exchange votes directly and bundle them into certificates. The certificates sit in each block's footer rather than its transaction list, so a counter that tallies transactions stops seeing votes from the moment of the switch.
What the Handover Blocks Show
Coindoo examined the blocks on either side of the switch through Solana's public mainnet RPC, the interface nodes expose for reading chain data, using its getBlock method. Each block occupies a slot, a window of roughly 400 milliseconds. TowerBFT ran for the first 5,000 slots of the epoch before Alpenglow replaced it.
The last TowerBFT block landed at 13:54:00 UTC on October 21, and the first Alpenglow block followed at 13:54:03, with no blocks produced in the eight slots between them. Roughly three in five transactions in the final TowerBFT block, 649 transactions in total, were validator votes; one block later, there were none. The Alpenglow block was nonetheless the larger of the two. A single pair of blocks cannot show whether network activity rose or fell; it shows the mechanism. Measuring a trend takes thousands of blocks.
Votes Are Not the Only Noise in the Count
Failures add a second layer. Reading the error field in each transaction's metadata, Coindoo found that 844 of the 1,701 transactions in the first Alpenglow block hit an execution error, leaving 857 that succeeded. A failed transaction is still charged a fee and still sits in the block, but it completed no payment or trade. The accounting-change framing covers only the vote layer, so even a vote-free tally needs an error-field filter before it describes work that actually completed.
Successful transactions do not map to people, either. One automated trading account can send transactions in large numbers, and a single transaction can contain several instructions. Counting what transactions actually accomplished, such as completed swaps or token transfers, gets closer to real use than any raw transaction total.
Where the Comparison Data Lives
Solana's getRecentPerformanceSamples method reports, for each sample, the total transaction count, the non-vote count and the sample length in seconds. Dividing a count by the length yields an average rate for that window.
The method returns at most 720 samples of about a minute each, roughly the last 12 hours. A query made more than half a day after the handover no longer reaches back to TowerBFT, so the pre-upgrade side of any comparison has to come from samples stored earlier or from historical blocks.
Three filters, applied identically before and after the switch, make the comparison meaningful:
- Remove validator votes. Alpenglow does this on the new side; the old side needs it done by hand.
- Remove failed transactions using each transaction's error field. The API's non-vote count still includes them.
- Compare equal time windows: one-minute averages against one-minute averages, never a dashboard peak against a daily total.
Tools That Read Votes Need Rewiring
Vote transactions did more than inflate TPS. Monitoring tools read Vote-program instructions from the transaction list to track which validators were participating. Under Alpenglow that input is gone, and the Foundation directs those tools to the voting certificates in block footers. A tracker still reading the old source would show validators going silent while they keep voting.
For Solana's usage figures, the useful number will arrive once several days of successful non-vote transactions can be set against stored pre-upgrade data covering the same hours. Until then, any headline TPS chart spanning October 21 mixes the bookkeeping change with real changes in use.
Source: Coindoo
