Transactions Per Second (TPS)

Overview

What it means in plain English

Transactions per second is a throughput measure describing how many transactions a blockchain or payment system processes over a defined interval. TPS depends on transaction complexity, block capacity, execution model, batching, and what the measurement counts. Headline values are not directly comparable unless they use the same workload, success criteria, layer, and observation period, and high TPS does not by itself prove low latency or finality.

How it works and why it matters

Transactions Per Second (TPS) is usually calculated as processed transactions divided by elapsed time, but the definition of processed varies. A benchmark may count submitted, included, successfully executed, or finalized transactions. It may also include batches that represent many user actions.

Throughput depends on workload. A simple native transfer consumes fewer resources than a complex smart-contract call, so the same network can show different TPS under different transaction mixes. Block size, Gas Limit, execution parallelism, storage access, and consensus timing all affect capacity.

Layer 2 systems can aggregate many transactions and publish compressed data or proofs to a base chain. Reporting only the layer 2 number can hide data availability, settlement, and finality assumptions. Cross-system comparisons should state which layer is measured and whether failed or internal operations are counted.

TPS differs from latency. A system can process many transactions per second while an individual payment waits for batching or finality. Conversely, a low-volume network can confirm one transaction quickly. Merchants care about time to reliable payment state, fee predictability, and availability as well as throughput.

Benchmarks should describe hardware, network conditions, duration, transaction type, and sustained versus peak performance. During real Congestion, queues, fees, and failure rates may matter more than advertised maximum TPS. Capacity planning should use observed business workloads and end-to-end settlement metrics.

A more useful operational dashboard pairs throughput with queue depth, confirmation latency, success rate, resource use, and finality time. This reveals whether higher processing volume actually improves merchant experience or merely moves the bottleneck to sequencers, data publication, indexing, or settlement.

Worked example

Network A advertises 2,000 operations per second under a test workload. Network B reports 100 completed value transfers per second under realistic conditions. Those figures measure different workloads and cannot be compared without defining which operations count and how long the test ran.

Practical checks and common confusion

Separate theoretical capacity, observed average throughput and sustained throughput under congestion. A high TPS number says little about transaction finality, decentralization, fees or whether a checkout can reconcile payments reliably.

Learn the related concepts

Transaction Trace Unsigned Transaction