The era of parallel execution has arrived, an overview of the MEV landscape on Monad

Author: APRIORI

Compiled by: Shenchao TechFlow

Introduction

In the process of enhancing blockchain performance for large-scale applications, Monad effectively optimizes the Ethereum Virtual Machine (EVM) model through a series of underlying optimizations, such as asynchronous I/O, optimized Patricia Trie, lazy execution, and optimistic concurrency control. These improvements address execution bottlenecks and inefficient state access issues on platforms like Ethereum without sacrificing decentralization.

This article explores the possibility of building a robust Miner Extractable Value Auction infrastructure (MEVA) on Monad, drawing valuable lessons from Flashbots on Ethereum and the Jito Network on Solana.

We would like to emphasize several key points:

1. MEV is an inherent characteristic of any blockchain network. A robust MEVA infrastructure is crucial for avoiding negative externalities and incentive misalignment during the block production process.

2. The design of MEVA is closely related to the underlying mechanisms of the blockchain, particularly the consensus execution phase. Future improvements will depend on the evolution of these factors and the network's performance under different pressures.

3. Historical trends in block production on Ethereum and Solana can provide references for MEVA design on Monad.

4. On a high-performance, lazy-execution blockchain like Monad, MEVA may require probabilistic block construction and search strategies similar to high-frequency trading to meet time constraints.

By exploring these issues, we hope to provide insights for designing a MEVA infrastructure that adapts to Monad's unique architecture and performance requirements.

MEVA Background in Ethereum

MEVA under Ethereum's Consensus Execution Phase

In Ethereum, consensus requires execution first. When nodes agree on a block, they agree not only on the list of transactions in the block but also on the Merkle root summarizing the state after the block's execution. Therefore, proposers must execute all transactions in the block before propagating the proposal. Similarly, validating nodes must also execute these transactions before voting.

Figure 1: Builder workflow in MEV-Boost's Proposer-Builder Separation (PBS)

Figure 1 illustrates the typical builder workflow in MEV-Boost's Proposer-Builder Separation (PBS). After completing the block construction, the builder submits it to the relayer, which then forwards the block to the Execution Layer (EL) client for simulation and validity checks.

Since execution is a prerequisite for consensus, when a builder constructs a block, they need to forward the block to the Execution Layer (EL) client and simulate the block to check its validity. In addition to its necessary role in the consensus-execution phase, the simulation phase also benefits builders and searchers.

From the builder's perspective: By simulating each transaction, builders can accurately estimate the value of the block to themselves and the validators. They can also attempt to reorder transactions to minimize rollbacks and maximize gas fees or base tips extracted from the mempool and bundled transactions. Accurate estimations enable them to bid higher to validators.

From the searcher's perspective: Since builders filter out potentially rollable bundled transactions before they are on-chain, searchers can ensure the execution of their strategies, increasing certainty. Additionally, searchers can access the latest block state. When the Consensus Layer (CL) propagates a new block, searchers can use the state of that block as a starting point for constructing profitable bundled transactions. Moreover, there are indications that builders are now providing more off-protocol transactions or features, allowing searchers to access information about the upcoming block state to incorporate rollback strategies into the soon-to-be-mined block.

However, the development of PBS has led to increased centralization in block construction, similar to the situation where companies compete for dedicated microwave network channels to prioritize the execution of arbitrage strategies in traditional trading.

Product Iteration as the Network Matures

We now explore how MEVA has evolved alongside Ethereum, as shown in Figure 2.

Figure 2: Chronological view of MEVA evolution with Ethereum network development

Priority Gas Auction (PGA) Era

As shown in Figure 3, searchers identify profitable MEV opportunities and submit smart contract transactions to the public mempool. This public visibility leads to on-chain public bidding and uniform price auctions, where even failed transactions incur gas fees.

During this period, competitive and costly unstructured MEV activities emerged, such as transactions with the same (account, announcement) pairs and increasing bids, leading to network congestion or consensus instability.

Figure 3: Simple Priority Gas Auction illustration

Flashbots and EIP-1559

To address these issues, Flashbots introduced relayers as intermediaries between searchers and block producers (miners in the PoW era). This move transformed the MEV market from a public bidding uniform price auction to a sealed bidding process. As shown in Figure 4, relayers help prevent bidding escalation in the public mempool and establish a more orderly and secure block production process.

The fee structure of EIP-1559 also plays a role here. It simplifies bidding through base fees but does not resolve the transaction ordering issue within blocks, which is still driven by priority fees. In fact, many searchers previously bid directly to miners via coinbase transfers. They ended up with more complaints about coinbase fees as they could no longer submit 0-gas bundled transactions.

Figure 4: MEVA with relayers

Proposer-Builder Separation (PBS)

After Ethereum completed its merge and transitioned to Proof of Stake (PoS), Proposer-Builder Separation (PBS) was implemented to further optimize the role separation in the block production pipeline. As mentioned earlier, relayers now act as intermediaries between block builders and proposers, responsible for ensuring data availability and block validity. Since proposers can connect to multiple builders for different private transactions, builders must compete by paying fees to proposers. This dynamic is illustrated in Figure 5.

