Key Takeaways Validator votes no longer count as Solana transactions Handover block: 649 vote transactions, then zero 844 of 1,701 first Alpenglow transactions failed Before-and-after TPS com
The Solana Foundation’s upgrade documentation calls the drop in transaction counts and transactions per second, or TPS, “an accounting change, not a throughput regression.” That still leaves a question for anyone reading a Solana chart: did activity fall, or only the count?
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 any tally of total transactions included them.
Alpenglow replaces that 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 vote traffic at the switch.
Coindoo queried 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 at 13:54:03, with no blocks produced in the eight slots between them.
Solana blocks either side of the October 21 consensus switch Block Consensus Total transactions Vote program Non-vote 459,652,999 TowerBFT (last) 1,051 649 402 459,653,008 Alpenglow (first) 1,701 0 1,701About three in five transactions in the last TowerBFT block were votes; one block later, there were none. The Alpenglow block was still the larger of the two, and a single pair of blocks cannot show whether network activity rose or fell. It shows the mechanism. Measuring a trend takes thousands of blocks.
Failures are the next 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.
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 accomplished, such as completed swaps or token transfers, gets closer to real use than any transaction total.
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 gives 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 has to come from samples stored earlier or from historical blocks.
Three filters, applied the same way before and after the switch
Vote transactions did more than add to 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 points 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 arrives 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.
The post Solana’s TPS Fell With Alpenglow – Votes Left the Count appeared first on Coindoo.
