The Era of Parallel Execution Has Arrived: A Look at the MEV Landscape on Monad
TechFlow Selected TechFlow Selected
The Era of Parallel Execution Has Arrived: A Look at the MEV Landscape on Monad
This article explores the possibility of building a robust Miner Extractable Value Auction (MEVA) infrastructure on Monad.
Navigating Web3 tides with focused insightsAuthor: APRIORI ⌘
Translation: TechFlow
Introduction
In advancing blockchain performance for mass adoption, Monad has effectively optimized the Ethereum Virtual Machine (EVM) model through a series of low-level improvements—such as asynchronous I/O, an optimized Patricia Trie, deferred execution, and optimistic concurrency control. These enhancements address execution bottlenecks and inefficient state access on platforms like Ethereum, without sacrificing decentralization.
This article explores the potential of building a robust Miner Extractable Value Auction (MEVA) infrastructure on Monad, drawing insights from valuable experiences with Flashbots on Ethereum and Jito Network on Solana.
We emphasize several key points:
-
MEV is an inherent characteristic of any blockchain network. A strong MEVA infrastructure is crucial to avoid negative externalities and misaligned incentives during block production.
-
MEVA design is closely tied to the underlying mechanisms of a blockchain, especially the consensus-execution phase. Future improvements will depend on the evolution of these factors and the network's behavior under various stress conditions.
-
Historical trends in block production on Ethereum and Solana can inform MEVA design on Monad.
-
On high-performance, deferred-execution blockchains like Monad, MEVA may require probabilistic block-building and search strategies akin to high-frequency trading, to cope with tight time constraints.
By examining these issues, we aim to provide insights into designing a MEVA infrastructure tailored to Monad’s unique architecture and performance requirements.
MEVA Background in Ethereum
MEVA Under Ethereum’s Consensus-Execution Paradigm
In Ethereum, consensus requires prior execution. When nodes agree on a block, they are agreeing not only on the list of transactions (with ordering) but also on the resulting Merkle root summarizing all post-state changes. Therefore, proposers must execute all transactions in a block before broadcasting their proposal. Similarly, validators must execute these transactions before voting.
Figure 1: Builder workflow in proposer-builder separation (PBS) within MEV-Boost
Figure 1 illustrates the typical builder workflow in MEV-Boost’s proposer-builder separation (PBS). After completing block construction, builders submit the block to a relay, which forwards it to the Execution Layer (EL) client for simulation and validity checks.
Since execution is a prerequisite for consensus, when builders construct a block, they must forward it to the EL client and simulate the block to verify its validity. Beyond its essential role in the consensus-execution pipeline, this simulation phase benefits both builders and searchers.
From the builder’s perspective: By simulating each transaction, builders can accurately estimate the value of the block to themselves and to validators. They can experiment with reordering transactions to minimize rollbacks and maximize gas fees or base tips extracted from the mempool and bundles. Precise estimation allows them to bid higher prices to validators.
From the searcher’s perspective: Since builders filter out potentially rollback-prone bundles before inclusion, searchers gain greater certainty in strategy execution. Additionally, searchers gain access to the latest block state. When the Consensus Layer (CL) broadcasts a new block, searchers can use its state as a starting point for constructing profitable bundles. Moreover, there are indications that builders now offer additional off-protocol transactions or features, enabling searchers to access information about the soon-to-be-built block state, allowing them to insert frontrunning strategies into upcoming blocks.
However, the development of PBS has led to increasing centralization in block building, similar to how firms in traditional finance compete over dedicated microwave network channels to gain priority in executing arbitrage strategies.
Products Evolve as the Network Matures
Now we examine how MEVA has evolved alongside Ethereum’s development, as shown in Figure 2.
Figure 2: Chronological view of MEVA evolution with Ethereum network development
Priority Gas Auction (PGA) Era
As illustrated in Figure 3, searchers identify profitable MEV opportunities and submit smart contract transactions to the public mempool. This public visibility leads to open on-chain bidding and first-price auctions, where even failed transactions incur gas fees.
This period saw intense and costly unstructured MEV activity, such as repeated transactions with identical (account, nonce) pairs and escalating bids, causing network congestion or consensus instability.
Figure 3: Simple illustration of a priority gas auction
Flashbots and EIP-1559
To address these issues, Flashbots introduced relays as intermediary auction houses between searchers and block producers (miners in the PoW era). This shifted the MEV market from open first-price auctions to sealed-bid auctions. As shown in Figure 4, relays help prevent bidding wars in the public mempool and establish a more orderly and secure block production process.
The fee structure introduced by EIP-1559 also played a role. It simplified bidding via base fees, though it did not resolve transaction ordering within blocks, which remains driven by priority fees for MEV. In practice, many searchers previously bid directly to miners via coinbase transfers. They eventually voiced more complaints about coinbase fees, as they could no longer submit zero-gas bundles.
Figure 4: MEVA with relays
Proposer-Builder Separation (PBS)
After Ethereum completed The Merge and transitioned to proof-of-stake (PoS), Proposer-Builder Separation (PBS) was implemented to further optimize role separation in the block production pipeline. As mentioned earlier, relays now act as intermediaries between block builders and proposers, 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
Risks of Centralization
Despite these historical advances, the growing risk of centralization in the builder market must be emphasized. Over the past year, the top nine builders have consistently accounted for over 50% of market share, indicating high market concentration, as shown in Figure 6. The current state is even more pronounced, with the top three builders covering over 90% of blocks.
Figure 6: Builders' market share, showing prevalent high concentration in the builder market (source: link)
Jito on Solana
Jito’s System Architecture
As the standard MEVA on Solana, Jito was created to address the high volume of spam transactions incentivized by Solana’s low transaction costs. Spamming behavior is effectively encouraged as long as the cost of a failed transaction (~0.000005 SOL) is less than the expected profit.
According to a 2022 report by Jito Labs, over 96% of arbitrage and liquidation attempts failed that year, and blocks contained over 50% MEV-related transactions. The report also noted that liquidation bots sent millions of duplicate packets to achieve only a few thousand successful liquidations, resulting in failure rates above 99%.
Figure 7: Jito’s MEVA on Solana
The severity of MEV externalities on Solana prompted Jito to develop an MEVA layer aimed at bringing order and determinism to block production. Let us revisit Jito’s original MEVA architecture as shown in Figure 7.
Jito consists of the following components:
Relay – Acts as a proxy to receive transactions and forward them to the block engine (or MEVA supply chain) and validators.
Block Engine – Receives transactions from the relay, coordinates searchers, accepts bundles, performs bundle simulations, and forwards optimal transactions and bundles to validators for processing. Notably, Jito conducts partial block auctions for bundle inclusion rather than full-block auctions, historically handling over 80% of bundles within two slots.
Pseudo-mempool – Created via the Jito-Solana client, establishing an approximately 200ms operational time window that discretizes order flow into auctions. Jito shut down this mempool on March 9, 2024.
Jito’s Design Choices
Let us explore the specific components of Jito’s system design and consider how these choices stem from Solana’s block production process.
Jito supports only partial block auctions rather than full-block construction, likely due to Solana’s multi-threaded execution model lacking global scheduling. Specifically, Figure 8 shows parallel threads executing transactions, each maintaining its own queue of pending transactions. Transactions are randomly assigned to threads and locally ordered by priority fee and time. Without global ordering at the scheduler level (prior to the 1.18.x update), Solana’s transactions inherently experience non-determinism due to scheduler jitter. Consequently, in MEVA, searchers or validators cannot reliably determine the current state.
Figure 8: Solana client’s multi-threaded execution model. Note that the MEVA bundling stage is attached as a separate thread alongside the multi-threaded queues.
From an engineering standpoint, running Jito’s block engine as an additional parallel thread aligns well with Solana’s multi-threaded architecture. Although bundle auctions ensure priority-fee-based ordering within the Jito block engine thread, there is no guarantee that bundles will always be globally prioritized over user transactions.
To mitigate this, Jito pre-allocates a portion of block space to the bundle thread, guaranteeing space for bundles in blocks. While uncertainty remains, this approach increases the probability of successful strategy execution. It also incentivizes searchers to participate in auctions rather than spam the network. By reserving block space for bundles, Jito balances facilitating orderly auctions with mitigating the chaotic effects of transaction spam.
Removing the Pseudo-Mempool
Jito’s widespread adoption has yielded positive results in alleviating spam issues on Solana. According to research by p2p and data shown in Figure 9, relative block production efficiency significantly improved after adopting the Jito client. This indicates that transaction processing became more efficient due to Jito’s optimized block engine introduced in 2023.
Figure 9: Evidence that Jito effectively mitigated spam problems on Solana. Chart taken from a study conducted by the p2p team.
Despite significant progress, many challenges remain. Because Jito bundles only partially fill blocks, MEV-driven transactions can still bypass the Jito auction channel. Partial evidence can be found in Figure 10’s Dune Dashboard, showing that since 2024, the network still averages over 50% failed transactions due to bot spam.
Figure 10: Dune Dashboard showing bot spam activity on Solana since May 2022 (see Dune)
On March 9, 2024, Jito decided to suspend its flagship mempool. This decision followed rising memecoin transaction volumes and a surge in sandwich attacks (where searchers place transactions before and after a target transaction), ultimately degrading user experience. Similar to private order flow channels in Ethereum’s MEVA, closing the public mempool may encourage growth in private order flows through partnerships with front-end services such as wallet providers and Telegram bots. Searchers may directly collaborate with validators to gain rights to priority execution, inclusion, or exclusion.
Indeed, Figure 11 shows the hourly sandwich bot profits of the largest private-mempool searcher after the mempool shutdown.
Top private-mempool searcher:
3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81
(Note: Sandwich bots are common frontrunning attack tools primarily used to extract profit from blockchain transactions.)
Figure 11: Hourly sandwich bot profits of searcher “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81” using private mempool
Jito’s decision to shut down the mempool reflects the team’s commitment to addressing fundamental issues within the Solana ecosystem. Beyond iterating on MEVA or adjusting Solana’s gas fee mechanism, Jito helps protocols reduce attack risks through UI product design choices—such as limiting default slippage parameters. Whether through fee adjustments that make spam more expensive or modifications to communication protocols, Jito’s infrastructure will continue to play a critical role in maintaining the health and stability of the Solana network.
MEVA Design on Monad
Deferred Execution and Its Impact on MEVA
Unlike Ethereum, where agreeing on a block requires both the transaction list (with ordering) and the Merkle root summarizing all post-state changes, Monad decouples prior execution from consensus. The node protocol only needs to resolve official ordering. As shown in Figure 12, each node independently executes transactions in block N when beginning consensus on block N+1. This arrangement allows for a gas budget corresponding to a full block time, as execution only needs to keep pace with consensus. Since leader nodes do not need to compute the canonical state root, execution can utilize the entire consensus period to process the next block.
Figure 12: Comparison of Monad’s deferred execution vs. Ethereum’s consensus-execution phases. Operational time windows are also shown from an MEVA design perspective.
We define the operational time window as the timeframe available for MEVA to complete a block construction proposal on Monad that is viable and profitable compared to default block construction methods. Deferred execution has two direct consequences:
-
When MEVA builds for block N within the operational time window, validators are simultaneously reaching consensus on the transaction list for block N while attempting to complete execution of block N−1. Thus, during the operational time window for block N, the potentially available state may still be from block N−2. This means that under this deferred execution architecture, there is no guarantee that relays or builders have the “latest state.” Therefore, simulating against the latest block before the next block is generated becomes impossible, introducing uncertainty.
-
Given Monad’s 1-second block time, MEVA’s operational time window is extremely limited. This implies that builders may not have sufficient time to sequentially simulate all transactions and bundles in a full block, as is typically done on Ethereum. Many variables affect simulation time on EVMs. However, assuming a single transaction simulation takes 10¹ to 10² microseconds (a rough estimate), and considering Monad’s target of 10⁴ transactions per second, simulating a full block alone within the operational window could take approximately one second. Given Monad’s 1-second block time, it would be challenging for builders or relays to perform multiple full-block simulations to optimize block construction.
Probabilistic Builder and Searcher Strategies
Given these constraints, completing full-block simulations within the operational time window and targeting the latest state is impractical. Since builders now lack both time and up-to-date state to know the exact outcome of each transaction, they must infer searcher signals based on rollback probabilities—relying on reputation or possibly 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 a block built by a builder, searchers face greater execution uncertainty. This contrasts with Ethereum, where searchers compete over dedicated private order flow channels to builders, achieving relatively deterministic strategy execution. In this probabilistic setting on Monad, searchers now face higher bundle rollback risks, leading to more uncertain PnL profiles. This resembles high-frequency traders who execute trades based on probabilistic signals, achieving slightly positive expected returns over time.
Figure 13: A conceptual spectrum illustrating different MEVA design paradigms, classified by the extent of proposed block checking or simulation
As shown in Figure 13, the degree of pre-checking/bundle validation by builders creates a spectrum of uncertainty in pricing or valuing proposed blocks. At one end is the Ethereum-style PBS model with accurate pricing, where builders must simulate transactions in the proposed block using Execution Layer (EL) clients and navigate extensive combinations within submitted bundles. At the other end is the optimistic builder model [16], featuring asynchronous block checking. In this model, builders bypass time-consuming simulations within the operational window and instead stake collateral (which may be slashed) to back signals shown to validators or relays. The probabilistic checking or partial simulation method proposed here for Monad lies in between—increasing the likelihood of successful strategy execution despite some uncertainty.
For example, a market maker on a DEX with an on-chain order book might use MEVA to preemptively adjust positions upon detecting major one-sided price movements, avoiding adverse selection. Such probabilistic strategies allow them to act quickly, even without the latest state information, balancing risk and reward in dynamic trading environments.
Conclusion
MEVA plays a critical role in optimizing block production, mitigating externalities, and enhancing system stability. As MEVA frameworks continue evolving—such as Jito on Solana and various implementations on Ethereum—they greatly contribute to solving scalability challenges and better aligning incentives among network participants.
Monad is a promising network at an early stage, offering the community a unique opportunity to design an optimal MEVA. Given Monad’s distinctive separation of execution and consensus, we invite researchers, developers, and validators to collaborate and share insights. Such collaboration will help create a robust and efficient block production process, enabling Monad to fulfill its potential as a high-throughput blockchain network.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@aprMEV
