Transactions Per Second (TPS)

Overview

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.