One of the most common moves in public-chain storytelling is throwing out a large enough throughput number. The "peak TPS" on a homepage and the throughput you can observe on-chain in real time are often not the same statistic. Third-party monitors have publicly compared claimed peaks with measured throughput; on some networks the gap spans two orders of magnitude or more. That is usually not a simple story of "who is lying," but of "theoretical peak" and "throughput in an observation window" being habitually blurred.
For readers evaluating high-performance designs — especially parallel EVM — comparisons are apples-to-oranges until TPS, BPS, confirmation latency, finality, and conflict rate share definitions. Who Should Read About Parallel EVM split reading paths by role; this piece supplies the shared measurement vocabulary. External figures cited below are public-disclosure examples used to illustrate measurement differences; they are not project ratings or investment advice.
TPS: one acronym, at least three formulas
TPS literally means transactions per second. In practice there are at least three distinct calculations:
- Theoretical / lab peak: an upper bound under specified hardware, client version, and transaction mix (often simple transfers or synthetic low-conflict load). Largest number; weakest extrapolation to mainnet.
- Sustainable throughput: the rate the system can hold under stated latency and failure-rate constraints. For payments and settlement, this is often more meaningful than peak.
- Observation-window throughput: transactions included and confirmed (under a chosen finality definition) in a time window, divided by seconds. It reflects real demand and congestion, not capability ceiling.
Ask three questions in parallel or comparison fails: how are transactions counted (including votes / housekeeping)? Are failed or rolled-back transactions included? How long is the window, and what hardware and client version were used? Parallel EVM adds a fourth: what was the conflict rate or hotspot distribution of the test load? A peak without conflict distribution has limited value — expanded in Conflict Hotspots and Workloads.
The same chain can honestly publish all three TPS modes: lab peak for ceiling, sustainable for the usable product band, observation-window for whether demand fills capacity today. Printing them as one number is where misdirection begins. When you see "up to," default it into the peak bucket and look for sustainable and observed counterparts.
BPS: do not translate "faster blocks" directly into "faster users"
In this article BPS means blocks per second, the block production frequency. Raising BPS can shorten the average wait for the next block, but user-perceived latency also depends on when a transaction enters the proposer's mempool, how long execution and conflict retries take, and how many more blocks or voting rounds protocol finality requires.
BPS is therefore a consensus and packing-rhythm metric, not a sufficient statistic for end-to-end experience. A chain can raise BPS and still feel slow if high-conflict execution piles up a re-execution queue. When reading materials, record BPS separately from confirmation latency and finality; do not let faster block times stand in for the whole performance story. If a document uses BPS for another meaning (for example byte-oriented throughput), follow that page's definition and do not mix it with this article's sense.
Confirmation latency: from send to "I see it"
Confirmation latency usually means: time from when a user (or wallet) submits a transaction until the network acknowledges it under some "acceptable confirmation" rule. The critical part is writing down what "acceptable" means — appearing in the latest proposed block, surviving k subsequent blocks, or meeting a BFT-style commit condition.
Practical reading habits:
- Prefer p50 / p95 / p99 over averages alone; tails drive support tickets and arbitrage windows.
- Note load: empty-chain latency and congested-period latency are different metrics.
- For parallel execution, additionally watch whether conflict retries widen part of the latency distribution.
- Separate "executed on my local node" from "finalized by the network": wallet UIs sometimes show the former; settlement often needs the latter.
A complete latency disclosure states the confirmation definition, percentiles, load description, and how clients were sampled. Missing any item makes the number hard to reproduce. Payments and merchant settlement especially need predictable latency upper bounds; average-only materials have almost no decision value for those scenarios.
Finality: do not conflate economic and protocol finality
Finality describes how costly — or whether, by protocol — a transaction result can still be overturned. Two common usages are often mixed:
- Protocol finality (deterministic finality): under BFT-style consensus, once enough votes are collected a block enters a committed state and honest nodes will not roll it back under the protocol. Latency is often framed in message rounds.
- Economic / probabilistic finality: under longest-chain or some rolling-confirmation rules, reorganization probability falls as more blocks accumulate, but a longer chain can still replace history in theory; "final" is a risk threshold.
Calling "N confirmations" under probabilistic finality "finalized" distorts cross-chain comparison. For settlement and bridge scenarios, state which finality model applies and under what assumptions (adversary hashpower / stake fraction / network synchrony). Bitroot's technical narrative around Pipeline BFT aims at fast protocol finality; see Pipeline BFT and Multi-Engine Synergy. Whether a product claim of sub-second finality holds is still bound to that test's disclosed conditions — design goals are not verified mainnet facts.
Finality time relates to confirmation latency but is not identical: users may refresh a UI after a soft confirmation while bridges and custodians still wait for protocol finality. When comparing two chains, first align which tier of "good enough" you are comparing.
Conflict rate: the parallel-EVM "hidden denominator"
Conflict rate describes, under optimistic parallelism, the share of transactions that must roll back or be re-executed serially because of read/write-set conflicts (definitions should state: by transaction count or by gas; account- or slot-grained). It rarely appears on classic single-thread posters, yet it is the denominator that explains why transfer benchmarks look fast and AMM benchmarks slow down.
Rough intuition:
- Conflict rate near 0: parallel speedup can approach the number of execution engines (still bounded by scheduling and state-access overhead).
- Rising conflict rate: effective throughput slides toward "serial execution plus rollback cost" — CPUs stay busy while users still wait.
An honest parallel-EVM benchmark therefore reports at least two figures: low-conflict load and high-conflict (or realistic mixed-contract) load, with the conflict definition stated. Publishing only a transfer peak hides the denominator. Also compare a gas-weighted conflict rate: a few heavy hotspot transactions can puncture throughput more than many light conflicts.
Minimum disclosure checklist for reading benchmarks
When you see a performance table, tick the boxes:
| Disclosure | Why it matters |
|---|---|
| Hardware (CPU / RAM / disk / network) and node count | Otherwise you cannot tell if the peak was stacked on extreme machines |
| Client version and configuration | Same protocol, different implementations, different numbers |
| Transaction mix and conflict-rate definition | Decides whether parallel figures extrapolate |
| TPS mode (peak / sustainable / observed) | Prevents comparing three formulas as one |
| Confirmation definition and percentiles | Prevents "fast on average, slow in the tail" from hiding |
| Finality type (protocol / economic) | Prevents cross-model false comparisons |
| Mainnet, testnet, or lab | Testnet figures are not production-stable performance |
The more items missing, the less citable the number. That runs against homepage logic of "bigger is better," but it is the only reproducible reading for engineering and research. Read it together with the next article's decentralization dimensions: the same peak measured only on a few high-spec machines in one metro shrinks further when extrapolated.
Closing
Performance metrics are not adjectives for a homepage; they are measurements that require attachments. TPS has no single true value, BPS cannot replace user latency, confirmation and finality must be defined before comparison, and conflict rate should no longer be absent from parallel-EVM reading. With this glossary aligned, discussions of decentralization versus hardware bars — and throughput collapse under hot workloads — are less likely to be hijacked by a single peak.
Further reading
- Previous: Who Should Read About Parallel EVM: Three Paths for Contract Developers, Client Engineers, and Researchers
- Next: The Tension Between Decentralization and Performance: Validator Requirements, Hardware, and Geographic Distribution
- Related: Conflict Hotspots and Workloads: When Parallel EVM Actually Helps