Figure 5: MEVA in the PBS era

Centralization Risks

Despite these historic advancements, it is essential to highlight the growing centralization risks in the builder market. Over the past year, the top 9 builders have consistently accounted for over 50% of the market share, indicating a high level of market concentration, as shown in Figure 6. The current state of concentration is even more pronounced, with the top three builders covering over 90% of blocks.

Figure 6: Market share of builders, indicating the high concentration prevalent in the builder market (Image source)

Jito on Solana

System Architecture of Jito

As the standard MEVA on Solana, Jito was created to address the high spam transaction behavior resulting from low transaction costs on Solana. As long as the fees for failed transactions (approximately 0.000005 SOL) do not exceed expected profits, spam transaction behavior is effectively incentivized.

According to a report from Jito Labs in 2022, over 96% of arbitrage and liquidation attempts failed that year, with over 50% of transactions in blocks being MEV-related. The report also noted that liquidation bots sent millions of duplicate packets to the network just to complete a few thousand successful liquidations, resulting in a failure rate exceeding 99%.

Figure 7: Jito's MEVA on Solana

The severity of MEV externality issues on Solana prompted Jito to develop a MEVA layer aimed at bringing order and certainty to the block production process. Let’s review the original MEVA architecture proposed by Jito, as shown in Figure 7.

Jito has the following components:

Relayer - Acts as an agent to receive transactions and forward them to the block engine (or MEVA supply chain) and validators.

Block Engine - Receives transactions from the relayer, coordinates searchers, accepts bundles, executes bundle simulations, and forwards the best transactions and bundles to validators for processing. Notably, Jito conducts partial block auctions to include bundles, rather than full block auctions, historically processing over 80% of bundles within two slots.

Pseudo Mempool - Creates an operational time window of approximately 200 milliseconds through the Jito-Solana client, triggering discrete auctions of order flow. Jito closed this mempool on March 9, 2024.

Design Choices of Jito

Let’s explore the specific components of Jito's system design and consider how these design choices stem from Solana's block production process.

Jito only supports partial block auctions rather than full block construction, likely due to Solana's multithreaded execution model lacking global scheduling. Specifically, Figure 8 shows parallel thread execution of transactions, with each thread maintaining its own queue of transactions waiting to be executed. Transactions are randomly assigned to threads and locally sorted by priority fees and time. In the absence of global sorting at the scheduler's end (prior to the 1.18.x update), Solana's transactions essentially experience non-determinism due to scheduler jitter. Thus, in MEVA, searchers or validators cannot reliably ascertain the current state.

Figure 8: Multithreaded execution model of Solana clients. Note that the bundling phase of MEVA is attached as an independent thread in the multithreaded queue.

From an engineering perspective, running Jito's block engine as an additional thread in parallel aligns well with Solana's multithreaded architecture. While bundling auctions ensure priority fee-based sorting within the Jito block engine thread, it cannot guarantee that bundles are always globally prioritized over user transactions.

To address this issue, Jito pre-allocates a portion of block space for the bundling thread, ensuring that bundles have space in the block. Although uncertainty still exists, this approach increases the probability of successful strategy execution. It also incentivizes searchers to participate in auctions rather than sending spam transactions to the network. By reserving block space for bundles, Jito achieves a balance between facilitating orderly auctions and mitigating the chaotic effects of transaction spam.

Removal of Pseudo Mempool

The widespread adoption of Jito has yielded positive results in alleviating spam issues on Solana. According to research from p2p and the data shown in Figure 9, relative block production rates significantly improved after the adoption of the Jito client. This indicates that transaction processing has become more efficient due to the optimized block engine introduced by Jito in 2023.

Figure 9: Evidence of Jito effectively mitigating spam issues on Solana. This figure is excerpted from a study conducted by the p2p team.

While significant progress has been made, many challenges remain. Since Jito bundles only partially fill blocks, MEV-induced transactions can still bypass Jito's auction channels. Some evidence can be found in the Dune Dashboard shown in Figure 10, which indicates that since 2024, the network still averages over 50% transaction failures due to bot spam transactions.

Figure 10: Dune Dashboard showing bot spam transaction activity on Solana since May 2022 (see Dune for details)

On March 9, 2024, Jito decided to suspend its flagship mempool. This decision was made due to the growth of memecoin transactions and the subsequent surge in sandwich attacks (where searchers place transactions before and after target transactions), ultimately affecting user experience. Similar to the private order flow channels for MEVA on Ethereum, closing the public mempool may promote the growth of private order flows through collaboration with front-end services such as wallet providers and Telegram bots. Searchers may establish partnerships directly with validators to gain rights for priority execution, inclusion, or exclusion.

In fact, Figure 11 shows the hourly sandwich bot profits of the largest private mempool searcher after the mempool closure.

Largest private mempool searcher:

3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81

(Note: Sandwich bots are a common frontrunning attack tool primarily used to profit from blockchain transactions.)

