How does Monad make the EVM parallel?

The EVM is defined as a sequential machine: transaction 2 runs against the state transaction 1 left behind. Ethereum clients execute blocks that way, one transaction at a time, on one core. Monad is a Layer 1 that runs the same EVM bytecode but executes transactions in parallel, moves execution off the consensus critical path, and replaces the storage layer that usually becomes the bottleneck. The result is meant to behave exactly like serial execution while using many cores and much more of each block interval.

This guide covers the four pieces and what they change for someone deploying contracts.

Optimistic parallel execution

Most transactions in a block don't touch the same state. Two swaps on different pools, a token transfer and an NFT mint can all run at the same time without affecting each other. The problem is that you can't know which transactions conflict before you run them, because the storage slots a contract touches depend on its inputs and on current state.

Monad handles this optimistically:

1. Transactions in a block are executed in parallel, each against the state as it was at the start of the block (or whatever results are available).
2. Each execution produces a pending result: the storage it read (its inputs) and the storage it wrote (its outputs), not a committed state change.
3. Pending results are then committed in the original transaction order. Before committing transaction n, Monad checks whether any of its inputs were changed by an earlier transaction committed in this block.
4. If an input changed, transaction n is re-executed against the correct state before it's committed.

Because commits happen in block order and every conflict triggers re-execution, the final state is identical to running the block serially. That's the key property: parallelism is an implementation detail, not a semantic change. Contracts don't need locks, access lists or any new concurrency model.

Re-execution is also cheaper than it sounds. The expensive part of executing an EVM transaction is usually reading state from disk. The first, optimistic run has already pulled those accounts and slots into memory, so a re-run is mostly computation on cached data.

Asynchronous execution

On Ethereum, a block proposer executes the block before proposing it, and validators execute it before voting. Consensus and execution share the same slot, so execution only gets a fraction of the block time; the rest is spent on networking and voting.

Monad decouples them. Consensus agrees only on the order of transactions in a block. Execution runs afterwards, in its own pipeline, while consensus is already working on later blocks. Since a block's order is final once agreed, every honest node executing it deterministically reaches the same state.

That raises two design questions, and Monad's answers matter to developers:

• How do nodes agree on state? Blocks carry a delayed state root: the state root from a small, fixed number of blocks earlier. A node whose execution diverged will notice when that root doesn't match its own.
• How do you stop spam if nobody has executed yet? At consensus time, a node can't know how much gas a transaction will actually use, or whether the sender's balance will still cover it after earlier transactions execute. Monad budgets block space by each transaction's gas limit, and charges fees on the gas limit as well. It also applies balance rules at consensus time, so an account can't queue transactions it won't be able to pay for.

MonadBFT

MonadBFT is the consensus protocol. It belongs to the HotStuff family: a rotating leader proposes a block, validators vote, and votes are aggregated so communication stays roughly linear in the number of validators in the normal case. Rounds are pipelined, so each new proposal also carries the votes that advance earlier blocks.

Its design targets two practical issues in leader-based BFT:

• Fast finality. Blocks are produced well under a second apart, and finality follows within a couple of rounds rather than the minutes Ethereum takes to finalize.
• Tail-forking. In some pipelined protocols, a malicious next leader can drop its predecessor's block. MonadBFT is designed so that a block that gathered enough support can't simply be discarded that way, which also removes an incentive for leaders to steal each other's MEV.

Block propagation uses erasure coding (RaptorCast) so a leader doesn't have to send a full block to every validator directly.

MonadDb

Parallel execution only helps if storage can feed it. Ethereum clients store the Merkle Patricia Trie inside general-purpose key-value databases such as LevelDB or RocksDB. That puts one tree structure (the trie) on top of another (an LSM tree or B-tree), so a single state read can turn into many disk reads, and reads are typically issued one at a time.

MonadDb is a custom database that stores the Merkle Patricia Trie natively on SSD and uses asynchronous I/O (via Linux io_uring), so many state reads can be in flight at once. That's what lets dozens of optimistic executions fetch state concurrently instead of queuing behind each other. It also keeps hardware requirements closer to a well-specified server with fast NVMe storage rather than keeping all state in RAM.

What changes for developers

Monad aims for bytecode-level EVM equivalence. Solidity and Vyper compile the same way, contracts deploy unchanged, and addresses, signatures and the JSON-RPC API follow Ethereum. Foundry, Hardhat, viem, ethers.js and standard wallets work by pointing them at a Monad RPC endpoint.

The differences to know about:

Area	What's different
Gas charging	You pay for the transaction's gas limit, not the gas used. An inflated gasLimit is paid in full.
Gas estimation	Use eth_estimateGas with a modest buffer; avoid wallet defaults or large fixed limits.
Hot state	Correctness is unaffected, but many transactions writing the same slot in a block (a global counter, a single pool) cause re-executions and serialize work.
Parameters	Limits such as maximum contract size and some opcode or precompile gas costs differ from Ethereum. Check Monad's documentation before assuming Ethereum values.
Finality	Blocks finalize in about a second or less, so confirmation logic built for Ethereum's reorg window can be much shorter.

The gas limit rule is the one most likely to cost users money. On Ethereum, setting a high limit is a harmless safety margin because unused gas is refunded. On Monad it isn't: the protocol reserves block space for the full limit at consensus time and charges for it. Frontends should estimate gas and add a small percentage, not double it.

The hot-state point is a performance consideration, not a bug. A contract where every call increments one storage variable still behaves correctly, but those transactions effectively run one after another. If you're designing for high throughput, keeping per-user state in per-user slots (mappings keyed by address) lets more of the block run in parallel.

Status

Monad's public mainnet, along with the MON token, launched in late 2025 after a long testnet period. Headline throughput figures, such as around 10,000 transactions per second, are design targets from the team; real sustained numbers depend on the transaction mix, and as with any new chain, it's worth checking current validator count, client maturity and documentation before relying on specific parameters.

Summary

Technique	Problem it solves
Optimistic parallel execution	Serial execution leaves most CPU cores idle.
Serial commit with re-execution	Keeps results identical to Ethereum's sequential semantics.
Asynchronous execution	Execution no longer competes with consensus for block time.
MonadBFT	Fast, pipelined BFT finality resistant to tail-forking.
MonadDb	State reads, not computation, are the real bottleneck.

For contract developers, the practical message is short: deploy the same bytecode with the same tools, set tight gas limits, and avoid funnelling every transaction through one storage slot.