Further reading: Read the complete explanation of blockchain TPS, latency and finality.
Did you know? A blockchain can advertise thousands of transactions per second while a single customer’s transfer still takes longer than expected to settle. That is not necessarily a contradiction. The network may process many instructions in aggregate while one particular instruction waits in a queue, encounters a failing contract or requires a separate finality condition.
Imagine a fictional school science club operating a registration desk. Alicia sees that the desk can process 100 forms every minute. Kai Kai arrives during a busy lunch break and waits ten minutes before his form is handled. Tricia points out that the desk’s processing capacity is a statistic about the flow of forms, not a promise of how long every individual student waits.
Blockchain technology has similar performance measurements. Throughput, latency, inclusion, confirmation, finality, success rate and user-visible completion describe different properties. They can all matter when somebody needs a dependable payment, digital certificate or application response.
Quick answer: transactions per second (TPS) measures a transaction-processing rate over a defined interval, under a particular counting method. It does not alone establish the time from user submission to first inclusion, final settlement, economic success, withdrawal availability or real-world delivery. Two blockchain systems can report very different TPS numbers because they use different workloads, transaction sizes, test conditions or counting rules. A fair comparison needs the full transaction lifecycle and a reproducible benchmark.
This easy-to-read guide shows how blockchain technology works by following a school-club registration from submission to completed service. All numerical examples are fictional, not live chain rankings or speed claims. For the bigger picture, see What Is Blockchain? and the in-depth Blockchain Benchmarks: Follow the Cohort from Submission to Finality.
Choose Your Reading Route
- A busy registration desk teaches the difference
- What transactions per second actually measures
- Why 100 TPS does not mean ten-millisecond settlement
- Submission, inclusion and finality are three different moments
- Why average latency hides the slowest users
- Peak laboratory TPS is not sustained production TPS
- A native transfer is not the same work as a contract call
- Frequently asked questions
- Sources and what to read next
A busy registration desk teaches the difference
Suppose the school science club has two desks. Desk A can stamp 100 completed registration forms every minute under ordinary conditions. Desk B stamps only 30 forms per minute. Which one is faster for Alicia?
At first glance, Desk A sounds faster. But suppose 1,000 students are already waiting at Desk A and only five are waiting at Desk B. Alicia’s actual time to completion can be shorter at Desk B despite its smaller headline processing rate.
The desk example separates throughput from latency. Throughput describes how much work a system completes per unit time. Latency measures how long a particular request takes between specified stages.
A real blockchain adds consensus, transaction validation, network propagation and smart-contract execution. Those mechanisms create additional stages, but the same basic distinction remains. A network that processes a large total number of transactions does not guarantee instant processing for one customer.
The analogy has limits. A blockchain’s transaction accounting can include invalid requests, internal contract calls, bundled operations and different finality models that a school form desk does not reproduce. Nevertheless, it gives learners a clear starting question.
Before believing a speed claim, ask: is this number about how many transactions the system handles overall, or how long my own action takes to achieve the result I need?
What transactions per second actually measures
TPS is a rate: the number of relevant transactions divided by the duration of the measurement window. A simple illustrative calculation is 1,000 successfully committed transactions in ten seconds, which is 100 committed transactions per second.
But every word in that description matters. Were those transactions merely received, included in a recent block, confirmed by a certain number of nodes or finalised under the protocol? Were failed operations counted? Was the number an average over hours or a brief peak during one test?
The Hyperledger Blockchain Performance Metrics white paper defines throughput in terms of committed valid transactions over a time interval for a specified system under test. It also stresses the importance of stating the network size and test environment.
A marketing chart might count submission attempts as TPS, while an engineering report counts only successful committed operations. Those measurements can differ even when both use technically correct arithmetic. They answer different questions.
Imagine the school receives 200 application forms but rejects 50 because they lack mandatory information. Saying it received 200 applications is different from saying it successfully processed 200 valid registrations.
A useful speed statement therefore specifies the numerator, denominator, inclusion and success criteria. “100 TPS” by itself is not a complete description of a blockchain’s useful capacity.
Why 100 TPS does not mean ten-millisecond settlement
A beginner might see 100 TPS and imagine a single transaction must settle in one hundredth of a second. That is not how throughput works. A system can process 100 operations together in a batch every few seconds while an individual operation waits for a batch to begin.
Suppose our classroom registration desk accumulates 100 forms and stamps them together once per minute. Averaged across that minute, the throughput can be substantial, but a student who arrives just after the previous batch may wait almost a full minute before the next.
On a blockchain, block production intervals and transaction ordering can affect inclusion delay. A system may also provide an early receipt from a service before the chain reaches a stronger settlement state.
Latency should be measured from a specified start, such as when the user’s wallet submits a request, to a specified end, such as accepted inclusion or finality. Those endpoints are not interchangeable. A service that starts its stopwatch only when a request reaches a node can omit delays between the user and the node.
The relevant question is what the customer needs. A ticket application may require only a reliable reservation response. A major funds transfer may require stronger settlement evidence. Neither goal is expressed by TPS alone.
This is why professional performance reports include both throughput and response-time or transaction-latency measurements rather than inferring one from the other.
Submission, inclusion and finality are three different moments
Picture Alicia using a blockchain-based school ticketing application. She signs and submits a transaction at one time. A node may then accept it into a local pending pool. Later, a block contains the transaction. Later still, the block may meet the network’s appropriate finality or confirmation condition.
These are separate events. The waiting time from submission to first block inclusion can differ from the time to an agreed stronger settlement status. A high processing rate does not collapse those steps into one.
The meaning of finality depends on the network. Bitcoin uses cumulative proof-of-work confirmations for increasing settlement confidence, while proof-of-stake Ethereum has explicit checkpoint-based economic finality. Other blockchains can have other models.
The Ethereum Proof-of-Stake FAQ describes the difference between finality approaches. Its precise terms should not be substituted blindly for those used by a separate network.
A wallet might say “transaction confirmed” after observing a block even though a business application requires a more conservative settlement threshold. Both interfaces may use the English word confirmed while referring to different evidence stages.
Before comparing network A and network B, define the same starting point and the same meaningful ending point. Otherwise a shorter number can simply reflect a weaker or earlier stopping condition.
Why average latency hides the slowest users
Suppose a fictional chain processes ten registration requests. Nine complete in two seconds while one takes 42 seconds. The average completion time is six seconds, although one student endured a much longer wait.
The average is not false; it simply compresses a distribution into one number. If a service promises an acceptable experience for most users, it may need the median, 95th percentile or 99th percentile latency and an explanation of what happened to exceptionally slow requests.
A 95th percentile value describes a boundary for a specified portion of observed measurements. It is not the maximum and should not be presented as a universal deadline. Percentile comparisons also need similar workloads, observation windows and sample sizes.
The Hyperledger Caliper documentation recognises latency statistics alongside throughput and computing-resource consumption, and the Hyperledger performance metrics paper provides formal definitions of latency.
For a school registration site, the administrator should care about what happens during the lunchtime surge, not merely the quietest period. The same reasoning applies to blockchain applications under congestion.
A useful benchmark reports average and tail behaviour rather than choosing whichever single figure makes a system look fastest.
Peak laboratory TPS is not sustained production TPS
A blockchain might perform extremely well in a controlled test laboratory. Engineers may use powerful machines, a small number of geographically close nodes, simple transactions and a short measurement window. Those conditions can be valuable for testing a system’s technical limits.
A real public network can have more participants, longer communication paths, heavier smart-contract workloads, adversarial traffic and unpredictable demand. Its sustained useful throughput may be different from the brief peak reached in the laboratory.
The ITU-T F.751.1 assessment criteria state that network topology and deployment conditions should accompany TPS evaluation. The standard also addresses the importance of measuring under a stable test environment.
Imagine the school desk achieving a record score when every form is pre-filled correctly and the students are already standing in order. That is a valid test of some operational capacity. It is not automatically a promise of identical performance during chaotic student arrivals.
A responsible report says whether it measures a theoretical maximum, a benchmark peak, a sustained test result or observed production throughput over a specified period.
A huge TPS claim without the workload and test conditions is more like a headline than a reproducible engineering finding.
A native transfer is not the same work as a contract call
The word transaction can describe operations with very different resource requirements. On Ethereum, a straightforward native ETH transfer and a complicated smart-contract call may consume different quantities of gas.
A large contract can read state, execute checks, write storage, interact with another contract and emit events. A simple transfer may require fewer of those operations. Counting each as one transaction can hide the different work required to process them.
Imagine comparing a school desk that stamps one-word forms with another that verifies a ten-page scholarship application. Both count processed applications, but the workloads are not equivalent.
This affects blockchain capacity. When resource budgets and block limits constrain the network, the number of operations completed in one second depends on how expensive each operation is under the relevant rules. There may be no one fixed TPS number that applies to every mix of applications.
For rigorous evaluation, choose representative operations and report their relative complexity or resource usage. A test using only cheap transfers may not forecast performance for a popular application that runs expensive code.
Read Why Smart Contracts Run Out of Gas for the separate role of execution work and resource limits.
Why failed transactions should be reported separately
A system can receive many requests while a significant fraction fails validation, execution or application-level business rules. Counting all attempts as successful throughput would misrepresent the experience of users who needed completed operations.
Imagine 1,000 students clicking the school registration button. The server responds quickly to all 1,000 requests, but only 600 registrations succeed because the remaining students are ineligible or the workshop reaches capacity. The response rate and successful registration rate answer different questions.
Blockchain systems can have similar distinctions. A transaction may be submitted, included and executed unsuccessfully. An application may process an accepted network event that does not achieve the intended real-world result. A transaction can also be rejected before inclusion.
A useful benchmark states which operations were counted, how failed or reverted calls were handled, and whether it reports submitted TPS, included TPS or successful committed TPS.
The Hyperledger performance metrics paper explicitly distinguishes valid committed transactions from invalid attempts when defining throughput. That is a valuable discipline even beyond the specific technologies the paper examines.
A real user cares whether their request worked. Throughput without success criteria cannot give a complete answer to that question.
High TPS can coexist with a queue
A network has finite capacity under its protocol and deployment. If requests arrive faster than the network can accept and complete them for a sustained period, a backlog can grow.
Suppose the school desk processes 100 forms per minute while students submit 150 per minute for ten minutes. It cannot keep pace under the same operating conditions. Even though its throughput remains 100 forms per minute, the pending pile grows.
A blockchain pending-pool service may show a similar buildup. Different nodes can have different local pending views and policies, so there is not necessarily one universal network-wide queue. Nevertheless, high demand can delay inclusion and affect fee estimates.
A wallet may recommend a different fee to improve selection incentives on some chains, but paying more does not create infinite processing capacity or guarantee an exact settlement time. It also does not repair an invalid request.
The user-facing result can be an unfamiliar delay despite an impressive advertised throughput figure. The relevant measurements are arrival rate, completed rate, backlog, selection policy and the actual time to finality.
For the related network-fee issue, see Why Network Fees Change When It Gets Busy.
Batching can change what one transaction represents
Some systems combine numerous user actions into a smaller number of on-chain transactions or commitments. A rollup, payment application or account-abstraction mechanism can process many operations under one higher-level batch.
A headline might count user operations rather than parent-chain transactions, or count a batch as one transaction while another benchmark counts each included instruction separately. Both can describe useful activity, but the units need to be comparable.
Imagine the school processing 100 registration entries under one signed batch. The batch is one administrative submission but contains 100 student-level operations. Counting one batch or 100 registrations produces different throughput numbers.
Ethereum’s Scaling documentation explains how layer-two systems batch or process user transactions separately before anchoring them to Ethereum according to their specific design. The details differ significantly between implementations.
A reader must also distinguish early layer-two inclusion from parent-chain data availability, proof acceptance and final settlement. The layer-two’s local performance does not automatically equal end-to-end settlement to mainnet.
The critical question is what unit was counted, and which layer accepted it? Without that context, a comparison between L1 and L2 TPS numbers can be misleading.
Why withdrawal speed can differ from transaction speed
A user may perform a quick transfer within a layer-two system but require a separate bridge procedure to withdraw assets to Ethereum mainnet. For some optimistic rollups, a challenge period is part of the canonical withdrawal process.
That means an app can truthfully advertise quick layer-two transactions while the ordinary exit route takes much longer. The two statements refer to different operations and different security conditions.
Imagine the fictional club’s fast register recording ten credits for Kai Kai immediately. Moving those credits to a separate official treasury requires further approval and waiting. Internal registration speed does not determine treasury settlement speed.
Some third-party bridges provide faster exits through destination liquidity, but those services introduce different counterparties, pricing and trust assumptions. A fast quote is not a universal guarantee of the same canonical settlement mechanism.
For an easy-to-read companion, see Why Layer-2 Withdrawals Can Take Days. It explains source inclusion, challenge periods, claims and final execution.
The performance metric should follow the user’s real purpose. If a customer needs assets usable on mainnet, the relevant duration is the full journey to that state, not just the first fast local confirmation.
Why safety and decentralisation belong in a speed comparison
A distributed system can sometimes improve measured performance by using fewer participants, faster communication paths or narrower validation duties. These choices can be appropriate for some applications, but they change the trust and resilience assumptions.
A school can process forms extremely quickly when one administrator decides everything. A committee system may be slower because more participants must check the decisions. The analogy is imperfect, yet it illustrates why governance and verification requirements cannot be removed from a fair speed comparison.
Blockchain architectures differ in validator participation, client diversity, proof systems, settlement layers and operational authority. Throughput does not independently measure all those qualities.
Ethereum’s Scaling overview explains that scaling aims to improve transaction speed and throughput without sacrificing security or decentralisation. That framing is useful because performance is only one system objective.
A very high TPS claim should therefore be accompanied by a description of which parties validate the result, which data remain independently available and what would happen if an operator stopped cooperating.
A good evaluation does not automatically rank every decentralised architecture below every centralised one. It asks whether the actual performance and trust model match the user’s needs and risks.
A small arithmetic comparison of two fictional networks
Consider two imaginary networks, Blue and Green. In a ten-second window, Blue successfully finalises 1,000 of its defined test transactions, which is 100 finalised operations per second. Green finalises 600, or 60 per second.
It would be tempting to call Blue the better network immediately. But imagine that Blue’s particular sample consists of minimal asset transfers in a small test environment, while Green’s consists of complex scholarship verifications involving several state checks.
Now consider latency. Suppose Blue’s median request-to-finality time is 40 seconds and Green’s is 12 seconds under their respective workloads. Green may provide a better single-user experience despite completing fewer operations per second in the window. The different workloads still prevent a clean overall ranking.
Add a failure rate. Blue submitted 1,100 requests to complete its 1,000 successful operations; Green submitted 610 to complete 600. If a website counts attempted requests, its numbers change again. A reader needs the denominator and success criteria.
These are invented teaching values, not real measurements. They demonstrate that one number cannot capture workload, delay, reliability and verification assumptions simultaneously.
The correct comparison is a table of equivalent tasks under stated conditions, with throughput, latency distribution, success, finality and resources measured consistently.
The cost per useful action can matter more than headline TPS
A network might process many transactions, but a customer also cares about how much it costs to complete the intended task. A useful comparison therefore considers the fee paid by the user or sponsor and the total application workflow, not only processing capacity.
Suppose the school runs a registration programme in which each student needs three separate transactions: approve a token, submit a registration and claim a ticket. A raw TPS number for simple transfers does not tell parents how much this complete journey will cost or how long it will take.
A different application might perform the same legitimate user task with one properly authorised transaction. Its underlying blockchain could advertise lower peak TPS while the application provides a simpler and cheaper experience for that task.
Cost also depends on congestion and resource pricing. A sponsor may pay the network fee so that the end user sees zero, while the underlying processing remains costly to the organisation.
The relevant question is what does it cost to complete one successful task under the agreed security and usability conditions? That is often more meaningful than the number of isolated transactions counted by a dashboard.
Read Why Gasless Transactions Still Have a Payer for how the direct payer can differ from the party receiving the service.
Hardware and network conditions affect measured speed
A benchmark’s performance depends on more than protocol theory. Computers have CPU, memory, disk and network constraints. The geographic distribution of nodes, bandwidth and software implementation can affect how rapidly transactions propagate and are verified.
If a test uses powerful servers in one data centre, its results may not generalise to a globally distributed network with more latency and independent operators. The software workload, number of participants and configuration must be specified.
The Hyperledger Caliper documentation includes resource-consumption indicators such as CPU, memory and network I/O. The ITU-T performance assessment recommendation distinguishes received and confirmed transaction rates.
A benchmark might show a bottleneck in signature verification under one test and network transmission under another. Upgrading only one component would not necessarily improve the other.
For students, compare a library clerk using a fast computer but a broken printer with another clerk using modest equipment and a reliable printer. Speed depends on the full workflow and the bottleneck that constrains it.
A trustworthy claim publishes enough environment information for an independent person to understand or repeat the test instead of simply accepting a promotional number.
How to build a meaningful blockchain benchmark
A sensible performance study begins with one clearly defined use case. For example: “One registered school member authorises a ticket purchase, and the relevant on-chain state becomes final under the chosen network’s rules.”
Next define the test transaction and its cost. Is it a simple transfer, a contract call, a batch or an off-chain signature followed by a sponsored operation? Different tasks should not be silently mixed.
Then choose a fixed observation window, request volume and measurement method. Record when each request was submitted, first included, accepted at the relevant finality level and made useful to the application. Track failed and timed-out requests separately.
Measure throughput and latency distribution together. The median is useful, but tail values reveal slow experiences under load. Record any backlog, retries or periods where the system stops serving requests.
Document the environment: network, node configuration, hardware, software version, number of participants, geographic distribution, available bandwidth and fee assumptions. These details are necessary for meaningful comparison.
Finally report limitations honestly. A single laboratory test is evidence under its conditions, not a guarantee of production performance forever. The Hyperledger Metrics paper stresses reproducibility and explicit test setup for precisely this reason.
A science-club exercise in three speed measures
Give three students paper roles: sender, processor and final verifier. Alicia submits imaginary registrations by writing a request number. Kai Kai processes them in batches. Tricia marks them finally accepted only after the classroom’s predefined confirmation rule has been met.
For the first round, Kai Kai processes 20 forms in ten seconds. Calculate throughput as two forms per second. Now ask when Alice’s particular form was submitted and when Tricia marked it accepted. That is a separate latency measurement.
In the second round, increase batch size but delay each batch until enough requests accumulate. Throughput may rise while an individual student’s waiting time becomes longer. The class has discovered why throughput and latency can move independently.
In the third round, add five intentionally invalid forms. Students should compare received requests with successfully completed ones. Counting every attempted request as valid throughput would hide failure.
Finally add a second fictional school office that releases physical tickets after a longer review. The class should track the end-to-end user journey rather than claiming success when the first desk stamped the form.
The activity needs only paper and a classroom clock. It turns performance language into observable steps instead of relying on advertisements for real chains.
Seven questions to ask about a TPS claim
1. What transaction is being counted? Native transfer, contract execution, L2 user operation, batch or internal event? The unit must be defined.
2. Which lifecycle stage counts? Received, included, committed or finalised? A submission rate is not necessarily a success rate.
3. Over what period? A peak for a few seconds is different from a sustainable average during a full day of demand.
4. What was the workload? Compare equivalent transaction complexity, input size, contracts and network configuration.
5. How long did users wait? Report submission-to-inclusion and relevant finality latency, including percentiles rather than only average speed.
6. What failed or queued? Identify rejected requests, reverts, retries, backlog and resource limitations.
7. What security and cost assumptions apply? Identify participants, proof or consensus requirements, fees, data availability and any external settlement or withdrawal steps.
When these answers are available, a TPS figure becomes meaningful evidence. Without them, it remains an incomplete marketing statistic.
Frequently asked questions
What does TPS mean in blockchain technology?
TPS stands for transactions per second. It measures a rate under a specified counting method and time interval, such as successfully committed transactions per second.
Does 1,000 TPS mean every transaction settles in one millisecond?
No. Aggregate throughput and individual latency are different measures. A system may process large batches while users wait for inclusion or finality.
What is the difference between throughput and latency?
Throughput measures how much work is completed per unit time. Latency measures the time a particular request takes between defined starting and ending events.
What is transaction finality?
It is the relevant network-specific settlement condition that provides confidence an accepted result will not be replaced or reversed under the protocol’s security model.
Why can a high-TPS blockchain feel slow?
Users may encounter network queues, delayed inclusion, application checks, longer finality periods, failed requests or separate bridge and settlement stages.
Why do TPS numbers from different blockchains disagree?
They may use different transactions, network sizes, peak windows, hardware, inclusion criteria, finality definitions or methods for counting bundled operations.
Do failed transactions count toward TPS?
That depends on the metric. An honest report should distinguish received attempts, included operations and valid successful commits rather than hiding failures.
Why do smart contracts affect TPS?
Different contracts require different computational and storage work, so the same block-resource budget can accommodate different numbers of operations.
Does layer-two TPS include Ethereum mainnet finality?
Not automatically. A layer-two may count its own transactions or operations, while the data-posting, proving, finality and withdrawal lifecycle involve additional conditions.
Can batching increase TPS?
Batching can improve effective processing of user operations, but measurements must specify whether they count individual operations, batches or parent-chain transactions.
Is higher TPS always better?
Not in isolation. A practical system also needs acceptable security, decentralisation, data availability, cost, reliability and latency for the user’s actual task.
What should students remember?
TPS tells you how many operations were handled under stated rules, not how quickly one user’s complete and final result will arrive.
Sources and what to read next
Ethereum Scaling distinguishes throughput and finality while explaining why scalability must preserve security and decentralisation. The Hyperledger Blockchain Performance Metrics white paper defines transaction throughput and latency and stresses reproducible tests. Hyperledger Caliper documents performance indicators including throughput, latency and resource use. The ITU-T F.751.1 assessment standard discusses the influence of test environment and network topology on TPS.
For the deeper eduKateSG reading route, continue to Blockchain Benchmarks: Follow the Cohort from Submission to Finality, Reading Blockchain Consensus Claims, Why a Confirmed Transaction Can Be Reorganised, and Why Layer-2 Withdrawals Can Take Days.
The lasting lesson is straightforward: count useful completed actions, measure the whole wait, identify finality and disclose the conditions. That is how a number like TPS becomes reliable evidence rather than an isolated speed boast.