Our MEV North Star: Reducing Intermediaries Between Searchers and Validators
Introduction
Monad’s promise to solve the blockchain trilemma is an untapped opportunity to reach mass adoption within crypto. Its key practical improvements include 10,000 transactions per second on a fully L1 EVM and Ethereum RPC API compatible. The full EVM bytecode compatibility allows for the seamless onboarding of developers from the ETH ecosystem, the biggest community of crypto developers yet. The RPC compatibility permits all ETH + L2 users to adopt Monad without challenges or obstacles, such as migrating to a new wallet.
Monad brings the following 4 key improvements1:
MonadBFT is a consensus mechanism that enhances security and efficiency through Byzantine Fault Tolerance. It ensures single-slot finality, enabling the blockchain to achieve rapid consensus and remain secure despite malicious actors or network disruptions.
Deferred Execution: This novel approach optimizes transaction processing by decoupling execution from consensus.
Parallel Execution: Monad uses optimistic execution to process multiple transactions simultaneously, Monad achieves 10,000 transactions per second.
MonadDb implements a Patricia Trie data structure vs Ethereum Merkle Patricia Trie. This approach plus other improvements make MonadDb a great solution based on speed and scalability.
Given Monad’s potential to address the blockchain trilemma, it is pretty clear that MEV will be a crucial component of the Monad supply chain. Magma is partnering with the top-tier validators to develop an MEV solution that pushes the APY rewards of our Liquid Staking Token.
What is MEV?
MEV stands for Maximal Extractable Value. MEV is the additional value that can be obtained from block production beyond the typical block rewards and transaction fees. This is achieved by altering the inclusion, exclusion, or order of transactions within a block.2
MEV Controversies
MEV has always been a controversial topic due to its consequences. It can be categorized into three for network participants: good, neutral, and bad MEV3.
Bad MEV is probably the one all of us know and are afraid of. The well-known Paradigm blog post “Ethereum is a Dark Forest4 went viral after explaining the concept of frontrunning. Frontrunning can happen since arbitrage bots can look at the public mempool and run the transaction you were submitting to the blockchain before you, therefore frontrunning you and obtaining the result you were expecting with your transaction. On Ethereum, there is a new block every 12 seconds which gives more than enough time for arbitrage bots to scan the public mempool, validate, and submit your transaction to a block-builder so that it is ordered before yours.
Another type of negative MEV is sandwich attacks, which consist of placing a buy and a sell transaction in between your buy transaction, therefore, making a small profit with your transaction based on the price change. This and frontrunning are the most known types of MEV and they are negative for the health of a blockchain due to its unfairness with no positive externalities, it consists of a zero-sum game where you lose vs a specialized actor.
On the other hand, good MEV is less known and contributes to blockchain and DeFi's overall health. Examples of good MEV are liquidations and DEX arbitrage. Liquidations ensure that undercollateralized loans on DeFi platforms are properly liquidated, these liquidations are essential to prevent “bad debt” on lending protocols, which occurs when debt is not fully backed by collateral. Without this kind of MEV and incentives for anyone building an MEV bot to liquidate for a small profit, healthy DeFi would not exist. Furthermore, DEX arbitrage consists of benefiting from DEXes price discrepancies by arbitraging and leading to an equal price across all DEXes, this again contributes to the overall health of the ecosystem participants.
Lastly, you have backrunning which does not affect anybody and it is just a strategy to place a transaction after a known profitable transaction to benefit from the price change. This is known as neutral MEV.
MEV on Ethereum
Par excellence, MEV's biggest field is Ethereum. Apart from Ethereum being the largest player regarding smart contracts, it has characteristics that make MEV quite fruitful here. The fact that there is a new block every 12 seconds, allows network participants to have enough time to reorder and validate the transactions of a block before submitting it to the validators. It is the ideal time space for sophisticated actors to implement algorithms in their favor to save on gas and prevent any reverts on their transactions in a deterministic manner.
Regarding the MEV supply chain on Ethereum. In theory, MEV is earned by validators. In practice, however, there is a long MEV infrastructure in which searchers compete to have their transaction placed first by validators. In this sense, validators benefit since the only way for searchers to guarantee transaction inclusion in the block is by paying high gas fees. These searchers are getting more sophisticated, they apply different gas optimizations and algorithms in their smart contracts to reduce the gas needed for their arbitrage opportunities, this practice is known as “gas golfing”.
If we look at the history of MEV, the 2021 crisis resulted in searchers spamming the network competing to include their transactions first. These gas spikes and on-chain congestion prompted the implementation of EIP-15595 on the Ethereum mainnet on August 5, 20216, as part of the London hard fork. This EIP aimed to stabilize transaction fees and improve the user experience by introducing a base fee mechanism. This change helped mitigate the volatility in gas prices by burning a portion of the transaction fees, thus reducing the incentive for excessive bidding wars. Additionally, EIP-1559 provided a more predictable fee structure, allowing users to estimate transaction costs better and reducing the likelihood of network congestion caused by MEV activities. Thanks to this EIP, searchers still compete for gas but only on the priority fee.
In early 2022, Flashbots introduced the Proposer-Builder Separation (PBS) architecture. In PBS, block builders create block proposals by selecting and ordering transactions, often incorporating MEV bundles submitted by searchers. These block proposals are then sent to relayers, which aggregate proposals from multiple builders and choose the one with the highest fees. Block proposers, most commonly known as validators, use MEV-Boost instead of the default execution client to propose the most profitable block received from relayers to the Ethereum network. Validators can connect to multiple relayers, with MEV-Boost serving as an intermediary between the marketplace of block builders and the marketplace of validators7.
To explore further, let us examine Ethereum’s order flow landscape8.
This flow reveals significant challenges in decentralizing the block builder role, as the top five actors build 80% of the blocks. Currently, the two largest block builders are https://beaverbuild.org/ and https://www.titanbuilder.xyz/. The block builder centralization threat comes with the following risks:
Censorship: These 5 block builders can see the transaction they are including in a block, and therefore can agree on specific block-building behavior as well as on which transactions to include or not in the block.
Exclusive order flow: If a block builder builder can access inputs for their blocks other builders do not have9, it can create a dangerous flywheel10 where this builder becomes the main player on the market. A particular block builder might have a private deal-flow for two reasons: offering users an RPC that respects their privacy and share part of the MEV with original users. These economies of scale go against Ethereum's main principles to maintain decentralization, and that is low barriers of entry.
Cross-domain MEV11: this can also lead to economies of scale, contributing to the centralization of the block building within the Ethereum supply chain.
To take on these centralization challenges, Flashbots is developing the new SUAVE12 (Single Unifying Auction for Value Expression) architecture to decentralize the block builder. The new architecture needs to comply with the following premises:
Neutralize the pressure from exclusive order flow by giving users rights to participate in the MEV they create. Furthermore, all the transactions the users submit should be private and available to all block builders.
Block builders from different chains have to integrate with each other in a permissionless manner to mitigate cross-domain MEV.
Lastly, the system that solves these two challenges, should as well be decentralized.
The SUAVE proposition looks to build a plug-and-play mempool and decentralized block builder for all blockchains.
The advantages of this approach are the following:
Builders limited to a single domain are increasingly disadvantaged due to cross-domain MEV.
Users gain efficiency by aggregating and clearing preferences within the same auction, enhancing SUAVE's advantage over centralized builders.
SUAVE gains an information edge due to all the parties involved vs centralized builders' information access.
Reaching a decentralized sequencer is a hard problem worth the cost of developing SUAVE for all chains.
A decentralized system can provide the necessary security and credible neutrality due to the fundamental role of sequencing in the blockchain stack.
SUAVE’s solution resides in building a new specialized EVM-compatible chain that is based on three main points.
Universal Preference Environment. A specialized chain and mempool for users and searchers to express their preferences regarding the execution of the transactions they submit, maintaining existing properties of bundles such as pre-confirmation privacy and determinism in the form of no reverts. This can lead to specialization to meet market needs. Examples could be sponsoring gas or batching similar transactions as demanded by users and searchers.
Optimal Execution Market. SUAVE proposes an auction model where if there is MEV on a transaction, executors compete to capture it and give as much as possible of the MEV profits to the original user. The Execution Market acknowledges the economic significance of order flow and aims to be a decentralized platform where users, wallets, and other sources of order flow can maximize their earnings from transactions.
Decentralized Block Building. The decentralized block-building market optimizes MEV for both builders and validators, while also enabling the builder to operate in a decentralized manner.
To accomplish the aforementioned objectives, Flashbots will lean on SGX technology13 to achieve an SGX-based order flow auction and an SGX-based decentralized block-building network.
MEV on Solana
Solana's low transaction costs create a perfect storm for network spam coming from arbitrage and MEV activities. Although determinism is challenging due to Solana’s 400ms block times14, the low transaction cost makes it easy for MEV bots to send as many transactions as possible. In 2022, 25% of block space accounted for MEV, and in some blocks up to 50%15. This made it difficult for normal users to land transactions on the Solana network. 60% of block computing was used by arbitrage transactions, with more than 98% of arbitrage transactions failing. Solana validators wasted 58% of their time processing failed arbitrages16. Even today, Solana's failed transactions account for 40% of total transaction due to network spamming17.
Solana's architecture is unique due to its use of the Proof of History (PoH) consensus algorithm18. Validators are organized into clusters19. Within each cluster, when a validator receives a transaction, it forwards it to the current leader and the next two leaders, resulting in an absence of mempool. The leader is responsible for appending transactions to the ledger during a designated time period known as a slot. Typically, a leader includes transactions based on FIFO (First In, First Out) and priority fees20.
A leader schedule21 determines which validator will act as the leader for each slot. Nonetheless, this schedule causes a network “jitter” when validators share the shred22 (partial blocks) they are building with other nodes, this time deviation gives room for transaction reordering and MEV. Note that there is no global ordering of transactions queued for execution, there is just a local ordering in each thread’s queue. It is important to notice that Solana architecture allows for continuous block production, meaning the Solana protocol does not wait for consensus from all validators on a newly produced block before proceeding to the next one.
One can think that something like EIP-1559 could be introduced in Solana to prevent network spamming. However, the actual problem is that base fees in Solana do not depend on compute units used, the base Solana fee is fixed at 5,000 lamports per signature independently of compute units. Regarding the priority fee, it is based on compute units requested, not on real compute units used, since the used compute units are not known until a transaction is executed. Lastly, for both the base fee and priority fee, 50% is kept by the leader as an incentive to include transactions in blocks and 50% is burned23.
All these factors shape how MEV is extracted in Solana, resulting in less sophisticated MEV compared to Ethereum. There are mainly three types of MEV within Solana24. First, we can find atomic arbitrages that extract MEV when two DEXs have different prices for the same trading pair; secondly, liquidations also produce MEV on Solana. Lastly, NFT mints for popular collections represent a riskier form of MEV, since one has to sell the acquired NFTs after the mint.
The specialty within Solana is that searchers have different techniques to land their MEV transactions compared to Ethereum where Flashbots architecture dominates the chain. These strategies are the following:
Spam. It makes sense to searchers if the expected profit from MEV exceeds the cost of a failed transaction (0.000005 SOL). This is why 60% of block computing is used by MEV transactions, with more than 98% of arbitrage transactions failing.
Optimistic transactions. On Solana, searchers can send transactions optimistically. In this scenario, the searching logic lives on-chain to read the state at execution time; additionally, it exposes a searching method to be called when certain off-chain logic presumes there is an arbitrage opportunity. This reduces the need for pre-transaction state checks, decreasing trade latency. This technique is useful on Solana due to its high read speed requirements and the low cost of failed transactions.
Priority fees. This is the least effective method for landing transactions. A high priority fee doesn’t guarantee the inclusion of the transaction first, due to Solana mechanics, where a faster searcher could get their transaction first even with a lower priority fee.
High-stake validators. Shreds are first propagated from the leader to a set of validators chosen by a stake-weighted shuffle, this is why a search may decide to send their transaction through a high-stake validator or be a high-stake validator themselves.
Leader slots. A validator who is also a searcher, could order the blockspace they are building in their favor when being the leader.
JITO bundles. JITO decided to launch a forked Solana validator client in October 202225. This client auctions block space off-chain by introducing a 200ms time frame where validators accept transaction bundles while also offering revert and MEV protection26. When using the JITO client validators will earn more fees than running a Solana client, where 50% of fees are burned and not captured by validators. Furthermore, searchers compete now for block space price instead of speed. This results in more determinism for searchers, who can adjust their transactions deterministically to compete for block space auction prices, which will turn more MEV into validators as a result of the bidding competition. JITO’s proposition has resulted in their validator client gaining 90% market share27.
Application-Specific Sequencing
Application-specific sequencing offers decentralized applications control over how transactions impacting their state are sequenced. ASS allows applications to regain sovereignty over its execution and contract state. In the past, if an app wanted to be sovereign it would have to build its app chain and face some challenging UX and liquidity requirements. On the other hand, ASS offers greater composability than an app chain. It enables applications to retain the value that will flow to validators through MEV in other cases, this approach leaves the opportunity for the applications to share this value capture with their stakeholders. Lastly, it is important to note that this is the first approach that addresses MEV from an application level instead of a protocol level28.
Comparing this architecture with PBS, we can see ASS has the following properties:
Restricted Sequencing Rights: This limitation ensures that only authorized validators can interact with the application's contract.
App-Specific Mempools: Instead of sending transactions to a public mempool, users submit signed intents to an app-specific mempool.
Order-Agnostic Outcomes: To uphold the sequencing rule and provide optimal economic benefits to the intended users, ASS transactions must be independent of the builders' transaction order for the rest of the block. This is accomplished by combining ASS orders into a single bundle, which is sent to builders for inclusion. Since this bundle does not conflict with the state accessed by other applications, its position within the block is irrelevant.
ASS benefits and challenges
Application-specific sequencing benefits for users and applications over validators are clear. The ability to retain MEV value capture and distribute it within the stakeholders of an application makes sense from a traditional market perspective. These users and applications want to transact without leaking any value and in the most efficient manner possible. However, it is also true that these applications are running on a blockchain that has a decentralized nature, with many more parties and infrastructure involved for these whole processes to work in a trustless manner.
Furthermore, application-specific sequencing benefits over implementing an app chain are quite clear:
Execution of the transactions stays in the original blockchain. ASS only delegates sequencing order, however, the execution of the transaction stays in the original L1 or L2.
User experience. Since the users do not need to bridge to a new chain, ASS does not come with additional UX compromises.
Access to liquidity. Applications can directly leverage the order flow and liquidity of the chain.
Assets reside in the native execution environment. Since all the assets are not bridged, there is no risk of depegs, chain halt, or security bridge hacks between others.
Application-specific sequencing challenges that need to be addressed:
Censorship. If we look at the perp and spot DEX Vertex, we can see that they run ASS through an off-chain sequencer to minimize MEV. This is a great approach, however, since the sequencer controls which transactions are included, this central entity could decide to censor specific users or transactions29.
Permissioned transaction validation. As we stated before only authorized validators can include transactions, this goes against the permissionless principles of any blockchain.
Liveness assumption. In the event of a liveness breach, such as a network partition, users may be unable to interact with parts of the application until a valid consensus is restored.
Trust assumption. As we stated, whether ASS introduces one or more sequencers, there is an inevitable trust in external sequencers that could be broken if one of them decides to act maliciously.
The composability dilemma. Applications that require high composability with other applications may sacrifice some control over transaction sequencing, making them more susceptible to MEV. On the other hand, applications that limit interactions with others gain more control over transaction ordering, allowing them to better protect against MEV exploitation and capture more value. However, this can reduce interoperability and potentially affect user experience30. Depending on the application’s composability needs ASS can be a great product or not.
Validators misalignment. ASS will probably be adopted sequentially by different applications, this will probably cause inefficiencies in the validators ecosystem. Validators are going to find themselves in a weird position to compete in the market, either they follow the status quo and continue with PBS being more competitive, or they adopt ASS at the cost of losing some revenue at least in the short term. It is important to take into account that MEV will always exist as some applications may choose not to do ASS for different reasons.
ASS bundle reversion. A single invalid non-ASS transaction, when composed with an app-specific one, can have the second-order effect of reverting the entire bundle.
Frontrun and backrun opportunities. Theoretically, searches could compete to place an order before or after a specific ASS bundle.
Resources overhead. Many applications might find that ASS represents a big effort for low results, following Pareto’s law, applications which do not rely on ASS as their main selling point might skip implementing ASS due to the resources needed to implement these solutions. For example, Fastlane’s flagship product Atlas requires modifying the frontend and backend, integrating with an operations relay, and developing a custom DAppControl module31.
It is important to remember that there are different players in the market like Sorella Labs, FastLane, Vertex Protocol, and Semantic Layer which are trying to solve the aforementioned challenges in different ways. ASS is still a nascent technology with a promising future and only time can tell if ASS will pass these challenges and get widely adopted.
MEV on Monad
Monad’s continuous block production presents challenges for MEV participants due to its deferred execution, which introduces indeterminism. Consensus happens first, where the order of transactions is settled between nodes, then, on the next block these transactions are executed in the consensualized order.
In the default Monad client, leaders use a priority gas auction to determine the transaction sequence. The Monad protocol does not enforce a specific transaction order as valid, and gas costs per opcode are identical to those in Ethereum32. It is important to note that indeterminism refers to execution, since absolute determinism exists regarding the order in which transactions will be executed, in other words, there is state determinism: “execution is required to unveil the truth, but the truth is already determined”33. Hence, validators agree on the order of these transactions through consensus, even though these transactions will execute on the next block.
Looking at Ethereum and Solana, we can conclude that searchers are looking for revert protection, hence, thereby avoiding the need to spam the network to secure inclusion. On this matter, it is not clear if simulating a transaction is going to be possible due to the parallel and deferred execution, even if possible, only part of the block transactions can be validated within a second due to Monad’s block speed. At Magma, we are researching a method in which a partial bundle of transactions can be auctioned off-chain offering guaranteed revert protection. This approach draws inspiration from Jito’s architecture, where due to network speed constraints, Jito's client does some partial block-building auctions where they offer revert protection.
Lastly, another area of research to align searchers and validators involves developing a fast and efficient method for searchers to land their transactions, offering MEV protection and multiple transactions being processed sequentially and atomically. This is an important area of research for Magma in conjunction with revert protection. This playbook has been successful in the past, addressing the needs of searchers and validators. Monad’s new architecture raises some questions, but a client offering these features could be a highly sought- after product in the ecosystem. Additionally, our objective is to reduce intermediaries and steps in the whole MEV architecture, enabling searchers to land their transactions faster while minimizing MEV capture by intermediaries.
Our MEV North Star
A north star is an ideal goal towards which we strive. For example, Solana’s North Star is for the blockchain to propagate transactions in real-time from one side of the world to the other, without latency. Having a clear north star helps ensure alignment in our direction. Achieving this goal is a step-by-step process, always evolving and subject to continuous improvement.
Our MEV north star is to reduce the number of intermediaries in the MEV process and get as close as possible to having direct communication between searchers and validators. As we have shown above, typical MEV flows can consist of 2-3 intermediary steps between a searcher submitting a transaction and a transaction being included in a block. Reducing the number of steps has practical benefits: with one-second block times, each additional intermediary step in the MEV process increases network latency.
It is important to remember that while reaching our north star, we have to make sure that every network participant is aligned. This is why we are researching three different areas to provide an equitable MEV architecture for the whole ecosystem with the least intermediaries and with users at its forefront.
After analyzing the Proposer-Builder Separation (PBS) model, we concluded that some components need to be removed if we want to follow a similar path on Monad. This makes sense given the similarities between Monad and Ethereum. Monad is starting with a priority gas auction model, which could result in a similar architecture to PBS if MEV evolves within Monad. Reviewing the different components of PBS, we are researching the possibility of extracting the relayer from the architecture to make it more optimal. This would allow for at least some partial block building where searchers submit their MEV bundles.
Looking at the typical PBS MEV flow, it is clear that the first step would be to remove relayers, creating a marketplace from block builders to validators.
There are significant performance benefits achieved by removing the relayer. Monad is designed for continuous block production and high throughput; the extraction of the relayer could streamline the MEV process significantly. This improvement could extend the operational time window under which searchers need to operate to submit their MEV bundles, hence, less sophisticated searchers would be allowed to operate on Monad favoring MEV infrastructure decentralization.
In this model, the way that builders communicate with validators about the sequence of transactions that should be included in the consensus block is crucial. This adds increased complexity in managing transaction prioritization and block construction without a centralized relayer. Additionally, some constraints have to be met such as avoidance of centralization by block builders, and lack of incentives for transaction reordering either by builders or validators. Another interesting concern is to avoid increasing the workload of the validators' nodes, given the current strain they will experience with one-second block times. This upgrade requires careful consideration of the technical and operational challenges to ensure that the validators remain robust, secure, and capable of handling high transaction volumes.
From another perspective, Trusted Execution Environments (TEEs) have immense potential, and we are researching their application at the client level. More concretely, Intel SGX is a specific implementation of a TEE, designed to provide a secure area within a processor for executing sensitive computations. SGX achieves this by creating secure enclaves, which are protected regions of memory that ensure the confidentiality and integrity of the data and code they contain. These enclaves allow for secure execution by isolating the processing of sensitive data from the main operating system and other applications. This isolation ensures that even if the rest of the system is compromised, the data within the enclave remains secure.
By running a client within an SGX enclave, transaction details can be kept confidential, even from the node operator. This setup ensures that transaction data is not exposed to unauthorized parties, providing a high level of privacy and security. The concept of a private mempool using SGX is particularly appealing. Through this approach architectures such as PBS would be reduced to users, searchers, and validators, removing all the intermediaries while giving privacy and MEV protection to users.
The benefits of using SGX for a private mempool are significant, particularly in terms of enhanced privacy and trust minimization. By ensuring that transaction details remain private, SGX protects them from potential leaks or unauthorized access, which is crucial in reducing the risk of front-running. Furthermore, TEEs and SGX open the MEV space to more participants who can become validators; it is important to remember that TEEs can provide integrity and privacy even in the presence of a malicious operator. Regarding the challenges, performance is one of our main areas of research, if we take a look at Flashbot’s experimentation with SGX34 we can see that running an SGX client is demanding from a time and resource perspective.
Another area of active research is Fully Homomorphic Encryption (FHE) and its applications within the MEV space. FHE is a form of encryption that allows computations to be performed on encrypted data without needing to decrypt it first. This means that you can perform operations on the data while it remains secure and private, and the results of these operations, when decrypted, will match the results of operations performed on the plaintext data.
These bring numerous benefits, especially when you think that users could submit encrypted transactions to searchers that would be private. The searchers could take advantage and blindly backrun these encrypted transactions without affecting the initial users. Furthermore, this approach would bring us to our north star of having only users, searchers, and validators. Additionally, it is important to note that FHE is more efficient than secret-sharing-based MPC protocols. However, several challenges remain. First, if we look at the high hardware requirements of past experiments with FHE35, we can see that centralization might be a problem due to computation needs, which could limit the number of searchers. Secondly, it is not clear yet how we might limit what blind operations the searcher can backrun on the user. Lastly, within FHE, there are still many optimizations to be done regarding arithmetic operations and its different cryptographic operations.
Conclusion
In conclusion, we aim to leverage the latest technologies to create an MEV architecture where searchers can send their transactions directly to validators. In our journey toward this goal, we strive to reduce intermediaries and associated latency in the MEV flow. This approach offers several benefits: it provides searchers with more time to submit their transactions, thereby opening up the MEV space to less sophisticated players for whom speed is not the most critical factor. Additionally, it enhances privacy and reduces the risk of censorship by eliminating intermediaries, thus establishing a direct marketplace between searchers and validators. Lastly, our pillars of MEV design prioritizes users by focusing on privacy, protection from bad MEV, and minimizing latency.