One of the blockchain industry's favorite marketing moves is throwing out a sufficiently large number. 65,000, 100,000, 160,000 — TPS figures like these, plastered across project homepages, are big enough to make every competitor look slow. But pull apart how each number was actually measured, and it often turns out they aren't measuring the same thing at all.
Research from Chainspect shows that Solana's officially claimed 65,000 TPS is 222 times higher than its real-time measured figure of 292.45 TPS; Arbitrum's claimed 40,000 TPS is more than 3,000 times its measured 12.43 TPS. No chain is necessarily lying here — "theoretical peak" and "actual throughput" are simply two different metrics that the industry has gotten used to blurring together. For anyone evaluating a high-performance chain, especially in the parallel EVM space, none of the comparative data that follows means much unless you first pin down exactly what TPS, BPS, confirmation latency, finality, and conflict rate mean — and how they commonly get misused. Otherwise you end up comparing apples to oranges without realizing it.
This piece isn't about any one specific chain. It's about laying out this measurement framework clearly, so the head-to-head comparisons and benchmarks later in this series (Series F) have a consistent, verifiable basis to build on.
TPS: one number, at least three different formulas
TPS literally means transactions processed per second, but that seemingly simple number gets calculated at least three distinctly different ways in practice — and the gap between them can run to tens or even thousands of times over.
The one that shows up most often in whitepapers and fundraising decks is max theoretical TPS: the mathematical ceiling a system could reach if network bandwidth, hardware performance, and block size all hit their design limits at once, with zero conflicts or re-execution overhead. It's the favorite precisely because it's the biggest number available — at the cost of almost never being sustained on a real network.
More grounded than that theoretical peak, though still not free of performance theater, is max recorded TPS — the highest value a network has ever measured within some very short window. Numbers like these tend to come out of purpose-built stress tests, such as Solana's 100k TPS stress test in 2025, or an unusual spike in on-chain activity; they carry more weight than the theoretical peak, but still don't represent the network's normal operating capacity.
What actually tracks the user experience is real-time TPS: completed transactions divided by elapsed time within a given measurement window under normal operating conditions. It's the number closest to what people actually feel using the network day to day, and the one third-party monitoring platforms like Chainspect emphasize in their reporting.
Even more easily overlooked than these three definitions is what actually counts as a "transaction." Take Solana as an example: its network carries a large volume of vote transactions, which validators use to confirm blocks — these are consensus-layer internal communication, not economic activity initiated by users. Reportedly, roughly two-thirds of transactions on the Solana network are vote transactions, and including them in total TPS meaningfully inflates the number. According to reporting from BingX and Crypto Briefing, once vote transactions are stripped out, Solana's "non-vote" real throughput regularly exceeded 2,500 TPS in mid-2026, with peaks above 6,000 TPS — far below the advertised 65,000 figure, but a much more accurate reflection of the actual user activity the network is carrying. Chainspect's published methodology explicitly notes that its measurements exclude system transactions and consensus-layer internal communication, as well as the systemic transactions that Layer 2s submit to Layer 1.
There's no absolute right or wrong here — Solana's own explanation is that vote transactions consume network resources and pay fees too, so there's a logical case for counting them. But for cross-chain comparisons, a TPS number that doesn't distinguish transaction composition is nearly guaranteed to mislead. Any serious performance claim should specify the time window the measurement covers, whether it includes system transactions, and whether it's an average under sustained load or a short-lived peak.
BPS and block time: another easily overlooked variable
BPS (Blocks Per Second) is the number of blocks a network produces per second. It's the inverse of block time, and together with block size it determines the theoretical TPS ceiling: TPS is roughly BPS multiplied by the number of transactions each block can hold.
This metric often gets pulled out on its own as marketing material — "400-millisecond block time" sounds much faster than "12 seconds." But fast blocks don't mean fast confirmation, and they certainly don't mean fast finality. A chain can have an extremely short block interval and still leave users waiting several blocks before they perceive a transaction as confirmed, because the consensus layer needs multiple rounds of voting to lock in a block. BPS on its own is just an intermediate variable — it can't stand in for throughput or user experience without accounting for the consensus mechanism sitting on top of it.
Confirmation latency and finality: two concepts that keep getting conflated
Confirmation latency is the time between a user submitting a transaction and the network confirming it. Finality is the degree of certainty that the transaction can no longer be rolled back or reorganized. These sound similar, but they mean very different things for user experience and asset safety: a transaction can be "confirmed" quickly while still being far from truly irreversible "final" — and that gap is exactly where a lot of payment flows and exchange deposit flows get people into trouble.
Different consensus mechanisms give very different answers here. Bitcoin uses probabilistic finality: once a transaction is included in a block, the probability of a malicious reorg drops exponentially as subsequent blocks accumulate on top of it. Industry convention treats 6 block confirmations (the so-called "six-block rule") as sufficiently safe, which takes roughly an hour.
Ethereum, after The Merge to proof-of-stake, adopted an epoch-based finality mechanism. An epoch consists of 32 slots, each about 12 seconds, so an epoch runs about 6.4 minutes. When more than two-thirds of staked validators vote for a checkpoint, that checkpoint becomes "justified"; when the next checkpoint is also justified on top of it, the earlier checkpoint becomes truly "finalized." That means economic finality on Ethereum mainnet typically takes two epochs — about 12.8 minutes. Rolling back a finalized block after that point would require destroying (slashing) at least one-third of all staked ETH — an extraordinarily expensive attack.
BFT-style consensus mechanisms like Tendermint offer "instant finality": once a block gets precommit signatures from more than two-thirds of validators, it's treated as final within that same round — there's no probabilistic waiting period. Chains in the Cosmos ecosystem typically complete this in 1 to 6 seconds. This is the biggest experiential advantage BFT-style consensus has over Nakamoto consensus, at the cost of needing to keep the validator set at a manageable size to keep communication overhead under control.
Solana sits somewhere in between, with a mechanism it calls "optimistic confirmation": once validators representing more than two-thirds of staked weight vote for a block, that block is marked "confirmed" — a process that takes about 400 milliseconds. Solana's own documentation states that no optimistically confirmed block has ever been rolled back since genesis. But full finality — where a block reaches maximum lockout depth after 32 consecutive votes, with an exponentially increasing lockout period — typically takes additional time to complete. In other words, "confirmed" and "finalized" represent two distinct levels of commitment in Solana's model, and which one a wallet or exchange is actually referencing when it shows a "funds received" notice directly affects how safely users perceive their funds to be.
None of these mechanisms is strictly better than the others. But as a reader or evaluator, the minimum bar is being able to tell whether a chain's advertised "confirmation time" refers to soft confirmation or hard finality.
Conflict rate: a new metric specific to parallel execution
For systems that use optimistic parallel execution, there's a metric the consensus mechanisms above never had to deal with: conflict rate — sometimes also called re-execution rate or abort rate.
In the Block-STM paper published by the Aptos team, conflict rate is defined as the frequency with which concurrently executing transactions access the same state data, producing a dependency conflict; abort rate refers to the proportion of transactions that get aborted and re-executed after the validation stage detects such a conflict. The paper specifically notes that, thanks to runtime write-set estimation and a low-overhead collaborative scheduler, Block-STM's abort rate stays quite low under real workloads. The paper's experiments also show a speedup of up to 25x over traditional locking once account counts reach the thousands, indicating the system is not particularly sensitive to conflicts.
The significance of conflict rate is that it's the real bottleneck on throughput for any optimistic parallel execution system. No matter how high a parallel EVM chain's theoretical TPS is, if the conflict rate under real load stays high and a large share of transactions need to be repeatedly re-executed, the throughput and latency users actually experience will fall well short of the theoretical number. So when evaluating an optimistic parallel chain, looking at peak TPS alone isn't enough — you also need to ask: at what conflict rate was this throughput number measured? Was the test load close to conflict-free transfers, or a high-contention DeFi scenario?
Why these definitions are worth insisting on
Research firms like Messari, Delphi Digital, and L2beat typically require disclosure of the exact test load composition, hardware specs, node count, and measurement time window when doing cross-chain comparisons — precisely because metrics like TPS and confirmation latency have so much definitional flexibility that a bare number, disclosed without its test conditions, has almost no comparative value.
This glossary matters especially for the parallel EVM space. Whether a chain uses deterministic parallelism (like Solana Sealevel) or optimistic parallelism (like Aptos Block-STM, Monad, Sei — and projects like Bitroot), the performance numbers vendors publish nearly always involve the same three variables at once: the TPS measurement methodology, the finality tier that the confirmation latency corresponds to, and the conflict rate. Any chain that publishes a bare TPS number with no test conditions attached should be asked to fill in the gaps: is this a theoretical peak or a measured average? Does it include system transactions? Is the corresponding finality soft confirmation or hard finality? What was the conflict rate under the test load?
That habit of asking follow-up questions is exactly the analytical tool this series will keep using in its later comparisons and benchmarks (Articles 79 through 88), and it's the real takeaway this piece hopes to leave you with — not memorizing a handful of term definitions, but building the instinct to ask about measurement methodology the moment you see any performance number.
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"
Sources: Chainspect, "Unveiling Blockchain Performance: Real-Time TPS vs. Max TPS Claims"; reporting from BingX and Crypto Briefing on Solana's non-vote TPS; Aptos Labs, "Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing" (arXiv:2203.06871); ethereum.org and Vitalik Buterin's writing on the beacon chain finality mechanism; Solana's official documentation, "Optimistic Confirmation and Slashing"; Helius, "Solana Commitment Levels"; Nansen, "What Is Tendermint"