Contextualizing Blockchain Performance

Transactions per second is the most cited metric in the industry and the least useful on its own. Here is what determines whether a network can carry institutional workloads, and how to evaluate it.

Transactions per second is the number everyone quotes when comparing blockchains. It appears in pitch decks, research notes, and timelines as shorthand for how fast a network is. One chain quotes 65,000. Another quotes 10,000. The assumption is that higher is better, and the conversation moves on.

The problem is that TPS, as commonly cited, does not measure what most people assume. It is a theoretical figure calculated under conditions that rarely resemble production. Two networks can post very different TPS numbers and deliver comparable real-world performance, while two others post similar numbers and behave nothing alike under load.

For anyone building on or allocating to a blockchain, what matters is how throughput behaves under real conditions, what finality means for settlement, and how gas costs behave over time. Those are the figures that determine whether a network can support what you are trying to build.

What TPS actually measures

A TPS figure usually represents the maximum number of transactions a network can process per second under optimal conditions: a single transaction type, a controlled validator environment, and no competing demand.

Production workloads look different. Real networks carry mixed transaction types with varying execution complexity, validators distributed across geographies with real latency, and demand that fluctuates. Under those conditions, the gap between theoretical maximum and sustained throughput can be large.

Many headline numbers also rely on architectural trade-offs that compress performance in production. Some networks reach their figures by requiring validators to colocate in data centers, which concentrates infrastructure risk. Others cap per-transaction execution complexity to push the number up, which reduces what developers can build.

Monad's 10,000 TPS is a designed network capacity rather than a stress-test peak, grounded in architecture intended to hold under production conditions. Three mechanisms drive it.

The architecture behind the number

Parallel execution. Most EVM chains process transactions sequentially. Monad executes them in parallel using optimistic concurrency control. Transactions begin executing before earlier ones in the same block have fully resolved, and when a conflict is detected, the affected transaction re-executes against corrected state. Independent transactions (which comprise the majority of activity on blockchains) proceed simultaneously. The ordering required for state consistency is preserved without requiring sequential execution.

Asynchronous execution. On most blockchains, validators must fully execute every transaction in a block before voting on it, so execution and consensus compete for the same time budget and execution gets only a fraction of it. In Ethereum, that worst-case execution budget works out to roughly 100 milliseconds inside a 12-second block, about 1% of block time. Monad separates the two into parallel pipelines. Nodes agree on transaction ordering first, and execution proceeds afterward with access to the full block time. This is what lets Monad carry a large per-block gas capacity while holding 400ms block times. A draft proposal, MIP-12, would shorten that interval further to 300ms; it is in governance discussion and not yet adopted.

Native compilation. Monad compiles frequently-used EVM bytecode to native machine code rather than interpreting it instruction by instruction, which lowers execution overhead. The client is written from scratch in C++ and Rust and is fully open source.

None of these depend on hardware concentration or validator colocation. Monad runs on commodity hardware with a globally distributed validator set, so performance does not rest on controlled infrastructure conditions. Unlike blockchains that optimize purely for performance with a centralized sequencer, Monad does not sacrifice decentralization, making it far more censorship resistant with less counterparty and exploitation risk.

Gas: the number developers budget against

Throughput tells you how much a network can handle. Gas costs tell you how expensive it is to use, and whether that cost is stable enough to support businesses.

Monad uses an EIP-1559-compatible fee mechanism, where the price per gas is a system-set base fee plus a user-specified priority fee, with a minimum base fee as a floor. The block gas target is set at 80% of the limit, and the base fee controller is calibrated to rise more slowly and fall more quickly than Ethereum's, which reduces sustained overpricing during ordinary demand.

One structural point: Monad charges the gas limit set in a transaction rather than the gas used at execution. This follows from asynchronous execution, since leaders propose blocks before execution completes, so gas has to be accounted for at proposal time. For developers, the practice is to set explicit gas limits for known operations.

