Monad’s core thesis is that the EVM (Ethereum Virtual Machine) doesn’t need to be slow — the bottleneck is sequential execution, not the EVM itself. Standard Ethereum and EVM chains execute transactions one at a time in sequence: transaction 1 must fully complete before transaction 2 begins. Monad’s innovation is parallel execution: identify which transactions don’t touch the same state (don’t read/write to overlapping accounts or storage slots), and execute them simultaneously across multiple CPU cores. The result, Monad claims, is 10,000 TPS with ~1 second block time and ~2 second finality — all while remaining 100% compatible with Ethereum’s existing smart contract ecosystem. No code changes required; Ethereum contracts deploy unchanged.
The Parallel EVM Thesis
Why standard EVM is sequential:
Ethereum executes transactions in a strictly ordered sequence because:
- Transaction N might depend on the state left by Transaction N-1
- Without knowing dependencies in advance, safe execution requires sequential processing
- Sequential execution is the simplest guarantee of determinism
Why most transactions aren’t actually sequential:
In practice, most transactions are independent:
- Alice sending ETH to Bob doesn’t affect Carol’s Uniswap swap
- Two separate lending protocol borrows rarely touch the same storage
- Parallel execution of independent transactions is safe and correct
Optimistic parallel execution:
Monad uses “optimistic parallelism” — a concept from database systems:
- Execute all transactions in parallel optimistically
- Track which state each transaction reads and writes
- Detect conflicts (two transactions that read/write the same storage)
- Re-execute conflicting transactions sequentially in order
- Non-conflicting transactions were already correctly executed in parallel
Result: Most of the ~10,000 TPS comes from parallel execution of non-conflicting transactions; a smaller subset is handled sequentially.
MonadBFT Consensus
Monad developed “MonadBFT” — a Byzantine Fault Tolerant consensus mechanism:
Properties:
- Direct derivative of HotStuff (same family as Ethereum’s Casper)
- Single-slot finality (~1s) — faster than Ethereum’s 12+ second slots
- Leader-based with validator rotation
- Probabilistic finality at 1 block, economic finality within 2 blocks
Key design:
- Pipelined consensus: multiple consensus rounds run concurrently
- Separate execution from consensus: transactions can be executed while the next block’s consensus is running
- Deferred execution: transactions committed to the chain first, executed in the background → allows pipeline optimization
MonadDB (Custom Storage Layer)
One of Monad’s less-discussed but critical innovations:
Problem: Ethereum clients store state in an MPT (Merkle Patricia Trie) — a balanced tree structure. Reading/writing state requires O(log N) disk seeks per storage access, which becomes a bottleneck at high TPS.
MonadDB:
Monad built a custom database with:
- Async I/O: Storage reads and writes happen asynchronously (not blocking the execution pipeline)
- Columnar storage: State organized for parallel access patterns
- SSD-optimized layout: Takes advantage of modern NVMe SSD parallel access
Result: At 10,000 TPS, disk I/O would be the bottleneck; MonadDB removes this bottleneck through systems-level optimization.
MON Token
Network: Monad L1
Utility:
- Gas fees (pay for transactions in MON)
- Validator staking (secure the network)
- Governance (on-chain parameter changes)
Status (as of 2025): Monad was in public testnet phase with mainnet launch anticipated. MON token distribution details in development — airdrop to testnet participants and community expected.
Monad vs. Solana vs. Ethereum
| Property | Monad | Solana | Ethereum L1 |
|---|---|---|---|
| EVM compat | 100% | No | Yes (native) |
| TPS (claimed) | 10,000+ | 65,000+ | ~15 |
| Finality | ~1-2s | 400ms | 12-13s + |
| Execution | Parallel EVM | Parallel (SVM) | Sequential EVM |
| DB | MonadDB (custom) | Accounts DB | LevelDB/LMDB |
| Decentralization | TBD (mainnet) | High | Very high |
Monad’s positioning:
- For EVM developers: “Get Solana-like performance without leaving the EVM”
- For ETH L1: An alternative high-performance L1 (competitor)
- For Solana: EVM compatibility is the differentiator (Solana requires SVM rewrite)
Developer Experience
100% EVM Compatibility:
- Deploy any Solidity contract to Monad without modification
- MetaMask, WalletConnect work out of the box
- Hardhat, Foundry, Truffle tooling all compatible
- Same RPC interface as Ethereum (eth_ methods)
What changes for developers:
- Gas mechanics slightly different (execution pipeline)
- Must be aware of parallel execution (no guaranteed ordering of unrelated transactions)
- State access patterns matter more (conflicts cause re-execution)
How to Participate in Monad
Testnet participation:
- Get testnet MON from the Monad faucet
- Deploy contracts or use testnet dApps
- Active participation often qualifies for mainnet airdrop consideration
When mainnet launches:
- Get MON to pay gas fees via (after exchange listings)
- Connect MetaMask to Monad network (standard EVM RPC setup)
- Use DeFi protocols deploying on Monad (EVM protocols can port immediately)
- Store MON: (standard EVM hardware wallet support)
Social Media Sentiment
Monad is one of the most anticipated new blockchain launches in the 2024-2025 cycle. The team’s technical credibility is well-established — Keone Hon (CEO) and Eunice Giarta (COO) come from Jane Street and other quantitative trading backgrounds, and the team includes former EVM engineers with deep execution layer expertise. The key technical claims (10,000 TPS via parallel EVM) are theoretically plausible based on published research, but performance claims for unreleased chains should be verified at mainnet. The main skeptical argument: Solana already provides high throughput for non-EVM workloads, and Ethereum’s rollup ecosystem provides EVM scalability — Monad needs to capture users who specifically want both high performance AND EVM compatibility, which is a narrower market than its marketing suggests. The testnet has been well-received and technically impressive; mainnet execution is the key unknown.
Last updated: 2026-04
Related Terms
Sources
Bronshtein, A., Guo, X., Levi, G., & Levit, V. (2022). Parallel Transaction Execution for Scalable Blockchain Performance. arXiv:2210.01898.
Yin, M., Malkhi, D., Reiter, M., Gueta, G. G., & Abraham, I. (2019). HotStuff: BFT Consensus with Linearity and Responsiveness. Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing.
Bernstein, P. A., & Goodman, N. (1981). Concurrency Control in Distributed Database Systems. ACM Computing Surveys, 13(2), 185–221.
Buterin, V. (2020). Why Sharding is Great: Demystifying the Technical Properties. Vitalik’s Blog.
Harris, T., Marr, S., & Steffan, J. G. (2005). Transactional Memory: An Overview. IEEE Micro.