Source: ASXN; Translated by: Jinse Finance xiaozou
1. Introduction
Monad is a high-performance optimized EVM-compatible L1 with 10,000 TPS (1 billion gas per second), 500 millisecond block frequency, and 1 second finality. The chain was built from scratch to solve some of the problems faced by the EVM, specifically:
*The EVM processes transactions sequentially, causing bottlenecks during periods of high network activity, thus extending transaction times, especially during times of network congestion.
* Low throughput, only 12-15 TPS, and long block time of 12 seconds.
*EVM requires gas fees to be paid for each transaction, and the fees fluctuate greatly, especially when network demand is high, gas fees can become extremely expensive.
2. Why extend EVM?
Monad provides full EVM bytecode and Ethereum RPC API compatibility, allowing developers and users to integrate without changing their existing workflows.
A common question is why to scale the EVM when there are better performing alternatives like the SVM. The SVM offers faster block times, lower fees, and higher throughput than most EVM implementations. However, the EVM has some key advantages that stem from two main factors: the large amount of capital in the EVM ecosystem and the extensive developer resources.
(1) Capital base
The EVM has a large amount of capital, with Ethereum’s TVL approaching $52 billion and Solana at $7 billion. L2s such as Arbitrum and Base each hold around $2.5-3 billion in TVL. Monad and other EVM-compatible chains can benefit from the large capital base on EVM chains through canonical bridges and third-party bridges that integrate with minimal friction. This large EVM capital base is relatively active and can attract users and developers because:
* Users prefer liquidity and high transaction volume.
Developers seeking high transaction volumes, fees, and visibility into their applications.
(2) Developer Resources
Ethereum’s tools and applied cryptography research are integrated directly into Monad, while achieving higher throughput and scale through:
*application
* Developer tools (Hardhat, Apeworx, Foundry)
*Wallets (Rabby, Metamask, Phantom)
*Analytics/Index (Etherscan, Dune)
Electric Capital’s Developer Report shows that as of July 2024, Ethereum has 2,788 full-time developers, Base has 889, and Polygon has 834. Solana ranks seventh with 664 developers, behind Polkadot, Arbitrum, and Cosmos. While some argue that the total number of developers in crypto is still small and should be largely ignored (resources should be focused on bringing in external talent), it is clear that there is a large amount of EVM talent in the “small” pool of crypto developers. Furthermore, given that most of the talent works in the EVM and most of the tooling is in the EVM, new developers will most likely have to or choose to learn and develop in the EVM. As Keone mentioned in an interview, developers have the choice to:
* Build portable applications for EVM, enabling multi-chain deployment, but with limited throughput and high fees
*Build high-performance and low-cost applications in a specific ecosystem such as Solana, Aptos, or Sui.
Monad aims to combine these two approaches. Since most tools and resources are tailored for the EVM, applications developed within its ecosystem can be ported seamlessly. Combined with its relative performance and efficiency - thanks to Monad's optimizations - the EVM is clearly a strong competitive barrier.
In addition to developers, users also prefer familiar workflows. Through tools such as Rabby, MetaMask, and Etherscan, the EVM workflow has become standard. These mature platforms facilitate the integration of bridges and protocols. In addition, basic applications (AMMs, money markets, bridges) can be launched immediately. These basic primitives are crucial for the sustainability of the chain as well as novel applications.
3. Extending the EVM
There are two main ways to extend the EVM:
* Move execution off-chain: offload execution to other virtual machines through rollups, using a modular architecture.
* Improve performance: Improve the performance of the base chain EVM through consensus optimization and increased block size and gas limit.
(1) Rollup and modular architecture
Vitalik introduced rollups in October 2020 as Ethereum's main scaling solution, in line with the modular blockchain principle. As a result, Ethereum's scaling roadmap delegates execution to rollups, which are off-chain virtual machines that leverage Ethereum's security. Rollups excel in execution, with higher throughput, lower latency, and lower transaction costs. They have shorter iterative development cycles than Ethereum - updates that take years on Ethereum may only take months on rollups due to lower potential costs and losses.
Rollups can run with centralized sorters while maintaining safe escape hatches that help them bypass certain decentralization requirements. It is important to note that many rollups (including Arbitrum, Base, and OP Mainnet) are still in their infancy (Phase 0 or Phase 1). In Phase 1 rollups, fraud proof submission is limited to whitelisted participants, and upgrades that are not related to on-chain provable bugs must provide users with at least a 30-day exit window. Phase 0 rollups provide users with less than 7 days to exit in the event of downtime or censorship by the permissioned operator.
In Ethereum, the typical transaction size is 156 bytes, and the signature contains the most data. Rollup allows multiple transactions to be bundled together, reducing the overall transaction size and optimizing gas costs. In short, rollup achieves efficiency by bundling multiple transactions into batches and submitting them to the Ethereum mainnet. This reduces on-chain data processing but increases the complexity of the ecosystem because rollup connections require new infrastructure requirements. In addition, rollup itself also adopts a modular architecture, moving execution to L3 to address basic rollup throughput limitations, especially for gaming applications.
Although rollups theoretically eliminate bridging and liquidity fragmentation by becoming a full-fledged chain on top of Ethereum, current implementations have yet to become fully “full” chains. The three largest rollups by TVL — Arbitrum, OP Mainnet, and Base — maintain different ecosystems and user groups, each excelling in certain areas but failing to provide a comprehensive solution.
In short, users have to visit multiple different chains to get the same experience as using a single chain like Solana. The lack of a unified shared state in the Ethereum ecosystem (one of the core propositions of blockchain) greatly limits on-chain use cases - especially because competing rollups cannot easily understand each other's state due to the fragmentation of liquidity and state. State fragmentation also brings additional demand for bridges and cross-chain messaging protocols that can connect rollups and state together, but with some trade-offs. A single blockchain does not face these fragmentation issues because there is a single ledger recording the state.
Each rollup takes a different approach in terms of optimization and focusing on its specific area. Optimism introduces additional modularity through Superchain, and therefore relies on other L2s to build with its stack and compete for fees. Arbitrum focuses primarily on DeFi, especially perpetual and options exchanges, while expanding to L3 through Xai and Sanko. New high-performance rollups such as MegaETH and Base have emerged with higher throughput capabilities and aim to provide a single large chain. MegaETH has not yet launched, and Base is impressive in terms of implementation, but still lacks in some areas, including derivatives trading (options and perpetuals) and the DePIN field.
(2) Early L2 expansion
Optimism and Arbitrum
The first generation of L2 provides improved execution compared to Ethereum, but lags behind newer hyper-optimized solutions. For example, Arbitrum processes 37.5 transactions per second (“TPS”), and Optimism Mainnet is 11 TPS. In comparison, Base is about 80 TPS, MegaETH targets 100,000 TPS, BNB Chain is 65.1 TPS, and Monad targets 10,000 TPS.
While the Arbitrum and Optimism Mainnets cannot support extremely high-throughput applications like fully on-chain order books, they scale through additional chain layers — L3 for Arbitrum and Superchain for Optimism — and centralized sorters.
Arbitrum’s focus on L3s for gaming, Xai and Proof of Play, demonstrates this approach. They are built on the Arbitrum Orbit stack and settled on Arbitrum using AnyTrust data availability. Xai achieved 67.5 TPS, while Proof of Play Apex achieved 12.2 TPS and Proof of Play Boss was 10 TPS. These L3s introduce additional trust assumptions through Arbitrum settlement rather than Ethereum mainnet, while facing the potential challenges of a less decentralized data availability layer. Optimism’s L2s — Base, Blast, and the upcoming Unichain — maintain stronger security through Ethereum settlement and blob data availability.
Both networks prioritize horizontal scaling. Optimism provides L2 infrastructure, chain deployment support, and shared bridges with interoperability capabilities through the OP Stack. Arbitrum offloads specific use cases to L3, especially gaming applications, where additional trust assumptions carry lower capital risk than financial applications.
(3) Optimizing chain and EVM performance
Alternative scaling approaches focus on performing optimizations or target tradeoffs to increase throughput and TPS by scaling vertically rather than horizontally. Base, MegaETH, Avalanche, and BNB Chain embody this strategy.
Base Base announced plans to reach 1 Ggas/s by gradually increasing the gas target. In September, they raised the target to 11 Mgas/s and increased the gas limit to 33 Mgas. The initial block processed 258 transactions and maintained about 70 TPS for five hours. By December 18, the gas target reached 20 Mgas/s, the block time was 2 seconds, and each block supported 40M gas. In comparison, Arbitrum is 7 Mgas/s and OP Mainnet is 2.5 MGas/s.
Base has emerged as a competitor to Solana and other high-throughput chains. As of today, Base has surpassed other L2s in terms of activity, as evidenced by:
*As of January 2025, its monthly fees reach $15.6 million - 7.5 times that of Arbitrum and 23 times that of OP Mainnet.
*As of January 2025, its cumulative transaction volume reached 329.7 million, which is 6 times that of Arbitrum (57.9 million) and 14 times that of OP Mainnet (24.5 million). Note: Transaction volumes can be manipulated and may be misleading.
The Base team is focused on providing a more unified experience by optimizing for speed, throughput, and low fees, as opposed to the modular approach of Arbitrum and Optimism. Users have shown a preference for a more unified experience, as shown by Base’s activity and revenue numbers. Additionally, Coinbase’s support and distribution have helped.
MegaETH
MegaETH is an EVM-compatible L2. At its core, it processes transactions through a hybrid architecture using dedicated sorter nodes. MegaETH uniquely separates performance and security tasks in its architecture, combined with a new state management system that replaces the traditional Merkle Patricia Trie to minimize disk I/O operations.
The system processes 100,000 transactions per second with sub-millisecond latency while maintaining full EVM compatibility and the ability to handle terabytes of state data. MegaETH uses EigenDA for data availability, distributing functionality across three specialized node types:
* Sorter: A high-performance single node (100 cores, 1-4TB RAM) manages transaction ordering and execution, keeping state in RAM for fast access. It generates blocks at approximately 10 millisecond intervals, witnesses block validation, and tracks state differences as blockchain state changes. The Sorter achieves high performance through parallel EVM execution and priority support, with no consensus overhead during normal operation.
* Provers: These lightweight nodes (1 core, 0.5GB RAM) compute cryptographic proofs that verify block contents. They validate blocks asynchronously and out of order, employ stateless validation, scale horizontally, and generate proofs for full node validation. The system supports zero-knowledge and fraud proofs.
* Full nodes: Running on moderate hardware (4-8 cores, 16GB RAM), full nodes bridge the prover, sorter, and EigenDA. They process compressed state differences over a peer-to-peer network, apply differences without re-executing transactions, validate blocks using proofs generated by provers, maintain state roots using an optimized Merkle Patricia Trie, and support 19x compressed sync.
(4) Issues with Rollups
Monads are fundamentally different from rollups and their inherent tradeoffs. Most rollups today rely on a centralized single sorter, although shared and decentralized sorting solutions are being developed. Centralization of sorters and proposers introduces operational vulnerabilities. Control by a single entity can lead to liveness issues and reduced censorship resistance. Despite the existence of escape hatches, centralized sorters can still manipulate transaction speed or order to extract MEV. They also create a single point of failure, and if the sorter fails, the entire L2 network will not function properly.
In addition to centralization risks, rollups bring additional trust assumptions and tradeoffs, particularly around interoperability:
Users encounter multiple non-interchangeable forms of the same asset. The three major rollups — Arbitrum, Optimism, and Base — maintain different ecosystems, use cases, and user groups. Users must bridge between rollups to access specific applications, or protocols must launch on multiple rollups, bootstrapping liquidity and users while managing the complexity and security risks that come with bridge integrations.
Additional interoperability issues stem from technical limitations (limited transactions per second at the base L2 layer), which has led to further modularization and pushing execution to L3, especially for gaming. Centralization poses additional challenges.
We have seen optimized rollups (like Base and MegaETH) improve performance and optimize the EVM through centralized sorters, as transactions are ordered and executed without consensus requirements. This allows for reduced block times and increased block sizes by using a single high-capacity machine, but also creates a single point of failure and potential censorship vector.
Monad takes a different approach, requiring more powerful hardware than the Ethereum mainnet. While Ethereum L1 validators require a 2-core CPU, 4-8 GB of RAM, and 25 Mbps bandwidth, Monad requires a 16-core CPU, 32 GB of RAM, a 2 TB SSD, and 100 Mbps bandwidth. While Monad’s specs appear massive compared to Ethereum, the latter has kept node requirements minimal in order to accommodate independent validators, though the hardware Monad recommends is accessible today.
In addition to hardware specifications, Monad is redesigning its software stack to achieve greater decentralization than L2s through node distribution. While L2s prioritizes hardware enhancements for a single sorter, sacrificing decentralization, Monad has modified its software stack to improve performance while maintaining node distribution, while increasing hardware requirements.
(5) Monad's EVM Early Ethereum forks mainly modified the consensus mechanism, such as Avalanche, while maintaining the Go Ethereum client for execution. Although Ethereum clients exist in multiple programming languages, they essentially copy the original design. Monad differs by rebuilding the consensus and execution components from first principles and from scratch.
Monad prioritizes maximizing hardware utilization. In contrast, Ethereum mainnet’s emphasis on supporting independent stakers limits performance optimizations because it requires compatibility with weaker hardware. This limitation affects improvements in block size, throughput, and block time—ultimately, the network is only as fast as its slowest validator.
Similar to Solana’s approach, Monad employs more powerful hardware to increase bandwidth and reduce latency. This strategy leverages all available cores, memory, and SSDs to increase speed. Given the decreasing cost of powerful hardware, it is more practical to optimize for high-performance devices than to limit the capabilities of low-quality devices.
The current Geth client executes via a single-threaded sequential process. Blocks contain linearly ordered transactions that transform the previous state into a new state. This state includes all accounts, smart contracts, and stored data. State changes occur as transactions are processed and verified, affecting account balances, smart contracts, token ownership, and other data.
Transactions usually run independently. The blockchain state consists of different accounts, each of which independently conducts transactions, and these transactions usually do not interact with each other. Based on this idea, Monad uses optimistic parallel execution.
Optimistic parallel execution attempts to run transactions in parallel to gain potential performance benefits - initially assuming there will be no conflicts. Multiple transactions are run simultaneously, initially without concern about their potential conflicts or dependencies. After execution, the system checks whether the parallel transactions actually conflict with each other and corrects them if conflicts exist.
4. Parallel execution of protocol mechanisms
(1) Parallel execution of Solana
When users think of parallel execution, they usually think of Solana and SVM, which allows for parallel execution of transactions via access lists. Transactions on Solana consist of a header, an account key (the address of the instructions included in the transaction), a block hash (the hash included when the transaction was created), instructions, and an array of signatures for all accounts required based on the transaction instructions.
The instruction for each transaction consists of a program address, which specifies the program to be called; accounts, which lists all the accounts that the instruction reads and writes; and instruction data, which specifies the instruction handler (the function that processes the instruction) and any additional data required by the instruction handler.
Each instruction specifies three key details for each account involved:
* The public address of the account
*Whether the account needs to sign the transaction
*Whether the instruction will modify the account data
Solana uses these specified lists of accounts to identify transaction conflicts ahead of time. Since all accounts are specified in the directive, including details on whether they are writable, transactions can be processed in parallel if they do not include any accounts writing to the same state.
The process is as follows:
*Solana checks the list of accounts provided in each transaction
* Identify which accounts will be written to
* Check for conflicts between transactions (are they writing to the same account)
* Transactions that do not write to any of the same accounts are processed in parallel, while transactions with conflicting write operations are processed sequentially
A similar mechanism exists in the EVM, but is not used because Ethereum does not require access lists. Users pay more upfront because they include this access list in their transaction. Transactions become larger and more costly, but users receive a discount for specifying an access list.
(2) Monad’s parallel execution is different from Solana. Monad uses optimistic parallel execution. Instead of identifying which transactions affect which accounts and parallelizing based on that (Solana’s approach), Monad assumes that transactions can be executed in parallel without interfering with each other.
When the Monad runs transactions in parallel, it assumes that the transactions start at the same point. When multiple transactions are run in parallel, the chain generates pending results for each transaction. In this context, pending results refer to the bookkeeping that the chain does to track the inputs and outputs of the transaction and how they affect the state. These pending results are submitted in the original order of the transactions (i.e. based on priority fees).
To commit a pending result, the inputs are checked to make sure they are still valid - if the inputs to the pending result have changed/modified (i.e. if transactions cannot work in parallel because they access the same account and would affect each other, then the transactions are processed sequentially (later transactions are re-executed)). Re-execution is done only to maintain correctness. The consequence is not that transactions take longer, but that more computation is required.
In the first execution iteration, the Monad has already checked for conflicts or dependencies on other transactions. Therefore, when the transaction is executed for the second time (after the first optimistic parallel execution failed), all previous transactions in the block have already been executed, ensuring that the second attempt will succeed. Even if all transactions in the Monad depend on each other, they are just executed sequentially, producing the same results as another non-parallelized EVM.
The monad keeps track of the read and write sets of each transaction during execution, then merges the results in the original transaction order. If a transaction running in parallel uses outdated data (because an earlier transaction updated something it read), the monad detects this when it merges, and re-executes the transaction with the correct updated state. This ensures that the final result is the same as the sequential execution of the blocks, maintaining Ethereum-compatible semantics. This re-execution has minimal overhead - expensive steps like signature verification or data loading do not need to be repeated from scratch, and often the required state is already cached in memory from the first run.
Example:
In the initial state, user A has 100 USDC, user B has 0 USDC, and user C has 300 USDC.
There are three transactions:
*Transaction 1: User A sends 10 USDC to User B
*Transaction 2: User A sends 10 USDC to User C
Serial execution process Using serial execution is simpler, but less efficient. Each transaction is executed in sequence:
* User A first sends 10 USDC to User B.
*User A then sends 10 USDC to User C.
In the final state, for serial execution (non-Monad):
*User A has 80 USDC left (sent 10 USDC to B and C respectively).
* User B has 10 USDC.
* User C has 310 USDC.
Parallel execution process
With parallel execution, the process is more complex, but more efficient. Multiple transactions are processed simultaneously, rather than waiting for each transaction to complete sequentially. While transactions run in parallel, the system keeps track of their inputs and outputs. During the sequential "merge" phase, if a transaction is detected to have used an input that was changed by an earlier transaction, the transaction is re-executed using the updated state.
The step-by-step process is as follows:
*User A initially has 100 USDC, User B initially has 0 USDC, and User C initially has 300 USDC.
* With optimistic parallel execution, multiple transactions run simultaneously, initially assuming that they all start working from the same initial state.
* In this case, Transaction 1 and Transaction 2 are executed in parallel. Both transactions read User A's initial state as 100 USDC.
*Transaction 1 plans to send 10 USDC from user A to user B, reducing user A's balance to 90 and increasing user B's balance to 10.
*At the same time, transaction 2 also reads that user A’s initial balance is 100, and plans to transfer 10 USDC to user C, trying to reduce user A’s balance to 90 and increase user C’s balance to 310.
* When the chain verifies these transactions in order, transaction 1 is checked first. Since its input values match the initial state, it is submitted, user A's balance becomes 90, and user B receives 10 USDC.
*When the chain checks transaction 2, it finds a problem: Transaction 2 was planned with the assumption that user A has 100 USDC, but user A now only has 90 USDC. Due to this mismatch, transaction 2 must be re-executed.
* During the re-execution, transaction 2 reads the updated state of user A as 90 USDC. Then 10 USDC is successfully transferred from user A to user C, leaving user A with 80 USDC and user C's balance increases to 310 USDC.
*In this case, since user A has enough funds to make both transfers, both transactions are successfully completed.
In the final state, for parallel execution (Monad):
The results are the same:
*User A has 80 USDC left (sent 10 USDC to B and C respectively).
* User B has 10 USDC.
* User C has 310 USDC.
* User D has 100 USDC minus the NFT cost and minted NFTs.
5. Delayed execution
When a blockchain verifies and reaches consensus on transactions, nodes around the world must communicate with each other. This global communication encounters physical limitations because data takes time to travel between distant points such as Tokyo and New York.
Most blockchains use a sequential approach where execution is tightly coupled to consensus. In these systems, execution is a prerequisite to consensus — nodes must execute transactions before finalizing a block.
Here are the details:
Execution precedes consensus so that blocks are finalized before starting the next block. Nodes first agree on the order of transactions, then agree on the Merkle root of the state summary after executing the transactions. The leader must execute all transactions in the proposed block before sharing it, and validating nodes must execute each transaction before reaching consensus. This process limits execution time because it happens twice while allowing multiple rounds of global communication to reach consensus. For example, Ethereum has a 12 second block time, while actual execution may take only 100 milliseconds (actual execution time varies greatly depending on block complexity and gas usage).
Some systems try to optimize this by interleaving execution, which breaks tasks into smaller segments that alternate between processes. While processing is still sequential, with a single task executing at any given moment, the rapid switching creates significant concurrency. However, this approach still fundamentally limits throughput, as execution and consensus are still interdependent.
Monads address the limitations of sequential and interleaved execution by decoupling execution from consensus. Nodes reach consensus on the order of transactions without executing them - that is, two parallel processes occur:
*Nodes execute transactions that have reached consensus.
*Consensus continues with the next block without waiting for execution to complete, and execution follows consensus.
This structure enables the system to commit a large amount of work through consensus before execution begins, allowing Monad to handle larger blocks and more transactions by allocating extra time. In addition, it enables each process to use the entire block time independently - consensus can use the entire block time for global communication, execution can use the entire block time for calculation, and the two processes do not block each other.
To maintain safety and state consistency while decoupling execution from consensus, Monad uses a delayed Merkle root, where each block contains a Merkle root of the state N blocks ago (N is expected to be 10 at launch, and is set to 3 in the current testnet), allowing nodes to verify that they have reached the same state after execution. The delayed Merkle root allows the chain to verify state consistency: the delayed Merkle root acts as a checkpoint - N blocks later, nodes must prove that they have reached the same state root, otherwise they executed something wrong. Additionally, if a node's execution produces a different state root, it will detect this after N blocks and can roll back and re-execute to reach consensus. This helps eliminate the risk of nodes behaving maliciously. The resulting delayed Merkle root can be used by light clients to verify the state - despite the delay of N blocks.
Since execution is delayed and occurs after consensus, one potential problem is that malicious actors (or regular users accidentally) keep submitting transactions that will eventually fail due to insufficient funds. For example, if a user with a total balance of 10 MON submits 5 transactions, each transaction individually attempts to send 10 MON, which may cause problems. However, if not checked, these transactions may pass consensus but fail during execution. To address this issue and reduce potential spam, nodes implement protection measures during consensus by tracking in-flight transactions.
For each account, the node checks the account balance N blocks ago (because that is the most recent verified correct state). Then, for each pending transaction "in transit" for that account (passed consensus but not yet executed), they subtract the value being transferred (e.g. sending 1 MON) and the maximum possible gas cost, calculated as gas_limit multiplied by maxFeePerGas.
This process creates a running "available balance" that is used to validate new transactions during consensus. If the value of a new transaction plus the maximum gas cost exceeds this available balance, the transaction is rejected during consensus, rather than letting it pass and then failing during execution.
Since Monad's consensus proceeds with a slightly delayed view of state (due to execution decoupling), it implements a protection against including transactions that the sender cannot ultimately pay. In Monad, each account has an available or "reserve" balance during consensus. As transactions are added to proposed blocks, the protocol deducts the maximum possible cost of the transaction (gas * max fee + value transferred) from this available balance. If an account's available balance would drop below zero, further transactions from that account will not be included in blocks.
This mechanism (sometimes described as charging a shipping cost to the reserve balance) ensures that only transactions that can be spent are proposed, thus preventing DoS attacks where attackers attempt to flood the network with useless transactions with 0 funds. Once blocks are finalized and executed, balances are adjusted accordingly, but during the consensus phase, Monad nodes always perform an up-to-date check of the spendable balances of pending transactions.
6. MonadBFT
(1) Consensus
HotStuff
MonadBFT is a low-latency, high-throughput Byzantine Fault Tolerant ("BFT") consensus mechanism derived from HotStuff consensus.
Hotstuff was created by VMresearch and further improved by LibraBFT from the Meta former blockchain team. It implements linear view changes and responsiveness, meaning it can efficiently rotate leaders while doing so at actual network speeds rather than predetermined timeouts. HotStuff also uses threshold signatures for efficiency and implements pipelining, allowing new blocks to be proposed before the previous block is committed.
However, these benefits come with certain trade-offs: the additional rounds result in higher latency and the possibility of forks during the pipeline compared to the classic two-round BFT protocol. Despite these trade-offs, HotStuff's design makes it more suitable for large-scale blockchain implementations, although it results in slower finality than two-round BFT protocols.
Here is HotStuff’s explanation:
*When transactions occur, they are sent to a validator of the network, called a Leader.
*The Leader compiles these transactions into a block and broadcasts it to other validators in the network.
*The validator then validates the block by voting, and the vote is sent to the Leader of the next block.
* To protect against malicious actors or communication failures, blocks must go through multiple rounds of voting before their state is finalized.
*Depending on the specific implementation, a block can only be committed after successfully passing two or three rounds, ensuring the robustness and security of the consensus.
Although MonadBFT is derived from HotStuff, it introduces unique modifications and new concepts that can be further explored.
Transaction Agreement
MonadBFT is specifically designed to implement transaction protocols under partially synchronous conditions — meaning that the chain can reach consensus even during asynchronous periods when message delays are unpredictable.
Eventually, the network stabilizes and delivers the message (within a known timeframe). These asynchronous periods arise from the architecture of the Monad, as the chain must implement certain mechanisms to increase speed, throughput, and parallel execution.
Dual wheel system
Unlike HotStuff, which originally implemented a three-wheel system, MonadBFT uses a two-wheel system similar to Jolteon, DiemBFT, and Fast HotStuff.
A round consists of the following basic steps:
*In each round, the Leader broadcasts a new block and the certificate (QC or TC) of the previous round.
*Each validator reviews the block and sends the signature vote to the Leader of the next round
*When enough votes (2/3) are collected, a QC is formed. QC means that the network's validators have reached a consensus to append a block, while TC means that the consensus round has failed and needs to be restarted.
"Dual round" specifically refers to the submission rules. To submit a block in a dual round system:
* Round 1: Initial block is proposed and gets QC
*Round 2: The next block is proposed and gets QC If these two rounds are completed consecutively, the first block can be committed.
DiemBFT used a three-round system in the past, but upgraded to a two-round system. The two-round system enables faster commits by reducing the number of communication rounds. It allows for lower latency because transactions can be committed faster because they do not need to wait for additional confirmations.
Specific process
The consensus process in MonadBFT is as follows:
*Leader operation and block proposal: The process begins when the designated leader of the current round initiates consensus. The leader creates and broadcasts a new block containing user transactions, as well as a proof of the previous round of consensus in the form of QC or TC. This creates a pipeline structure where each block proposal carries the certification of the previous block.
* Validator Operation: Once a validator receives a block proposal from a Leader, they begin the validation process. Each validator scrutinizes the validity of the block according to the protocol rules. Valid blocks receive a signed YES vote sent to the next round of Leaders. However, if a validator does not receive a valid block within the expected time, they initiate a timeout procedure by broadcasting a signed timeout message including the highest QC they know. This dual-path approach ensures that the protocol can make progress even if a block proposal fails.
* Certificate creation: The protocol uses two types of certificates to track consensus progress. When a leader collects YES votes from two-thirds of validators, a QC is created, proving broad consensus on a block. Alternatively, if two-thirds of validators time out without receiving a valid proposal, they create a TC, allowing the protocol to safely proceed to the next round. Both certificate types serve as key proof of validator participation.
* Block Finalization (Two-Chain Commitment Rule): MonadBFT uses a two-chain commitment rule for block finalization. When validators observe that two adjacent certified blocks from consecutive rounds form a chain B ← QC ← B' ← QC', they can safely commit block B and all its ancestors. This two-chain approach provides safety and liveness while maintaining performance.
Local memory pool architecture
Monad uses a local memory pool architecture instead of the traditional global memory pool. In most blockchains, pending transactions are broadcast to all nodes, which can be slow (many network hops) and bandwidth intensive due to redundant transmissions. In contrast, in Monad, each validator maintains its own memory pool; transactions are forwarded by RPC nodes directly to the next few scheduled leaders (currently the next N=3 leaders) for inclusion.
This takes advantage of the known leader schedule (avoiding unnecessary broadcasts to non-leaders) and ensures that new transactions reach block proposers quickly. Upcoming leaders perform validation checks and add transactions to their local memory pools, so when the validator takes its turn to lead, it already has relevant transactions queued. This design reduces propagation delays and saves bandwidth, achieving higher throughput.
(2) RaptorCast
Monad uses a specialized multicast protocol called RaptorCast to quickly propagate blocks from leaders to all validators. Rather than sending full blocks serially to each peer or relying on simple broadcasts, leaders use an erasure coding scheme (per RFC 5053) to break up block proposal data into encoded chunks and distribute these chunks efficiently via a two-level relay tree. In practice, leaders send different chunks to a set of first-tier validator nodes, which then forward the chunks to others so that every validator eventually receives enough chunks to reconstruct a full block. The distribution of chunks is stake-weighted (each validator is responsible for forwarding a portion of the chunks) to ensure load balancing. In this way, the entire network's upload capacity is used to quickly propagate blocks, minimizing latency while still tolerating Byzantine (malicious or faulty) nodes that may drop messages. RaptorCast enables Monad to achieve fast, reliable block propagation even with large blocks, which is critical for high throughput.
BLS and ECDSA signatures
QC and TC are implemented using BLS and ECDSA signatures, which are two different types of digital signature schemes used in cryptography.
Monad uses a combination of BLS signatures and ECDSA signatures to improve security and scalability. BLS signatures support signature aggregation, while ECDSA signatures are generally faster to verify.
ECDSA Signature
Although signatures cannot be aggregated, ECDSA signatures are faster. Monad uses them for QC and TC.
QC Creation:
*Leader proposes a block
* Validators agree by signing a vote
* When the required voting parts are collected, they can be combined into a QC.
*QC proves that the validator agrees with the block
TC Create:
*If the validator does not receive a valid block within the scheduled time
* It broadcasts a signed timeout message to peers
* If enough timeout messages are collected, they form a TC.
*TC allows you to enter the next round even if you fail the current round
BLS Signature Monad uses BLS signatures for multi-signatures, as it allows signatures to be gradually aggregated into a single signature. This is mainly used for aggregatable message types such as voting and timeouts.
Votes are messages sent by validators when they agree with a proposed block. They contain a signature indicating approval of the block and are used to construct QCs.
Timeouts are messages sent by a validator when it has not received a valid block within the expected time. They contain a signed message with the current round number, the highest QC of the validator, and a signature of these values. They are used to construct TC.
Both voting and timeouts can use BLS signature combination/aggregation to save space and improve efficiency. As mentioned before, BLS is relatively slower than ECDSA signatures.
Monad uses a combination of ECDSA and BLS to benefit from the efficiency of both. Although the BLS scheme is slower, it allows signature aggregation and is therefore particularly useful for voting and timeouts, while ECDSA is faster but does not allow aggregation.
7. Monad MEV
In simple terms, MEV refers to the value that parties can extract by reordering, including, or excluding transactions in a block. MEV is often categorized as "good" MEV, which is MEV that keeps the market healthy and efficient (e.g., liquidation, arbitrage), or "bad" MEV (e.g., sandwich attacks).
Monad's delayed execution affects how MEV works on the chain. On Ethereum, execution is a prerequisite for consensus - meaning that when nodes agree on a block, they agree on the list and order of transactions and the resulting state. Before proposing a new block, the Leader must execute all transactions and calculate the final state, allowing searchers and block builders to reliably simulate transactions against the latest confirmed state.
In contrast, on Monad, consensus and execution are decoupled. Nodes only need to agree on the order of transactions in the most recent block, while consensus on the state may be reached later. This means that validators may be working based on state data from earlier blocks, which makes them unable to simulate against the latest blocks. In addition to the complexity brought by the lack of confirmed state information, Monad's 1 second block time may make it challenging for builders to simulate blocks to optimize the built blocks.
Access to the latest state data is necessary for searchers because it provides them with confirmed asset prices, liquidity pool balances, and smart contract status on the DEX, etc. - which enables them to identify potential arbitrage opportunities and discover liquidation events. If the latest state data is not confirmed, searchers cannot simulate blocks before the next block is generated and face the risk of transaction rollback before the state is confirmed.
Given the delays in Monad blocks, the MEV landscape may be similar to Solana.
For context, on Solana, blocks are produced in a slot every ~400ms, but the time between a block being produced and “rooted” (finalized) is much longer — typically 2000-4000ms. This delay comes not from block production itself, but from the time it takes to gather enough stake-weighted votes for a block to be finalized.
During this voting period, the network continued to process new blocks in parallel. Since transaction fees were very low and new blocks could be processed in parallel, this created a “race condition” where seekers would send a large number of transactions hoping to be included — which caused many transactions to be rolled back. For example, during December, 1.3 billion of the 3.16 billion non-voting transactions on Solana (about 41%) were rolled back. Jito’s Buffalu highlighted as early as 2023 that “98% of arbitrage trades on Solana fail.”
Due to similar block delay effects on Monad, where confirmation status information for the latest block does not exist and new blocks are processed in parallel, searchers may be incentivized to send a large number of transactions - which may fail because transactions are rolled back and the confirmed state is different from the state they used for simulation.
8. MonadDB
Monad chose to build a custom database, called MonadDB, for storing and accessing blockchain data. A common problem with chain scalability is state growth - that is, the size of the data exceeds the capacity of the node. Paradigm published a short research paper on state growth in April, highlighting the difference between state growth, history growth, and state access, which they believe are often conflated, although they are different concepts that affect node hardware performance.
As they point out:
*State growth refers to the accumulation of new accounts (account balances and nonce) and contracts (contract bytecode and storage). Nodes need to have sufficient storage space and memory capacity to accommodate state growth.
*Historical growth refers to the accumulation of new blocks and new transactions. Nodes need to have enough bandwidth to share block data and enough storage space to store block data.
*State access refers to the read and write operations used to build and verify blocks.
As mentioned before, both state growth and history growth affect the scalability of the chain because the data size may exceed the capacity of the nodes. Nodes need to store data in permanent storage to build, verify, and distribute blocks. In addition, nodes must cache in memory to sync with the chain. Both state growth and history growth, as well as optimized state access, require the chain to adapt, otherwise it will limit the block size and operations per block. The more data in the block, the more read and write operations per block, the larger the history growth and state growth, and the greater the need for efficient state access.
While state and history growth are important factors in scalability, they are not the primary concern, especially from a disk performance perspective. MonadDB focuses on managing state growth through logarithmic database scaling. As a result, increasing the state by 16 times only requires one additional disk access per state read. Regarding history growth, when a chain has high performance, there will eventually be too much data to store locally. Other high-throughput chains, such as Solana, rely on cloud hosting like Google BigTable to store historical data, which, while effective, sacrifices decentralization due to reliance on a centralized party. Monad will initially implement a similar solution while eventually working towards a decentralized solution.
(1) Status access
In addition to state growth and history growth, one of the key implementations of MonadDB is to optimize the read and write operations of each block (i.e. improve state access).
Ethereum uses Merkle Patricia Trie ("MPT") to store state. MPT borrows the properties of PATRICIA (a data retrieval algorithm) to achieve more efficient data retrieval.
Merkle Tree A Merkle Tree ("MT") is a set of hash values that ultimately reduce to a single root hash value, called a Merkle root. The hash value of data is a fixed-size cryptographic representation of the original data. A Merkle root is created by repeatedly hashing pairs of data until a single hash value (the Merkle root) remains. The usefulness of a Merkle root is that it allows verification of leaf nodes (i.e., the single hash value that is repeatedly hashed to create the root) without having to verify each leaf node individually.
This is much more efficient than verifying each transaction individually, especially in large systems with many transactions in each block. It creates verifiable relationships between the various pieces of data and allows for "Merkle proofs", where a transaction can be proven to be included in a block by providing the transaction and the intermediate hashes needed to reconstruct the root (log(n) hashes instead of n transactions).
Merkle Patricia Trie
Merkle trees are well suited to the needs of Bitcoin, where transactions are static and the main requirement is to prove that the transaction exists in a block. However, they are less suitable for Ethereum's use case, where stored data needs to be retrieved and updated (e.g., account balances and nonces, adding new accounts, updating keys in storage), not just verified to exist, which is why Ethereum uses the Merkle Patricia Trie to store state.
Merkle Patricia Trie ("MPT") is a modified Merkle tree used to store and verify key-value pairs in the state database. While MT takes a series of data (such as transactions) and hashes them only in pairs, MPT organizes data like a dictionary - each data (value) has a specific address (key) to store it. This key-value storage is implemented through Patricia Trie.
Ethereum uses different types of keys to access different types of Tries, depending on the data that needs to be retrieved. Ethereum uses 4 types of Tries:
*World State Trie: Contains the mapping between addresses and account states.
*Account Storage Trie: stores data related to smart contracts.
*Transaction Trie: Contains all transactions included in the block.
* Receipt Trie: Stores transaction receipts with transaction execution information.
*Trie accesses values by different types of keys, which enables the chain to perform a variety of functions, including checking balances, verifying the existence of contract code, or looking up specific account data.
Note: Ethereum plans to move away from MPT and toward Verkle trees in order to “upgrade Ethereum nodes so that they can stop storing large amounts of state data without losing the ability to validate blocks.”
Monad DB: Patricia Trie
Unlike Ethereum, MonadDb implements the Patricia Trie data structure natively on disk and in memory.
As mentioned earlier, MPT is a combination of the Merkle tree data structure and the Patricia Trie for key-value retrieval: Two different data structures are integrated/combined: the Patricia Trie is used to store, retrieve, and update key-value pairs, and the Merkle tree is used for verification. This results in additional overhead because it adds complexity to hash-based node references, and Merkle requires additional storage for hash values on each node.
The Patricia Trie-based data structure enables MonadDB to:
* Has a simpler structure: each node does not have a Merkle hash, the node relationship does not have a hash reference, it only stores keys and values directly. * Direct path compression: Reduce the number of lookups required to reach the data. * Local key-value storage: Although MPT integrates Patricia Trie into a separate key-value storage system, the native function of Patricia Trie is key-value storage, which allows better optimization. * No data structure conversion required: No conversion between Trie format and database format is required. These make MonadDB have relatively low computational overhead, require less storage space, achieve faster operations (whether retrieval or update), and maintain a simpler implementation.
Asynchronous I/O
Transactions are executed in parallel on a Monad. This means that the storage needs to accommodate multiple transactions accessing the state in parallel, i.e. the database should have asynchronous I/O.
MonadDB supports modern asynchronous I/O implementations, which allows it to handle multiple operations without creating a large number of threads - unlike other traditional key-value databases such as LMDB, which must create multiple threads to handle multiple disk operations - there is less overhead since there are fewer threads to manage.
A simple example of input/output processing in the cryptographic world is:
*Input: read state to check account balance before transaction *Output: write/update account balance after transfer Asynchronous I/O allows input/output processing (i.e. reading and writing storage) even if the previous I/O operation has not yet completed. This is necessary for Monad because multiple transactions are being executed in parallel. Therefore, one transaction needs to access storage to read or write data while another transaction is still reading or writing data from storage. In synchronous I/O, the program executes one I/O operation at a time in sequence. When an I/O operation is requested in synchronous I/O processing, the transaction waits until the previous operation is completed. For example:
* Sync I/O: The chain writes tx/block #1 to state/storage. The chain waits for it to complete. Then the chain can write tx/block #2. * Async I/O: The chain writes tx/block #1, tx/block #2, and tx/block #3 to state/storage at the same time. They complete independently.
(2) StateSync
Monad has a StateSync mechanism that helps new or lagging nodes catch up efficiently without having to replay every transaction since genesis. StateSync allows a node (a "client") to request a recent state snapshot to a target block from its peers (a "server"). The state data is split into chunks (e.g. parts of account state and recent block headers), which are distributed across multiple validator peers to share the load. Each server responds with the requested state chunk (leveraging metadata in MonadDb to quickly retrieve the required Trie nodes), and the client assembles these chunks to build the state for the target block. Since the chain is constantly growing, once sync is complete, the node either performs another round of StateSync closer to the tip, or replays a small number of recent blocks to fully catch up. This chunked state sync greatly speeds up node bootstrapping and recovery, ensuring that even as Monad's state grows, new validators can join or restart and fully sync without hours of delay.
9. Ecosystem
(1) Ecosystem efforts
The Monad team is focused on developing a strong and robust ecosystem for its chain. Over the past few years, the competition between L1 and L2 has shifted from a primary focus on performance to user-facing applications and developer tools. It is no longer enough for chains to simply boast high TPS, low latency, and low fees; they must now provide an ecosystem that encompasses a variety of different applications, from DePIN to AI, from DeFi to consumer. The reason this is becoming increasingly important is the proliferation of high-performance L1s and low-cost L1s, including Solana, Sui, Aptos, and Hyperliquid, all of which provide high-performance, low-cost development environments and block space. One advantage Monad has here is that it uses the EVM.
As mentioned earlier, Monad provides full EVM bytecode and Ethereum RPC API compatibility, enabling developers and users to integrate without changing their existing workflows. A common criticism of those working to extend the EVM is that there are more efficient alternatives available, such as SVM and MoveVM. However, if a team can maximize EVM performance through software and hardware improvements while keeping fees low, then extending the EVM makes sense because of the existing network effects, developer tooling, and easily accessible capital base.
Monad's full EVM bytecode compatibility enables applications and protocol instances to be ported from other standard EVMs, such as ETH mainnet, Arbitrum, and OP Stack, without code changes. This compatibility has both advantages and disadvantages. The main advantage is that existing teams can easily port their applications to Monad. In addition, developers creating new applications for Monad can take advantage of the rich resources, infrastructure, and tools developed for the EVM, such as wallets such as Hardhat, Apeworx, Foundry, Rabby, and Phantom, as well as analysis and indexing products such as Etherscan, Parsec, and Dune.
One downside of easily portable protocols and applications is that they can lead to lazy, inefficient forks and applications being launched on a chain. While it is important for a chain to have many available products, the majority should be unique applications that are not accessible on other chains. For example, while most chains will need Uniswap V2 style or pooled liquidity based AMMs, a chain must also attract a new class of protocols and applications to attract users. Existing EVM tooling and developer resources help enable novel and unique applications. Additionally, the Monad team implements various programs, from accelerators to venture capital competitions, to encourage novel protocols and applications on the chain.
(2) Ecosystem Overview
Monad offers high throughput and minimal transaction fees, making it well suited for specific types of applications such as CLOBs, Decrypt, and consumer applications that are well suited to benefit from a high-speed, low-cost environment.
Before diving into the specific categories that fit into monads, it may be helpful to understand why an application would choose to launch on L1 rather than on L2 or launching its own L1/L2/application chain.
On the one hand, launching your own L1, L2, or app chain can be beneficial because you don't have to deal with the noisy neighbor problem. Your block space is completely owned by you, so you can avoid congestion during high activity and maintain consistent performance regardless of the overall network load. This is especially important for CLOB and consumer applications. During congestion, traders may be unable to execute transactions, and everyday users who expect Web2 performance may find it impossible to use applications due to slowdowns and performance degradation.
On the other hand, launching your own L1 or appchain requires bootstrapping a set of validators and, more importantly, incentivizing users to bridge liquidity and capital to use your chain. While Hyperliquid successfully launched its own L1 and attracted users, there are many teams that have failed to do the same. Building on-chain enables teams to benefit from network effects, provides secondary and tertiary liquidity effects, and enables them to integrate with other DeFi protocols and applications. It also eliminates the need to focus on infrastructure and building a stack - which is difficult to do efficiently and effectively. It is important to note that building an application or protocol is very different from building an L1 or appchain.
Launching your own L2 can alleviate some of these pressures, especially the technical issues associated with bootstrapping a validator set and building infrastructure, as there are click-to-deploy rollup-as-a-service providers. However, these L2s are generally not particularly efficient (most still do not have TPS to support consumer applications or CLOBs) and often have risks associated with centralization (most are still in Phase 0). In addition, they still face disadvantages related to liquidity and activity fragmentation, such as low activity and user operations per second (UOPS).
*CLOB
Fully on-chain order books have become a benchmark for the DEX industry. While this was previously impossible due to network-level limitations and bottlenecks, the recent surge in high-throughput and low-cost environments means that on-chain CLOBs are now possible. Previously, high gas fees (making it expensive to place orders on-chain), network congestion (due to the necessary trading volume), and latency issues made trading based entirely on on-chain order books impractical. Additionally, the algorithms used in CLOB matching engines consume a lot of computing resources, making it challenging and costly to implement them on-chain.
A model based entirely on an on-chain order book combines the advantages of a traditional order book with full transparency of trade execution and matching. All orders, trades, and the matching engine itself exist on the blockchain, ensuring full visibility at every level of the trading process. This approach offers several key advantages. First, it provides full transparency, as all trades are recorded on-chain, not just trade settlements, allowing for full auditability.
Second, it mitigates MEV by reducing the chances of front-running at both the order placement and cancellation levels, making the system more fair and resistant to manipulation.
Finally, it removes trust assumptions and reduces manipulation risk because the entire order book and matching process exists on-chain, eliminating the need to trust off-chain operators or protocol insiders and making it more difficult for any party to manipulate order matching or execution. In contrast, off-chain order books compromise on these aspects, potentially allowing for insider front-running and order book operator manipulation due to a lack of full transparency into the order placement and matching process.
On-chain order books have advantages over off-chain order books, but they also have significant advantages over AMMs:
While AMMs typically incur losses for liquidity providers due to LVR and IL, suffer price slippage, and are susceptible to arbitrage exploitation of outdated prices, on-chain order books eliminate liquidity providers’ exposure to IL or LVR. Their real-time order matching prevents outdated pricing, reducing arbitrage opportunities through efficient price discovery. However, AMMs do have advantages for riskier, less liquid assets, as they enable permissionless trading and asset listings, enabling price discovery for new and illiquid tokens. It is important to note that, as mentioned earlier, LVR is less problematic than some alternatives given the shorter block times on Monad.
Projects worth noting
