TPS is a count of a defined transaction population divided by elapsed seconds. It can include different filters and execution outcomes depending on the source. Transactions, instructions, user actions and submitted attempts are different units, and current Votor votes no longer contribute vote transactions to blocks.
Count transactions rather than whichever activity looks similar
A transaction contains one or more top-level instructions and can trigger nested program calls. A user action can need several transactions, while one transaction can perform several operations.
A swap may include account setup, a routed trade and cleanup. Counting every instruction as a separate transaction inflates the transaction count by changing the unit.
Submitted attempts are another population. A sender can rebroadcast the same signed transaction many times, while only one accepted transaction identity represents that attempt onchain.
Define whether your chart counts recorded transactions, successful executions or a program-specific business event. Keep that definition with the unit label.
Calculate a rate from an actual sample interval
Choose a teaching sample with 18,000 recorded transactions over 60 seconds. Its rate is 300 TPS. If 15,000 completed successfully under the chosen execution filter, successful-execution TPS is 250.
Neither number establishes how many people acted or how many purchases completed. Those questions require a different decoder and business definition.
getRecentPerformanceSamples returns recorded counts and samplePeriodSecs under its RPC contract. Use the returned duration in the calculation. The method also exposes a nullable non-vote count.
If a field is null or unavailable, preserve that state. Do not substitute zero or infer a value from a different field without a documented rule.
Combine intervals using counts and elapsed time
Choose a ten-second sample with 1,000 transactions and a fifty-second sample with 10,000. Their separate rates are 100 and 200 TPS.
The combined rate is 11,000 divided by 60, or about 183.33 TPS. Averaging 100 and 200 gives 150, which incorrectly gives the short sample the same weight as the long one.
For continuous observations, sum comparable counts and their covered duration. Check for overlap so the same interval does not enter twice.
If there are gaps, report covered time or apply a stated handling method. An unexplained denominator can make a partial dataset look like a complete period.
Weight rate samples by covered seconds
Mark the vote-transaction break after Alpenglow
Under the former consensus model, transaction totals could include validator vote transactions. Current Votor sends votes outside blocks, so those vote transactions leave the recorded block population.
That is a methodological break for an all-transactions historical chart. A drop in its total can reflect the removed category rather than a drop in user application activity.
Separate historical categories where the source supports them and mark activation on the chart. Do not subtract an old constant vote rate from all later observations.
Non-vote is still not a universal synonym for human economic use. It can include automation, failed executions and other activities within the source's counted population.
Observed throughput is not maximum capacity or latency
A measured window reports what the source observed during that interval. It does not by itself establish a network's theoretical maximum throughput.
A load test needs its workload, transaction complexity, account contention, hardware or service conditions and success criteria. A simple independent transfer workload differs from a shared-state DeFi workload.
TPS also does not state how long one transaction took from wallet action to application completion. Submission, execution, finality and RPC observation have separate timing.
Use the latency guide for that end-to-end measurement.
Read a published TPS claim with its method
Find the source, cluster, period, counted population, execution filter and aggregation. Check whether the number is a peak, average, median or theoretical target.
For post-migration data, confirm compatible block and bank handling. A stream with tentative candidates needs an accepted-branch counting policy.
If the source does not disclose enough to compare it, report that uncertainty. A precise decimal on a card cannot replace a defined metric.
Common questions
Is one instruction one transaction?
No. One transaction can contain several instructions and nested calls.
Is non-vote TPS the same as real users per second?
No. It remains a transaction-category rate, not a person or economic-value count.
Does 300 TPS mean a transaction takes 1/300 second?
No. Throughput and individual latency measure different properties.
Sources and documentation
- getRecentPerformanceSamples
- Solana Foundation: Alpenglow status and migration
- Solana transactions
- Solana instructions
- Solana RPC overview
Found an error or an outdated detail? Send a correction.
