The era of parallel execution is here, at a glance at the MEV landscape on Monad
This article explores the possibility of building a powerful miner extractable value auction infrastructure (MEVA) on Monad.
Written by:APRIORI 208
Compiled by Deep Wave TechFlow
introductory
In the process of improving blockchain performance to achieve large-scale applications, Monad effectively optimized through a series of low-level optimization measures such as asynchronous I/O, optimized Patricia Trie, delayed execution, and optimistic concurrency controlEthereumVirtual machine (EVM) model. These improvements address execution bottlenecks and inefficient state access issues on platforms such as Ethereum without sacrificing decentralization.
This article explores the possibility of building a powerful miner extractable value auction infrastructure (MEVA) on Monad, and draws on Flashbots on Ethereum andSolanaValuable experience on Jito Network.
We would like to highlight a few key points:
MEV is an inherent characteristic of any blockchain network. A strong MEVA infrastructure is critical to avoid negative externalities and inconsistent incentives in block production.
The design of MEVA is closely related to the underlying mechanisms of blockchain, particularly the consensus execution phase. Future improvements will depend on the evolution of these factors and how the network performs under different pressures.
Historical trends in block production on Ethereum and Solana can inform MEVA design on Monad.
On a high-performance, delayed-execution blockchain like Monad, MEVA may require probabilistic block construction and search strategies similar to high-frequency transactions to cope with time limitations.
By exploring these questions, we wanted to provide insight into designing MEVA infrastructure adapted to Monad's unique architecture and performance requirements.
MEVA background in EthereumMEVA under the Ethereum consensus implementation phase
In Ethereum, consensus needs to be executed first. When nodes agree to a block, they agree not only on the list of transactions in the block, but also on the Merkle root summarized after the block is executed. Therefore, proponents must execute all transactions in the block before spreading the proposal. At the same time, validators also need to execute these transactions before voting.
Figure 1: Proposer-Builder Separation (PBS) Builder Workflow in MEV-Boost
Figure 1 shows a typical builder workflow for Proposer-Builder Separation (PBS) in MEV-Boost. After the builder completes the block construction, it submits it to the repeater, and the repeater then forwards the block to the execution layer (EL) client for simulation and validity checks.
Since execution is a prerequisite for consensus, when the builder constructs a block, it is necessary to forward the block to the execution layer (EL) client and simulate the block to check its validity. In addition to being necessary in the consensus-execution phase, the simulation phase also provides benefits to builders and searchers.
From the builder's perspective: By simulating every transaction, the builder can accurately estimate the value of the block to itself and the validators. They can also try reordering transactions to minimize rollbacks and maximize gas fees or basic tips drawn from memory pools and bundled transactions. Accurate estimates enable them to pay more for validators.
From the viewpoint of the searcher: Since the builder filters out bundled transactions that may roll back before the transaction goes live, the searcher can ensure the execution of the strategy, increasing certainty. Additionally, searchers can access the latest block status. As the consensus layer (CL) propagates a new block, the searcher can use that block's state as a starting point for constructing profitable bundled transactions. At the same time, there are signs that builders now provide more transactions or features outside of the protocol, enabling searchers to obtain information on the status of blocks to be built in order to add runback strategies to blocks that are about to go live on the chain.
However, the development of PBS has led to an increase in the centralization of block construction, similar to traditional transactions where companies compete for dedicated microwave network channels to prioritize arbitrage strategies.
As the network matures, products are iterating
We now explore how MEVA evolved as Ethereum evolved, as shown in Figure 2.
Figure 2: A chronological view of MEVA's evolution with the Ethereum network
Priority Gas Auction (PGA) Era
As shown in Figure 3, the searcher identified a profitable MEV opportunity and submitted smart contract transactions to a public memory pool. This public visibility has led to on-chain public bidding and one-price auctions, and even failed transactions can incur gas fees.
This period saw highly competitive and expensive unstructured MEV activities, such as transactions with identical (accounts, announcements) pairs and increasing bids, leading to network congestion or unstable consensus.
Figure 3: Simple Priority Gas Auction Schematic
Flashbots and EIP-1559
To solve these problems, Flashbots introduced repeaters as intermediary auction houses between searchers and block producers (miners in the PoW era). This move changed the MEV market from publicly bid one-price auctions to sealed bids. As shown in Figure 4, repeaters help prevent competitive upgrades in public memory pools and establish a more orderly and secure block production process.
The EIP-1559 fee structure also played a role in this. It simplified bidding through basic fees, but it didn't solve the problem of transaction order within the block, which still drives MEV through priority fees. In fact, many searchers used to bid directly to miners via Coinbase transfers. They ended up complaining more about the Coinbase fees because they were no longer able to submit a 0-gas bundle transaction.
Figure 4: MEVA with relay
Separation of Proposers and Builders (PBS)
After Ethereum completed the merger and moved to Proof of Stake (PoS), the separation of proponents and builders (PBS) was implemented to further optimize the separation of roles in the block production pipeline. As mentioned before, the repeater now acts as an intermediary between block builders and proponents, and is responsible for ensuring data availability and block effectiveness. Since proponents can connect multiple builders for different private transactions, builders must compete by paying fees to proponents. This dynamic is illustrated in Figure 5.
Figure 5: MEVA in the PBS Era
Concentrated risk
Despite these historic advances, it is important to highlight the growing risk of concentration in the builder market. Over the past year, the top 9 builders continued to hold more than 50% of the market share, showing a high level of market concentration, as shown in Figure 6. The current state of concentration is more obvious, with the top three builders covering more than 90% of the blocks.
Figure 6: Builder's Market Share, which shows the high concentration prevailing in the builder market (image source)
Jito on SolanaJito's system architecture
As the standard MEVA on Solana, Jito was created to address Solana's high spam trading behavior due to low transaction costs. As long as the cost of a failed transaction (approximately 0.000005 SOL) does not exceed the expected profit, spam trading behavior is effectively encouraged.
According to a 2022 report by Jito Labs, over 96% of arbitrage and liquidation attempts failed that year, and blocks contained more than 50% of MEV-related transactions. The report also pointed out that the clearing robot sent millions of duplicate packages to the network just to complete thousands of successful liquidations, resulting in a failure rate higher than 99%.
Figure 7: Jito's MEVA on Solana
The severity of MEV externality issues on Solana prompted Jito to develop a MEVA layer designed to bring 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:
Repeater - 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 repeater, coordinates searchers, accepts bundles, performs bundling 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, and has historically processed more than 80% of bundles within two slots.
Pseudo-memory pool - creates an operating time window of approximately 200 ms via the Jito-Solana client, triggering a discrete auction of the order flow. Jito shut down this memory pool on March 9, 2024.
Jito's design choices
Let's explore the specific components of the Jito system design and consider how these design choices stemmed from Solana's block production process.
Jito only supports partial block auctions rather than full block construction, probably due to Solana's multi-threaded execution model lacking global scheduling. Specifically, Figure 8 shows parallel threads executing transactions, and each thread maintains its own queue of transactions awaiting execution. Transactions are randomly assigned to threads and ordered locally by priority fee and time. In the absence of global sequencing on the scheduler side (prior to the 1.18.x update), Solana's transactions would essentially experience uncertainty due to scheduler jitter. As a result, in MEVA, searchers or validators cannot reliably determine the current state.
Figure 8: Solana client's multi-threaded execution model. Note that the MEVA bundle phase is attached as an independent thread in the multi-thread queue
From an engineering perspective, running Jito's block engine in parallel as an additional thread fits well with Solana's multi-threaded architecture. Although bundle auctions ensure priority fee-based ranking within the Jito block engine thread, there is no guarantee that bundles will always have global priority over user transactions.
To solve this problem, Jito pre-allocates a portion of the block space to the bundled threads to ensure that there is room for bundling within the block. Although uncertainty remains, this approach increases the probability of successful strategy execution. It also motivates searchers to participate in auctions instead of spamming the web. By reserving block space for bundles, Jito is able to strike a balance between promoting orderly auctions and mitigating the disruptive effects of transaction spam.
Removing a pseudo memory pool
Jito's widespread adoption has had positive results in mitigating spam issues on Solana. According to the P2P study and the data shown in Figure 9, there was a significant increase in relative block productivity after adopting the Jito client. This shows that transaction processing has become more efficient due to the optimized block engine introduced by Jito in 2023.
Figure 9: Evidence that Jito is effective in mitigating spam issues on Solana. The chart is taken from a study carried out by the P2P team
While significant progress has been made, many challenges remain. Since the Jito bundle only partially fills blocks, MEV-induced transactions can still bypass the Jito auction channel. Part of the evidence can be found in the Dune Dashboard in Figure 10, showing that since 2024, the network still has an average of over 50% of failed transactions due to robotic spam.
Figure 10: Dune Dashboard of bot spam trading activity on Solana since May 2022 (see Dune for details)
On March 9, 2024, Jito decided to suspend its flagship memory pool. This decision was due to the growth of memecoin transactions and the ensuing surge in sandwich attacks (where searchers place transactions before and after target transactions), which ultimately affected the user experience. Similar to the MEVA private order flow channel on Ethereum, closing the public memory pool may promote the growth of private order flows through partnerships with front-end services such as wallet providers and Telegram bots. Searchers may directly partner with validators to obtain priority enforcement, inclusion, or exclusion rights.
In fact, Figure 11 shows the hourly Sandwich Bot profit of the largest private memory pool searcher after the memory pool is shut down.
The largest private memory pool finder:
3pe8gpnegayjvvmhqgg1mveoiceDhmqbfwrhpj2paf81
(Translator's note: Sandwich robots are a common stealing attack tool, mainly used to obtain profits in blockchain transactions).
Figure 11: Hourly sandwich robot profit for searcher “3pe8gpnegayjvvmhqgg1mveoiceDhmqbfwrHPJ2PAF81” using a private memory pool
Jito's decision to shut down the memory pool shows the team's commitment to addressing the fundamental issues in the Solana ecosystem. In addition to iterating on MEVA or adjusting Solana's gas fee mechanism, Jito also helps the protocol reduce the risk of attacks through UI product design choices such as limiting default slippage parameters. Whether through fee restructuring that makes spam transactions more expensive or by modifying 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 MonadDelayed execution and its impact on MEVA
Unlike Ethereum, on Ethereum, where it is agreed that a block requires a list of transactions (with sorting) and a Merkel root summarizing all post-event states, Monad decouples previous execution from consensus. The node protocol only needs to solve the official ranking problem. As shown in Figure 12, each node independently executes transactions in block N when starting to agree on block N+1. This arrangement allows for a gas budget corresponding to the full block time, since execution only needs to keep up with consensus. Since the leader node is not required to calculate the factual state root, execution can use the entire consensus period to process the next block.
Figure 12: Monad Delayed Execution vs. Ethereum's Execution-Consensus Phase. The operating time window is also shown from the MEVA design perspective
We define the operating time window as a time frame that allows MEVA to complete a block building proposal on Monad that is viable and profitable compared to the default block building method. The delayed execution model has two immediate consequences:
When MEVA is built for the Nth block within the operating time window, the validator is also reaching a consensus on the Nth block's transaction list while trying to complete the execution of the N-1 block. As a result, the usable state may still be at N-2 during the Nth operating time window. This means that under this deferred execution architecture, there is no guarantee that the relay or builder is “up to date.” As a result, it is impossible to simulate the latest block until the next block is generated, leading to uncertainty.
Given Monad's 1-second block time, MEVA's operating time window is extremely limited. This means that builders may not have enough time to simulate the transactions and bundling of complete blocks in sequence, as is usually done on Ethereum. Many variables can influence how long it takes to simulate a trade on 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 operating time window alone could take about 1 second. Given Monad's 1-second block time, it would be challenging for builders or relays to complete multiple full block simulations to optimize the built block.
Probability Builder and Searcher Strategies
Due to these limitations, it is impractical to complete the full block simulation within the operating time window and simulate the latest state. Since builders now lack both the time and the latest status to know the exact hint of each deal, they must infer searcher tips based on the possibility of a deal rollback, rely on reputation or (probably best) simulate N-2 status. This makes block valuations less certain.
Due to the lack of theoretical guarantees for transaction rollback, once the validator accepts the block constructed by the builder, the searcher faces greater execution uncertainty. This is in contrast to Ethereum, where searchers compete in a dedicated private order flow to the builder channel to execute with a relatively determined strategy. In this relative probability setup on Monad, searchers now face a higher risk of bundle rollbacks, leading to a more uncertain execution PnL profile. This is similar to high-frequency traders, who execute trades based on probabilistic signals and get slightly higher expected returns over time.
Figure 13: A conceptual spectrum map showing the different MEVA design paradigms, classified according to the degree of inspection or simulation of the proposed block
As shown in Figure 13, the extent of prior bundling/block inspection on the part of the builder creates a spectrum of uncertainty in the pricing or valuation of proposed blocks. At one end is an Ethereum-style PBS model with accurate pricing, and the builder must simulate transactions in the proposed block using an execution layer (EL) client. They have to navigate a wide range of combinations within the submitted bundles. At the other end is the optimistic builder model [16], which has asynchronous block checks. In this model, the builder bypasses the time required for any simulation within the operating time window and honors the prompts shown to the validator or relay by depositing collateral (which may be cut). The probability check or part of the simulation method proposed here on Monad is in the middle, and although there is some uncertainty, it increases the likelihood that the searcher will successfully execute the strategy.
For example, a market maker with an on-chain order book DEX may pre-move its position via MEVA when it sees a major one-way price movement to avoid unfavorable choices. This probabilistic strategy allows them to act quickly, even without up-to-date status information, to balance risk and reward in a dynamic trading environment.
epilogue
MEVA has played a key role in optimizing block production, mitigating external influences, and improving system stability. As the MEVA framework continues to evolve, such as Jito on Solana and various implementations on Ethereum, it has greatly facilitated the resolution of scalability issues and made the incentives for network participants more consistent.
Monad is a nascent, promising network that provides the community with a unique opportunity to design the best MEVA. Given Monad's unique separation of execution and consensus mechanisms, we invite researchers, developers, and validators to collaborate and share their insights. This collaboration will help create a strong and efficient block production process, and help Monad realize its future as a high-throughput blockchain network.
