Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Transactions per second (TPS) measures blockchain throughput: the number of transactions a network completes during one second under a stated counting rule and test condition. It is useful for describing capacity and activity, but it is not the same as transaction speed, confirmation time, finality, fees, security, or decentralization.
TPS is a throughput rate, not a complete definition of “speed”
At its simplest, TPS is calculated as:
TPS = transactions counted ÷ elapsed seconds
The calculation looks straightforward, but the result depends on what “transactions counted” means. A serious performance claim must say whether it counts submitted attempts, transactions accepted by nodes, valid transactions, transactions included in blocks, transactions committed by the network, or transactions that have reached finality.
ITU-T Recommendation F.751.1 (2020) identifies TPS as a standard performance indicator and defines it in terms of processed transaction count over processing time. The recommendation also says that the test topology and environment should be reported. Hyperledger’s performance-metrics guidance gives a more specific operational definition: transaction throughput is the rate at which valid transactions are committed by the blockchain system during a defined period, at a stated network size. Its method says invalid transactions should be subtracted.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThose qualifications are essential. Counting every request sent to a node can make a busy or failing system look productive even when many requests are rejected. Counting only valid, committed transactions gives a more useful view of work the blockchain actually completed.
#1 Best Overall
How to calculate and report TPS correctly
1. Define the transaction unit
A transaction is not a uniform unit of work. A basic payment may change only a few balances, while a smart-contract or program call can read and update substantial state, consume more execution resources, and trigger additional operations. Comparing one transaction from each workload as if they required equal effort can mislead.
For that reason, a report should identify the transaction mix. State whether the workload contains simple transfers, contract calls, batches, failed calls, or another defined operation. If several transaction classes are mixed, give their proportions rather than presenting one unexplained number.
2. State the validity and commitment rule
Specify whether the numerator includes failed, invalid, dropped, reverted, merely submitted, included, committed, or finalized transactions. For a network-throughput measurement, valid transactions committed by the system are generally the most meaningful baseline. A failed execution can consume resources, but it should not silently be counted as a successful state change if the stated metric is valid committed throughput.
Recommended Free Tools
3. Set the measurement interval
Divide the count by the exact elapsed interval. A five-second burst, a one-minute average, and a 24-hour live average answer different questions. Short windows can capture peaks; longer windows reveal sustained behavior and periods in which demand or node conditions changed.
4. Describe the system and test conditions
For a controlled benchmark, document the software version, hardware, node count, geographic distribution, network topology, consensus configuration, transaction workload, offered load, and whether the test was run on a private or public network. ITU-T and Hyperledger both emphasize reporting the environment because changing these variables can change the result.
Worked example
Suppose a test commits 18,000 valid transactions during a 30-second interval. Its throughput is 18,000 ÷ 30 = 600 TPS. If 2,000 additional requests were invalid and rejected, they do not belong in a valid-committed TPS numerator. If the same 18,000 transactions took 60 seconds under a heavier workload, the result would be 300 TPS even though the transaction count is unchanged.
TPS versus latency, confirmation, and finality
TPS answers, “How many transactions can this system complete per second under this definition?” It does not answer, “How long will my transaction take?” That second question concerns latency.
Latency
Transaction latency is the elapsed time from submission until the transaction’s effect is usable across the network at a specified confirmation threshold. Hyperledger’s definition includes propagation and the settling of consensus. A network can sustain high throughput while an individual transaction waits in a queue, waits for a block, or waits for a required confirmation level.
Confirmation
Confirmation indicates that a transaction has been included or otherwise acknowledged at a chosen stage of the protocol. The exact meaning differs by blockchain. Solana documentation treats confirmation and finality as separate concepts, so a transaction described as “confirmed” is not automatically equivalent to one that is final.
Finality
Finality is the protocol’s stronger assurance that a result will not be reversed under its stated assumptions. Ethereum’s transaction lifecycle illustrates the distinction: a broadcast transaction waits for a validator to include it in a block, and the containing block can later become justified and finalized. Inclusion, confirmation, and finality therefore represent different points in the lifecycle.
When evaluating a blockchain for payments, trading, gaming, or another interactive application, record TPS together with a latency percentile and the finality condition. A peak throughput number with no time-to-confirm information cannot tell a user whether an action feels instantaneous or whether settlement is suitably irreversible.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Why blockchain TPS numbers differ
Transaction workload and resource use
Blockchains usually meter execution resources. On Ethereum, transactions that change state consume gas, and blocks are bounded by a gas limit. A block can therefore contain many low-resource transfers or far fewer expensive contract calls. The resulting TPS changes with the workload even when the block interval is unchanged.
Rank #3
Block capacity and timing
Throughput is constrained by how much work fits in each block and how often blocks are produced. Ethereum documentation says blocks are normally created and committed once every 12 seconds; that is a block interval, not a TPS figure. The number of transactions per block still depends on each transaction’s gas use, and the observed rate can differ from the theoretical capacity.
Counting rules
One report may count all submitted attempts, another only valid transactions, and another only transactions regarded as final. Failed or invalid operations can inflate a submitted-request figure while adding no successful state transition. Always put the counting rule beside the number.
Measurement window and demand
Live traffic is variable. A network under light demand may show a low observed average despite having unused capacity. A brief stress test may show a high rate that cannot be sustained. “Observed TPS,” “average TPS,” “peak TPS,” and “maximum under test” should not be treated as interchangeable labels.
Hardware, topology, and network size
Validator or node hardware, storage, bandwidth, geographic distance, message propagation, software implementation, and the number of participating nodes all affect performance. A private test network with favorable connectivity is not automatically representative of a public network spread across regions.
Layer boundary
A base-layer TPS figure and an ecosystem total that adds one or more layer-2 systems count different work. Ethereum.org describes rollups as a primary scaling approach and distinguishes on-chain from off-chain scaling. A comparison must state whether it measures a single base layer, a particular layer 2, or an aggregate across layers; otherwise the numbers are not equivalent.
Does higher TPS mean a blockchain is faster?
Not necessarily. Higher throughput means the system can complete more transactions per unit of time under the stated conditions. It does not guarantee that any one transaction is included sooner or reaches finality sooner.
Rank #4
Consider two hypothetical systems:
| System | Throughput | Individual-transaction outcome |
|---|---|---|
| A | 1,000 TPS during a controlled test | A transaction may wait in a queue before inclusion |
| B | 400 TPS under its normal public workload | A transaction may reach the required confirmation threshold sooner |
This example is illustrative, not a benchmark. It shows why throughput and latency must be measured separately. Queue depth, block timing, propagation, and the confirmation rule can matter more to a particular user than a maximum TPS headline.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteTPS also says nothing by itself about transaction fees, validator diversity, resistance to attacks, availability, or the consequences of a failure. Those are separate performance, security, and operational questions.
How to compare TPS claims from different networks
Before putting two numbers in the same table, verify all of the following:
- What kind of number is it? Identify an observed live average, a peak observation, a controlled benchmark, or a theoretical maximum.
- What workload was used? Compare equivalent transaction types and resource demands.
- Which transactions count? Check whether failed or invalid transactions are excluded and whether the endpoint is inclusion, commitment, or finality.
- What interval was measured? Note the start and end times, duration, and whether demand was steady.
- What layer is included? Do not compare a base layer with a multi-layer aggregate without labeling the boundary.
- What environment produced the result? Record hardware, node count, topology, geography, software, and consensus settings for tests.
- What is the latency and finality profile? Pair throughput with the time to the confirmation state the application needs.
- What trade-offs apply? Assess security and decentralization rather than treating TPS as a quality ranking.
If a source does not disclose these conditions, label the figure as incomplete rather than presenting it as a directly comparable fact. The reviewed primary guidance does not provide a current, like-for-like cross-chain benchmark, so a ranking based only on headline TPS would be misleading.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What a useful blockchain performance report should contain
A reproducible report can use a compact disclosure block such as:
- Metric: valid transactions committed per second.
- Workload: transaction types, resource limits, and proportions.
- Validity rule: treatment of rejected, failed, and reverted operations.
- Interval: exact duration and whether the figure is an average or peak.
- Scope: base layer, layer 2, or explicitly defined aggregate.
- Environment: network size, node locations, hardware, software, and topology.
- Confirmation target: inclusion, a stated confirmation level, commitment, or finality.
- Latency: time distribution, not just a single average where possible.
This format prevents a number from being detached from the conditions that give it meaning. It also lets readers reproduce the calculation and decide whether the test resembles their intended workload.
Common TPS mistakes and how to avoid them
Calling a block interval a TPS result
A 12-second block interval describes how often blocks are produced in the cited Ethereum documentation. It becomes a throughput figure only after you know how many qualifying transactions fit in those blocks.
Using a theoretical ceiling as normal performance
A capacity estimate under ideal assumptions is not the same as sustained public-network throughput. Label the two separately and provide the assumptions behind the ceiling.
Counting requests instead of completed work
Submitted attempts, retries, and invalid transactions can exceed committed state changes. Use a validity and commitment rule, and subtract invalid transactions when reporting valid throughput.
Equating confirmation with finality
State the exact threshold used. A transaction may be included or confirmed before the protocol considers its result finalized.
Comparing unlike layers or workloads
Keep base-layer, layer-2, and aggregate figures in separate rows unless the scope is explicitly normalized. Likewise, do not compare simple transfers with complex contract calls without describing their resource use.
Choosing the right metric for a real application
Start with the application’s required outcome rather than a headline number:
- Define the action. Identify the transaction type and expected workload mix.
- Set the user deadline. Decide how quickly inclusion and the required confirmation state must occur.
- Set the settlement requirement. Determine whether ordinary confirmation is sufficient or finality is required.
- Estimate sustained demand. Use expected average and peak rates, including retries and bursts.
- Check resource limits. Confirm that the transaction’s gas or equivalent execution demand fits the network’s block or batch constraints.
- Evaluate non-throughput properties. Include fees, availability, security assumptions, and decentralization relevant to the use case.
TPS is most valuable as one column in that analysis. It tells you about volume over time; latency and finality tell you about when a particular result becomes usable and how strongly it is settled.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