Monad also sets gas amounts to reflect what an operation actually costs the network. Compute, state access, and bandwidth are distinct resources that do not scale together, so Monad weights opcode pricing across those dimensions rather than charging one blended number, which keeps the cost of an operation closer to the work it causes. MIP-8 applies the same principle to storage: the protocol groups storage slots into 4 KB pages, and within a transaction only the first read from a page pays the full cold price, while every other slot on that page is priced as warm, at a fraction of the cost. Workloads that touch clusters of related data, such as balances, positions, and account configuration, get cheaper, and pricing stays tied to actual resource use.

The combination of high per-block capacity and a slow-adjusting fee curve reduces the frequency and severity of fee spikes relative to networks running close to their gas limit. In short, Monad can support businesses that need to regularly process a large number of transactions without worrying about high fees (such as micropayments).

Finality: what settlement actually requires

Finality is the point at which a transaction cannot be reversed. Networks differ in how they define it. Some offer probabilistic finality, where confidence grows as blocks accumulate but no single moment is definitive. Others offer deterministic finality, where a specific consensus event marks irreversibility.

Monad reaches deterministic finality in two consensus rounds, roughly 800ms, and speculative finality, revertible only in rare circumstances, in a single round at roughly 400ms. MonadBFT achieves this with a pipelined BFT mechanism that has linear message complexity on the happy path, so it scales to a large validator set without all-to-all communication, and it is resistant to tail-forking, a class of attack in earlier pipelined protocols where a malicious leader could fork away a predecessor's block.

The contrast is clearest across chains. Block time and time to finality are different numbers, and for settlement only the second one matters.

The practical result: an application that needs to act on a confirmed settlement, redemption, or payment can do so in under a second with certainty.

EVM compatibility: what it means in practice

Throughput, gas, and finality are network properties. EVM compatibility is an ecosystem property, and it sets the real cost of moving to a new chain. For many institutions, a lack of EVM-compatibility is a deal breaker. It is the difference between deploying in six months versus several years.

The Ethereum ecosystem holds the largest pool of audited contract code, the deepest tooling, and the longest audit history in the industry, and EVM-compatible chains inherit all of it. Teams do not learn a new language, rewrite infrastructure, or find auditors for a different virtual machine. Monad is fully EVM bytecode compatible and supports Ethereum's JSON-RPC API, so existing deployments move over without rewrites, and EVM custody, compliance, and wallet infrastructure extends to Monad with minimal integration work.

Reading performance claims

The next time a throughput figure shows up in a comparison, the useful questions are: under what conditions was it measured, does it hold under real load, what does finality look like, and how do gas costs behave when the network is busy?

Monad's documented figures, a 10,000 TPS design capacity, 400ms block time, 800ms deterministic finality, and an EIP-1559 fee model on a globally distributed validator set, are a starting point for that evaluation, and the architecture and documentation behind them are public.

Clearing that bar is the qualifier, not the conclusion. Furthermore, what separates blockchains is what an asset or a payment can do once it is on the chain. On Monad, a stablecoin can settle a payment, earn yield in a lending market, and collateralize a position without leaving the chain. A tokenized treasury can be held, traded, and financed in the same environment. Liquidity, real-world assets, trading, and payments sit together and compose throughout the onchain economy. That composability is the structural advantage, and it is the part a throughput number is never going to capture.

The chain that wins the next decade is the one where capital has a reason to not only arrive, but stay long term. The combination of performance and composability is what keeps capital within onchain economies.

For more on Monad's infrastructure and ecosystem, visit monad.xyz.

About Monad

Monad is a high-performance, institutional-grade Layer 1 blockchain purpose-built to power the financial layer of the internet. Fully EVM-compatible, Monad delivers 10,000 TPS, 400ms block times, 800ms finality, and near-zero fees — without requiring specialised hardware. The network runs on consumer-grade machines, supporting accessible participation and decentralized network operation: over 200 independently operated validators across 30+ countries and 55+ cities secure the chain today.