Performance Race: Transactions Per Second
A popular restaurant on a Friday night. The kitchen can prepare 20 meals per hour. Everything works beautifully when 15 customers arrive. But when 50 people show up hungry, something has to give. Maybe wait times stretch from minutes to hours. Maybe prices rise to discourage diners. Maybe some people simply give up and leave. The kitchen's capacity hasn't changed as it's still making 20 meals per hour. But the experience has become terrible.
This is exactly what happens to a blockchain when demand exceeds capacity. And capacity, in blockchain terms, is measured in transactions per second or TPS.
This is the third article in Performance Race: a five-part series exploring how blockchains pursue speed without losing their principles. Time to talk about transactions per second (TPS): the most cited, yet misunderstood, metric of performance.
To catch up, refer to the previous articles:
Throughput Limits
If you used Ethereum during the NFT boom of 2021, you’ve felt what blockchain congestion means. You’d try to buy something, and your wallet would quote a $50 fee, then $80, then $150, while your transaction sat unconfirmed behind thousands of others.
This wasn’t a glitch. It was a capacity-limited system overwhelmed by demand, with price rising to ration the scarce resource: space in the next block.
That capacity is often expressed as transactions per second (TPS) - how many transactions a network can process each second. But it’s more nuanced than it sounds. TPS depends on two factors working together:
- Block size - how much data fits in each block
- Block time - how often new blocks are created
It’s like shipping packages: if a truck carries 100 boxes and departs every hour, you’re moving 100 boxes per hour. To raise throughput, you can either use a bigger truck (larger blocks) or send trucks more often (shorter block times) or both.
Spectrum of Throughput
Let's look at how different blockchains stack up:
For digital gold like Bitcoin, which most people hold rather than spend, its modest throughput is sufficient. But for a global payment network, it's nowhere near enough. Ethereum improves on speed, but it was never designed for massive throughput. During high demand, this bottleneck becomes painfully obvious. It keeps processing at the same rate, but fees skyrocket as users compete for the limited space.
Solana was built for high throughput. Even with its real-world performance, the network remains orders of magnitude beyond Bitcoin or Ethereum. Visa is often treated as the benchmark for “real” payment network performance, and its TPS figures are the standard many blockchain projects cite. But these comparisons are misleading.
Misleading Stats
Charts comparing blockchain TPS often tell an incomplete story. Not all transactions are equal. A simple Bitcoin transfer differs greatly from an Ethereum transaction executing complex smart contracts. Treating both as “one transaction” is like saying a text message and a video call are the same “internet action”.
Some blockchains boost TPS by making tradeoffs, requiring more powerful hardware, reducing decentralization, loosening security guarantees, or narrowing what counts as a transaction. Finally, theoretical peak TPS means little if a network has never sustained that rate under real-world or adversarial conditions.
Congestion Effect
Low TPS isn’t a problem until it is. Most blockchains run comfortably below their limits, until a surge hits: a viral app launch, an NFT mint, a new token listing, or market volatility. Suddenly everyone tries to transact at once.
What happens next depends on how the blockchain handles congestion:
None of these outcomes feel good for users, whether it’s paying high fees, waiting endlessly, or losing transactions outright.
If you're building on or using a blockchain, TPS shapes what's possible:
Scaling Problem
If low TPS causes congestion, why not just raise it? Make bigger blocks, process them faster, and solve the congestion issue once and for all. The challenge is that increasing TPS isn't free as it comes with costs that threaten the properties that make blockchains valuable in the first place.
This is why Bitcoin's community largely rejected increasing the block size significantly. They believed preserving the ability for anyone to run a node was more important than higher throughput. Other communities made different choices, prioritizing capacity over maximum decentralization.
Reactive in Focus
Reactive Network’s (RNK) throughput is defined not by traditional TPS, but by how many Reactive contracts and event sequences the RVM environment can process per block.
RNK operates with a 7-second block time and an Ethereum-like block structure, giving it roughly twice Ethereum’s base TPS. But the real capacity comes from the RVM environment. In mainnet block 1417146, a single RVM processed 7,399 transactions, and the network can run many RVMs in parallel, each capable of far more throughput.
Under congestion, Reactive behaves like Ethereum by increasing gas prices. Since event execution occurs within RVMs, the system can handle substantially more activity before reaching a limiting threshold.
Theoretical upper bounds are high: roughly 600 sequences per block, each with 1,000+ events, putting potential throughput near 1 million events per block. Testing also showed that a validator was able to include tens of billions of gas within a single RVM.
As a result, Reactive’s performance is determined by the number of active Reactive contracts and processed events within the RVM environment, rather than RNK’s TPS.
Closing Thoughts
Reactive shows how alternative architectures can rethink throughput entirely, moving beyond the narrow lens of raw TPS. But the broader lesson applies to every blockchain: numbers alone don’t define performance.
The blockchain space is locked in a capacity arms race, with each project claiming higher numbers than the last. Some claim millions of TPS, though these figures often come with asterisks, theoretical maximums, simple transaction averages, or internal operations that aren't directly comparable.
What ultimately counts is sustained, verifiable performance. Can a blockchain handle its stated capacity during periods of stress? Can it process complex transactions at scale without sacrificing security? Does throughput remain stable when demand spikes rather than collapsing into high fees or stalled confirmations?
Every chain is navigating the same tension: the desire for decentralization, broad participation, and strong security on one side, and the push for ever-higher capacity on the other. Greater performance typically requires greater hardware, and greater hardware narrows who can participate — a tradeoff no TPS chart will reveal.
About Reactive Network
Reactive is an EVM-compatible execution layer for dApps built with Reactive contracts. These contracts differ from traditional smart contracts by using inversion-of-control for the transaction lifecycle, triggered by data flows across blockchains rather than by direct user input.
Reactive contracts listen for event logs from multiple chains and execute Solidity logic in response. They can determine autonomously when to transmit data to destination chains, enabling conditional cross-chain state changes. The network delivers fast and cost-effective computation via a proprietary parallelized EVM implementation.
Website | Blog | Twitter | Telegram | Discord | Reactive Docs
