Monad is a high-performance Ethereum-compatible Layer 1 blockchain described in technical documentation by Keone Nadeau and Monad Labs (2022–2024). Monad’s thesis: full EVM compatibility and 10,000 TPS are simultaneously achievable by redesigning the execution architecture — not by compromising on EVM semantics or decentralization.

Three core innovations:

1. Parallel EVM with optimistic parallelism: Execute transactions simultaneously across CPU threads; detect and re-execute conflicts after the fact — instead of ordering them strictly before execution
2. Deferred writes (pipelined execution): Keep in-progress state in a local buffer; commit to the database only after full block execution — decoupling execution speed from I/O speed
3. MonadDB: A custom state database designed for the specific access patterns of EVM execution (random small reads, batch sequential writes), replacing Ethereum’s MPT + LevelDB combination

> Documentation: monad.xyz

---

Publication and Context

Monad Labs raised $225M in a Series A in April 2024 led by Paradigm — one of the largest single rounds in crypto infrastructure. Keone Nadeau is a former Jane Street trading systems engineer; the team has deep systems programming and distributed systems backgrounds.

By 2024, the “parallel EVM” narrative was well-established: Sei v2, Aptos (Block-STM), and Fuel had all demonstrated parallelism concepts. Monad differentiates by committing to full Ethereum bytecode compatibility — the same EVM semantics that Ethereum mainnet uses — rather than a new VM (FuelVM) or a non-EVM design (Move on Aptos).

This means every existing Ethereum smart contract can deploy on Monad without any modification — a stronger claim than most parallel execution systems.

---

Parallel EVM: Optimistic Parallelism

Why Sequential EVM Is A Bottleneck

Standard Ethereum EVM processes transactions strictly sequentially: transaction 1 completes, its state changes are written, then transaction 2 begins. This prevents conflicts (two transactions attempting to modify the same storage slot simultaneously) but wastes CPU time — most transactions touch disjoint state.

Monad’s Optimistic Parallelism

Monad executes transactions speculatively in parallel:

1. All transactions in a block are dispatched to parallel execution threads simultaneously
2. Each thread maintains a local speculation buffer: reads are checked against the buffer; writes go into the buffer (not the database)
3. After all threads complete, the system checks for read-write conflicts: if transaction 5 read a value that transaction 3 (which ran concurrently) wrote, transaction 5’s result is invalid
4. Conflicting transactions are re-executed serially in correct order
5. Valid (non-conflicting) transactions have their buffers merged into the database

Efficiency: In typical DeFi workloads, 60–80% of transactions touch disjoint state and run fully in parallel. Only 20–40% require serial re-execution.

Deferred Writes

Separating execution from state commitment is Monad’s deferred writes optimization:

1. During block execution, all state writes go to an in-memory journal (not the database)
2. Block execution completes (fast, in-memory)
3. After all transactions are executed and validated, the journal is committed to MonadDB in one pass

This allows the execution pipeline to run at CPU speed without being bottlenecked by I/O latency on each write.

---

MonadDB: Custom State Database

Ethereum’s state database uses a Merkle Patricia Trie (MPT) stored in LevelDB:

• MPT provides cryptographic state roots (necessary for proofs)
• LevelDB is a general-purpose key-value store (not optimized for MPT access patterns)

Problems with MPT+LevelDB for Monad:

• MPT updates are random write amplification (updating one storage slot touches multiple MPT nodes)
• LevelDB’s LSM-tree structure is not ideal for EVM’s mixed read/write patterns
• MPT traversal is slow (each storage slot lookup requires traversing the trie)

MonadDB is a custom database designed for EVM state:

• Separates state storage from proofs: Storage (account balances, contract data) is stored in a fast flat structure; Merkle proofs are computed separately, asynchronously
• Async I/O: MonadDB is designed to overlap I/O and execution, using async disk access to hide I/O latency
• State commitment is pipelined: The database commits Merkle roots asynchronously after block execution, not blocking the next block’s execution

---

MonadBFT: Pipelined Single-Slot Consensus

MonadBFT is a pipelined BFT consensus protocol targeting single-slot finality (finality within one block, not two):

Pipelining: In standard BFT (Tendermint-style), each phase (propose → prevote → precommit) must complete before the next begins. MonadBFT pipelines these phases: while one block is being prevoted, the next block is being proposed.

Single-slot finality: A transaction achieves final, irreversible confirmation within one block period.

MonadBFT is described as related to the HotStuff family of BFT protocols (linear message complexity) but with pipeline modifications for single-slot finality.

---

Key Technical Properties

Property	Value
EVM compatibility	Full EVM bytecode compatible
Execution model	Optimistic parallelism + deferred writes
State database	MonadDB (custom, async I/O)
Consensus	MonadBFT (pipelined BFT)
Finality	Single-slot
Target TPS	10,000
Block time	~1 second (target)
Mainnet	Testnet 2024; mainnet expected 2025

---

Reality Check

Monad’s technical design is well-grounded in systems engineering principles. Optimistic parallelism, deferred writes, and custom state databases are established techniques in distributed systems applied to EVM.

Important caveats:

• Mainnet not yet launched (as of early 2025): Monad is in extended testnet; production performance is unverified
• 10,000 TPS under realistic conditions: TPS claims are typically measured under synthetic workloads; real DeFi transactions (with AMM pool state hotspots) have much higher conflict rates. Realistic TPS on DEX-heavy workloads may be significantly lower
• Centralization during launch: Early Monad validators are likely to be a small, selected set; decentralization timeline is unclear
• No open-source code: Monad’s core code was not open-sourced as of early 2025
• $225M valuation pressure: A $225M Series A implies a very high FDV expectation; delivering on this requires significant ecosystem adoption that does not yet exist

---

Legacy

Monad represents the most ambitious attempt to date to achieve high throughput while maintaining Ethereum bytecode compatibility. If mainnet performance matches claims, it would represent a major advance for EVM-native DeFi. The parallel EVM design (optimistic parallelism + deferred writes + custom DB) is a coherent systems architecture that will influence future blockchain execution environment design regardless of Monad’s market success.

---

Related Terms

• Parallel EVM
• EVM
• Block Time
• Throughput
• Sei Whitepaper
• Aptos Whitepaper

---

Research

• Monad Labs. (2024). Monad Technical Documentation. monad.xyz.

— Primary source; describes optimistic parallelism, deferred writes, MonadDB, and MonadBFT consensus design.

• Gelashvili, R., Spiegelman, A., Xiang, Z., Danezis, G., Li, Z., Malkhi, D., Xia, Y., & Zhou, R. (2022). Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. PPoPP 2023.

— Block-STM (Aptos’s parallel execution system); the closest published academic work to Monad’s optimistic parallelism approach.

• Yin, M., Malkhi, D., Reiter, M., Gueta, G.G., & Abraham, I. (2019). HotStuff: BFT Consensus with Linearity and Responsiveness. ACM PODC 2019.

— HotStuff BFT consensus; MonadBFT is reportedly derived from or related to this family of linear-message-complexity BFT protocols.