Figure 11: Hourly sandwich bot profits of searcher "3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81" using a private mempool

Jito's decision to close the mempool indicates the team's commitment to addressing fundamental issues within the Solana ecosystem. In addition to iterating on MEVA or adjusting Solana's gas fee mechanisms, Jito also helps the protocol reduce attack risks through UI product design choices (such as limiting default slippage parameters). Whether by making spam transactions more costly through fee structure adjustments or modifying communication protocols, Jito's infrastructure will continue to play a key role in maintaining the health and stability of the Solana network.

MEVA Design on Monad

Lazy Execution and Its Impact on MEVA

Unlike Ethereum, where agreeing on a block requires a list of transactions (with ordering) and a Merkle root summarizing all post-execution states, Monad decouples prior execution from consensus. The node protocol only needs to resolve the official ordering issue. As shown in Figure 12, each node independently executes the transactions in block N when it begins consensus on block N+1. This arrangement allows for a gas budget corresponding to the full block time, as execution only needs to keep pace with consensus. Since there is no need for a leader node to compute the factual state root, execution can utilize the entire consensus period to process the next block.

Figure 12: Comparison of Monad's lazy execution with Ethereum's execution-consensus phase. Also illustrates the operational time window from the perspective of MEVA design.

We define the operational time window as the timeframe that allows MEVA to complete a block construction proposal on Monad, which is feasible and profitable compared to the default block construction method. The lazy execution model has two direct consequences:

1. When MEVA constructs the Nth block within the operational time window, validators simultaneously reach consensus on the transaction list for the Nth block while attempting to complete the execution of the N-1 block. Therefore, in the Nth operational time window, the potentially available state may still be in the N-2 block. This means that under this lazy execution architecture, there is no guarantee that relayers or builders have the "latest state." Thus, it is impossible to simulate against the latest block before the next block is generated, leading to uncertainty.

2. Given Monad's 1-second block time, the operational time window for MEVA is extremely limited. This means that builders may not have enough time to sequentially simulate the transactions and bundles of a complete block, as is typically done on Ethereum. Many variables can affect the time required for transaction simulation on the EVM. However, assuming that simulating a transaction takes 10^1 to 10^2 microseconds (a rough estimate), and Monad aims for 10^4 transactions per second, simulating a complete block within the operational time window may take about 1 second. Considering Monad's 1-second block time, it would be challenging for builders or relayers to complete multiple full block simulations to optimize block construction.

Probabilistic Builder and Searcher Strategies

Given these constraints, completing a full block simulation within the operational time window and simulating against the latest state is impractical. As builders now lack both time and the latest state to understand the exact hints of each transaction, they must infer searcher hints based on the likelihood of transaction rollbacks, relying on reputation or, preferably, simulating against the N-2 state. This makes block valuation less certain.

Due to the lack of theoretical guarantees against transaction rollbacks, once validators accept the block constructed by builders, searchers face greater execution uncertainty. This contrasts with Ethereum, where searchers compete in dedicated private order flow channels to builders with relatively certain strategy execution. In this relatively probabilistic setting on Monad, searchers now face higher risks of bundle rollbacks, leading to more uncertain execution PnL profiles. This is similar to high-frequency traders who execute trades based on probabilistic signals, achieving slightly higher expected returns over time.

Figure 13: A conceptual spectrum diagram illustrating different MEVA design paradigms, categorized by the degree of proposal block checking or simulation.

As shown in Figure 13, the extent to which builders conduct pre-bundling/block checks creates a spectrum of uncertainty in pricing or valuing the proposed block. At one end is the Ethereum-style PBS model, which features accurate pricing, where builders must simulate transactions in the proposed block using the Execution Layer (EL) client. They must navigate a wide array of combinations in the submitted bundles. At the other end is the optimistic builder model, with asynchronous block checks. In this model, builders bypass any time required for simulation within the operational time window and redeem hints shown to validators or relayers by depositing collateral (which may be slashed). The probabilistic checks or partial simulation methods proposed here on Monad lie in the middle, increasing the likelihood of searchers successfully executing strategies despite some uncertainty.

For example, a market maker on an on-chain order book DEX might preemptively move their position through MEVA upon discovering significant one-sided price movements to avoid adverse selection. This probabilistic strategy allows them to act quickly, balancing risk and reward in a dynamic trading environment, even without the latest state information.

Conclusion

MEVA plays a crucial role in optimizing block production, mitigating external impacts, and enhancing system stability. As the MEVA framework continues to evolve, with implementations like Jito on Solana and various implementations on Ethereum, it significantly contributes to solving scalability issues and aligning the incentive mechanisms of network participants.

Monad is an emerging network with great potential, offering the community a unique opportunity to design the optimal MEVA. Given Monad's unique execution-consensus separation mechanism, we sincerely invite researchers, developers, and validators to collaborate and share insights. This collaboration will help create a robust and efficient block production process, supporting Monad in realizing its prospects as a high-throughput blockchain network.