If you’re building on a public ledger, theoretical TPS is only part of the story. What matters most is how many transactions the network can process under real-world conditions, with real users, real state, global node distribution, and full security guarantees.
Performance benchmarks for distributed ledgers are hard to compare. Lab numbers and “Theoretical Maxima” get cited constantly, but they rarely tell you what you can actually build on today.
Hedera maintainers and contributors publish performance numbers from the release testing process, with tests run against a mainnet replica before each software release. This is called Verified Throughput. To understand why that distinction matters, it helps to look at what most TPS discussions skip.
The Challenge with Theoretical Maxima
A common way to estimate “Max Theoretical TPS” uses a formula based on block size and block time: (Maximum block size / minimum transaction size) / block time. For block-based protocols under ideal conditions, this gives you an upper bound. But applying it uniformly across all networks produces misleading comparisons. Not every protocol works this way.
Unlike leader-based protocols, hashgraph consensus assembles transactions into blocks collaboratively, without a designated leader. This means that hashgraph is a leaderless protocol where the theoretical limit depends on network bandwidth and timestamp precision.
On Hedera, user transactions are timestamped at the microsecond boundary, putting the consensus ceiling at around 1 million user transactions per second. The network does timestamp at nanosecond precision, but the intervals between user transactions are reserved for system transactions. Hedera reports only user-submitted transactions (not system transactions) to reflect what developers and applications can actually rely on.
That ceiling won’t help you plan capacity for an application launch. Theoretical limits skip over the constraints that shape a production network: state sizes in the hundreds of millions of entities, nodes spread across continents rather than colocated in one data center, and the cryptographic overhead of maintaining ABFT. This is where most TPS comparisons break down.
Consensus vs. Execution: Where the Bottleneck Actually Is
Most TPS discussions treat “processing a transaction” as one operation. However, there are two, and they have very different performance characteristics.
Consensus is ordering
The Hashgraph algorithm works on events, not individual transactions. It mostly ignores what’s inside a transaction. It cares about bandwidth, roughly 200 bytes per transaction on average, and assigning timestamps when events reach consensus. Consensus alone could handle over a million transactions per second.
Execution is applying state changes
Ordered transactions get applied to the network state: updating balances, modifying token associations, writing contract storage. In other words, execution is the part that’s actually hard. The bottleneck is disk I/O, since every transaction requires loading state, applying changes, hashing, and writing results back.
Different transaction types hit disk differently. For example:
| Transaction type | Approx. TPS (performance testing) | Why |
|---|---|---|
| Account creation | 25,000+ | Mostly writes new data |
| Token transfer | ~11,000 | Loads sender + receiver, checks balances, updates multiple records |
The more state a transaction touches, the slower it executes. This distinction between consensus and execution is why a single TPS number rarely tells the full story.
Verified Throughput on Mainnet
Hedera publishes “Verified Throughput,” performance tested and sustained on mainnet. Verified Throughput is the capacity you can architect against, not a best-case number measured under ideal conditions. The current throttle of 10,000 TPS for cryptocurrency transactions on Hedera is a governed limit, not a technical ceiling. In fact, short bursts have already hit 16,000 TPS in production.
The throttle is there for practical reasons. It keeps confirmation times consistent during spikes, prevents any single application from monopolizing capacity, and gives the network room to process transactions against a state with over a billion entities.
That entity count has grown by more than 250x, and sustained throughput climbed from around 4,000-6,000 TPS to above 10,000 TPS over the same period. In other words, the network got faster while managing far more state!
Lab tests with minimal state will always produce bigger numbers. Hedera publishes what developers can use today, security guarantees included.
Scaling in Both Directions
A familiar trade-off in distributed systems is that adding nodes for decentralization degrades performance. Latency goes up, throughput goes down. Hedera approaches scaling differently.
Vertical Optimization
Vertical scaling means getting more out of each node through software and hardware improvements. Consensus is already fast, so vertical gains come from making execution faster, specifically, how nodes read and write state to disk.
This is similar to the optimization work in high-frequency trading: both are Java-based systems constrained by how fast data moves through memory and storage. Performance testing results from each Consensus Node software release. For release v0.70 demonstrates continued execution layer improvements.
The long-term goal is to enable 100,000+ user-submitted transactions per second in a single shard. The consensus algorithm isn’t the constraint. State management speed is, and closing that gap means substantial changes to the execution layer and potentially the hardware running it.
Horizontal Scalability
Horizontal scaling comes through sharding, which means splitting the network into parallel partitions. Because Hashgraph consensus is leaderless, adding nodes to a shard strengthens security without slowing performance. Adding shards scales total throughput linearly, as long as cross-shard traffic remains modest.
Security
Higher throughput at the cost of weaker consensus is a bad trade for a public ledger. Some protocols use weaker consistency models to post bigger numbers. Hedera runs ABFT (Asynchronous Byzantine Fault Tolerance), the strongest guarantee available for distributed consensus.
In practice,asynchronous means consensus holds even when messages between nodes are delayed indefinitely. Weaker BFT variants break under those conditions. Transactions on Hedera are final once confirmed, with no reordering or rollback, and that stays true as the network scales.
What this Means for Developers
TPS is not one number. The throughput an application gets depends on the transaction types it uses and how much state those transactions read and write. If you’re doing mostly token transfers, plan around different limits than if you’re creating accounts. Per transaction type throttle limits are documented alongside the network’s overall throttle configuration.
For developers, the relevant question is not what is possible under ideal conditions. The relevant question is how much throughput you can rely on when your application goes live.
Verified Throughput answers that.
