The Ethereum protocol and broader ecosystem continuously aim to improve the value that Ethereum can provide. A key ecosystem-wide bottleneck to improving Ethereum has been Maximal Extractable Value (MEV). MEV refers to the maximum value the protocol agent responsible for including, ordering, and excluding transactions in a block can extract from the system. This post summarizes the methods proposed to mitigate the negative effects of MEV on applications and the protocol and investigates future research directions.

This post is organized as follows:

The first section proposes a 2-dimensional categorization of out-of-protocol MEV mitigation techniques. An example of each category is explored.

The section after that explores why the Ethereum protocol cannot function as the infrastructure that prevents or rebates MEV.

Thirdly, we explore what the Ethereum protocol does to prevent the negative externalities of MEV.

Finally, we argue that none of the discussed in- or out-of-protocol MEV mitigation techniques can solve all problems caused by MEV simultaneously.

The start of this post functions as a partial systemization of knowledge of MEV mitigation. Yet, the fourth section presents a relatively novel argument that out-of-protocol MEV mitigation does not solve in-protocol MEV problems. This argument is based on a paper by Davide Crapis and me.

This post refers to in- and out-of-protocol mitigation techniques. With in-protocol MEV mitigation techniques, we mean mechanisms that are either part of the Ethereum protocol rules or that would require changing the Ethereum protocol rules. Out-of-protocol mitigation techniques are all mechanisms that are not in-protocol.

Out-of-protocol MEV mitigation

MEV imposes rents on users interacting with a blockchain. To increase the value that Ethereum facilitates, it is intuitive to decrease the rent that MEV represents. The mandate of out-of-protocol MEV mitigation techniques is to decrease the value-inhibiting effect that MEV poses without changing Ethereum’s protocol rules.

We will use how MEV is extracted on Automated Market Makers (AMMs) and, consequently, how it can be mitigated as an example. Many AMMs work as follows:

Liquidity providers (LPs) provide multiple different tokens to an AMM and let the AMM set the prices against which users can trade with the LP’s tokens.

An AMM adjusts its pricing only in response to transactions included in new blocks. This discrete adjustment contrasts with the continuous price fluctuations of the underlying tokens in external markets.

When a block needs to be proposed, the block producer can include transactions that use the publicly observable external market price to arbitrage the stale quotes on an AMM, thereby extracting MEV.

This form of MEV, known as Loss-Versus-Rebalancing (LVR), is a cost for liquidity providers. Keeping the fees that accrue to liquidity providers constant, the amount of liquidity provided decreases with the amount of LVR extracted from the AMM. Less liquidity means that user trades have a higher price impact, meaning it is more expensive for users to trade on the AMM. A goal of AMM design is to decrease the cost that LVR imposes on the AMM. Similarly, a goal of application design, in general, is to decrease the cost of MEV on users.

There are many ways in which the cost of MEV can be decreased. Roughly, out-of-protocol MEV mitigation techniques are divided along two axes:

• Application-specific or shared infrastructure MEV mitigation techniques.
• Preventing MEV or rebating MEV.

The first axis is whether an application mitigates MEV by itself or relies on some shared infrastructure. The second axis is more complicated. An application could either be designed to prevent exposing MEV in the first place, or it could sell the right to extract the MEV and rebate the sales revenues to those extracted from. Rebating MEV slightly misuses the definition of MEV, which is the value the actor responsible for including, ordering, and excluding transactions can extract from the system. MEV that is rebated is not extracted from the system and thus does not strictly fit the definition of MEV. Still, using the term MEV may be helpful since all concepts related to MEV apply to the value that is rebated, aside from where the revenue goes. We will see examples of all four possibilities and discuss their relative advantages.

Figure 1: 2-dimensional categorization of out-of-protocol MEV mitigation techniques with examples for each category.

Application-Specific and Preventing MEV: The Function Maximizing AMM.

The MEV mitigation technique that is usually conceptually most intuitive for those who hear about MEV for the first time is an application that prevents exposure to MEV. An exciting example is the function maximizing AMM proposed by Andrea Canidio and Robin Fritsch. It batches trades collected over a period of time and executes all at a uniform clearing price. The authors show that it eliminates LVR and sandwiching, another MEV form. The intuition is that all participants trade at the marginal price of the pool after the batch and that arbitrageurs are incentivized to trade up until the point at which this price is equal to the external market price. This system is similar to a frequent batch auction proposed by Budish, Cramton, and Shim (2015) in the traditional finance literature. As an aside, it is thus an excellent example of synergies between decentralized and traditional finance. Traditional finance ideas can be implemented in decentralized finance; the learnings from the implementation can then be used to inform traditional finance.

Application-Specific and Rebating MEV: The MEV capturing AMM.

The MEV capturing AMM (McAMM) is an example of an application-specific MEV mitigation that relies on rebating. The McAMM auctions off the right to be the first trader to interact with the AMM in a block, thus allowing this trader to extract a possible arbitrage. The auction proceeds are then distributed amongst the arbitraged liquidity providers. If the auction is efficient, the proceeds should equal the arbitrage value extracted from liquidity providers. This design could lead to the same LVR elimination as the function maximizing AMM discussed above, even though the approach is radically different. Whether this will be the case in practice depends heavily on the specific implementations of the auction.

Infrastructure and Rebating MEV: MEV-Share.

Rebating does not have to be specific to an application. Flashbots, a company operating in the block construction space, has developed MEV-Share. It lets users choose what transaction data to share in an auction privately. Bidders bid for the right to place this transaction in a bundle and thus extract MEV from it. The user can receive the auction proceeds. This infrastructure is not application-specific, as transactions could interact with any application.

Infrastructure and Preventing MEV: Protected Order-Flow in a Profit-Seeking World.

Finally, there are infrastructural mechanisms that aim to prevent MEV extraction. An example is Protected Order-Flow in a Profit-Seeking World (PROF). PROF relies on a block producer within a Trusted Execution Environment (TEE) that credibly commits to an ordering rule, for example, first-come, first-serve. TEEs have two critical properties that make the commitment credible, namely:

• [ ] Integrity: the code and data within the TEE cannot be modified or tampered with, either during execution or while stored, by external entities such as the operating system, hypervisor, or malicious actors.
• [ ] Confidentiality: the data and computations inside the TEE remain private and inaccessible to unauthorized entities, including the host system, other applications, or attackers.

Any user that sends its transaction to a block producer who commits to running an ordering rule knows the block producer in the TEE will do so. Therefore, PROF can prevent certain types of MEV extraction, like front-running for any application, without changing the Ethereum protocol’s rules.

Different MEV mitigation techniques have different pros and cons. Application-specific MEV prevention techniques are difficult to find as they require much research and implementation work per application. Infrastructural MEV prevention, on the other hand, requires a lot of overhead. For example, some infrastructural MEV prevention techniques require running expensive hardware and doing a lot of business development. Whether rebating is effective depends heavily on whether the auction is competitive, which depends on auction specifics like its format and when it takes place.

These four MEV mitigation techniques may not be collectively exhaustive nor fully mutually exclusive. Note also that the dimensions resemble spectrums and not binaries, as shown in Figure 1. For example, some MEV mitigation techniques may be more infrastructural than others. The field moves very rapidly, which makes any categorization challenging. Finally, the space feels optimistic, and many may share the opinion that MEV as a percentage of total value facilitated will rapidly shrink.

The lack of in-protocol MEV mitigation

These MEV mitigation techniques may seem unsatisfactory to some. Why can’t Ethereum be the protocol infrastructure that holistically solves MEV? Maybe some readers would suggest using a specific ordering rule. Proposals to enforce a particular ordering rule in Ethereum, such as first-come-first-serve, have not gained widespread support. I believe there are two fundamental reasons the protocol has been unable to holistically solve the burden MEV places on end users and applications – both are related to Ethereum’s credible neutrality constraint.

First, Ethereum cannot obtain a transitive global ordering satisfying “fairness”. Ethereum hosts a variety of applications that each may benefit from different sorts of ordering rules. While first-come, first-serve ordering may help some applications, it may inhibit the growth of others. Therefore, it is hard for the ecosystem to agree on what is fair. Next to that, even if the ecosystem were to agree on one fair ordering rule, it is hard to obtain a globally transitive ordering rule because a transaction may arrive at different nodes at different times.

These inconsistencies cause problems in first-come, first-serve ordering protocols. Specifically, even if the order in which individual nodes receive transactions is transitive, it does not mean that the aggregate order is also transitive. First-come, first-serve ordering rules can get stuck in cycles to restore transitivity, and sometimes, these cycles have to be solved by an arbitrary rule, like choosing a total ordering alphabetically. This may mean that transactions for which first-come, first-serve ordering is most important, like time-sensitive arbitrage transactions, aren’t ordered in this way but arbitrarily.

Figure 2: Slide showing the Condorcet cycles first-come, first-serve ordering rules may get stuck in. Slide taken from a presentation on Themis by Mahimna Kelkar.

In addition to the fact that first-come, first-serve ordering rules have theoretical problems, it is unclear whether they are desirable in the first place. This ordering rule benefits those with faster connections. If fast connections are valuable enough, this could lead to a latency race, as seen in traditional finance with large investments in speed technology. Speed technology could harm credible neutrality in blockchains as it incentivizes geographical centralization.

Inconsistent views of when transactions arrive cause problems for the first-come, first-serve ordering rule and for every ordering rule. Ordering rules usually aim to achieve some economic properties. For example, priority gas ordering seeks to include those transactions in order of how much they value being included first. Usually, these economic desiderata are fulfilled only if there is a global view of which transactions should be ordered. Since it is hard to obtain a transitive global view from transitive local views, it is hard to obtain such a global view. In other words, some validators will think a transaction should be ordered within one slot, and others think it should be in another slot, degrading the economic properties the ecosystem could expect to receive from a fixed ordering rule.

Secondly, the consensus protocol is unaware of the MEV games played on the execution layer. This would make it hard to design an in-protocol rebating scheme as the protocol currently would not understand what value MEV is and to whom it should be rebated. Finally, the protocol must remain credibly neutral. It should not be in a position where it would have to make an opinionated choice as to whom it should rebate the MEV even if it could, nor should it choose MEV prevention techniques that favor specific applications over others.

An interesting example that comes close to an in-protocol MEV rebating technique is MEV taxes, proposed by Dan Robinson and Dave White. It allows any application to overload the in-protocol priority fee by setting a parameter, say $k$. Any user that interacts with the application then has to pay $k$ times the priority fee it paid to the consensus validator to the application. You may see how this system could rebate MEV proceeds to applications in a generalized manner. For example, if there were 10 ETH of MEV to be extracted from an application, with $k = 9$, by being the first to interact with it, a user may pay a priority fee of 1 ETH to the validator and 9 ETH to the application, assuming that transactions are ordered by priority fee.

MEV taxes is a promising direction, but as stated by its authors, it must be further explored to understand how it would work on Ethereum. One challenging aspect may be that MEV taxes assume the priority fee is a universal signal for the amount of MEV. While this may be true if a priority order is enforced, the ordering itself may decrease the total amount of MEV, similar to how a multi-unit first-price auction may have lower revenue than a combinatorial auction. Flashbots’ SUAVE seems to be heading in the opposite direction, which allows for more expressive preferences. SUAVE is currently not live but aims to build a decentralized block builder that optimally merges bundles without a specific ordering rule.

Priority fees may not resemble MEV well when searchers want to express their preferences for being included in a more complex way than the one-dimensional priority fee. Perhaps a searcher wants to be included within the block before other competing searchers’ bundles but does not care about the absolute position within the block. Using priority fees would mean the searcher competes for position with all users, regardless of their relevance to this searcher.

There are other ways to decrease the MEV extracted from users besides ordering rules. One research direction is encrypted mempools. This means that users broadcast transactions in encrypted form. Only after inclusion is the transaction decrypted. The block producer, thus, does not know the contents of the transaction, making it impossible to conduct front-run transactions based on the now shielded data.

Encrypted mempools are live on Gnosis Chain, a blockchain that has a similar architecture to Ethereum. Ecosystem participants, notably Shutter Network, aim to bring encrypted mempools to Ethereum mainnet. Some current limiting factors are the trust assumptions that are necessary with threshold encryption-based cryptography techniques, the state of Verifiable Delay Functions, and the free data availability problems related to encrypted mempools.

In summary, Ethereum cannot be the infrastructure that prevents MEV because the ecosystem has not been able to agree on a fair ordering rule and because it is hard to achieve a transitive global ordering given any ordering rule. Some proposals for ordering rules, like the MEV taxes example given above and protocol upgrades, have been discussed that could facilitate a transitive global ordering satisfying “fairness”. There is, however, currently no rough consensus on that these are desirable. Ethereum cannot be the infrastructure that rebates MEV because the consensus layer is unaware of what happens on the execution layer and Ethereum cannot choose between applications since it must remain neutral.

What does the protocol do?

The previous paragraph showcases how difficult it is for the protocol to eliminate the burden MEV places on users. However, many protocol mechanisms handle MEV, and an entire section of Vitalik’s roadmap is dedicated to it. What do these mechanisms do?

These in-protocol mechanisms aim to solve a problem different from the mitigation techniques discussed previously. Instead of maximizing the value Ethereum facilitates by minimizing the MEV extracted from users, the in-protocol mechanisms aim to maximize Ethereum’s credible neutrality by minimizing the negative externalities of MEV. MEV not only decreases the utility of those extracted from, it also greatly distorts the behavior of the extractor, for example, it incentivizes centralization through economies of scale and causes consensus instability.

Economic forces are a big centralization risk for Ethereum’s consensus and transitively for its credible neutrality. If there are economies of scale, small consensus agents can be expected to merge with large agents to benefit. If there are returns to sophistication, rational validators may behave differently from the honest specifications. Economies of scale or returns to sophistication for consensus agents are negative externalities of MEV.

The protocol aims to prevent negative externalities by unbundling the roles consensus agents have in Ethereum and firewalling them from each other. Currently, Ethereum assigns all the following roles to one agent, but in principle, these are separate roles. The three roles identified so far are the following:

• [ ] Attesting to information necessary for consensus and creating consensus blocks is the most critical role in Ethereum’s Proof-of-Stake consensus system. Examples are attesting to the head of the chain, attesting to the timeliness of messages, and creating consensus blocks when needed. The rewards for these roles are fairly homogenous across participants.
• [ ] Proposing the execution block. This role ensures the liveness of the execution layer. It may consist of timely submission of the execution payload and efficiently allocating the execution payload building rights. The rewards for this role depend on the participant’s risk tolerance and speed.
• [ ] Building the execution block. This role decides the ordering of transactions in an execution payload. It has the most potential to extract MEV from the system, and clear economies of scale, high barriers to entry, and sophistication are associated with this role. The rewards are thus very heterogeneous across participants.

The Ethereum ecosystem aims to isolate these three roles so that incentives originating from one role do not affect the incentives of those fulfilling another role. Some roles, like transaction ordering, can be more centralized as long as block validation is trustless and highly decentralized, and a decentralized set of participants can ensure censorship resistance, as Vitalik stated in his influential Endgame post.

Proposer-Builder Separation (PBS) aims to separate the roles of proposing and building the execution payload. It is a design philosophy that recognizes the different roles and facilitates the proposer’s outsourcing of its block-building duty to a specialized party. MEV-Boost is the current out-of-protocol instantiation of PBS. It allows all proposers, regardless of sophistication, access to the same MEV markets. Concretely, it enforces that the builder receives the right to construct the block and that the proposer receives their payment for selling this right. With MEV-Boost, a proposer is not better off by investing in sophisticated MEV extraction techniques but can remain relatively unsophisticated in this area and enjoy the same rewards as more sophisticated proposers.

Attester-Proposer Separation (APS) is conceptually similar to PBS. It, too, recognizes the difference between two roles: attesting & proposing consensus blocks and proposing execution blocks. APS is currently in the research phase and no out-of-protocol version is live. Proposers may want to be fast because it allows them to submit their block later, which means they may include more transactions. It is vital for the consensus protocol not to incentivize latency because it leads to geographical centralization. APS is sometimes seen as the last line of defence for the Ethereum protocol.

PBS and APS show how these three roles may be isolated. However, implementing these two protocol upgrades also means that the participants creating blocks would be very centralized, which is terrible for censorship resistance. Ethereum aims to overcome these problems by building one-way valves between these roles. The protocol may overload the role of attesting to blocks with attesting to which transactions are pending in the mempool. A committee of attesters would then be responsible for creating a list of transactions the block producer must include, or else their block would ignored by the attesters. These types of mechanisms are called inclusion lists.

These valves challenge the separation of roles. It is very difficult to design valves that meaningfully use the properties of one set of participants, for example, constraining another set of participants, while also ensuring that those participants at the other end of the valve do not affect the participants who affect them. As an example, the decentralized set of attesters would be responsible for creating an inclusion list. We do not want the block producer nor the centralizing incentives related to block production to affect the attesters.

Figure 3: Division of labor by Attester-Proposer Separation (APS) and Proposer-Builder Separation (PBS) with inclusion lists and selling building rights as one-way valves between roles.

No Single Solution to Two Separate Problems

The primary aim of in-protocol MEV mechanisms fundamentally differs from application and infrastructure MEV mitigation techniques. Out-of-protocol mitigation techniques generally aim to decrease the MEV per unit of value facilitated. In contrast, in-protocol mitigation techniques aim to prevent negative externalities of MEV that centralize Ethereum’s consensus agents. Specific MEV mitigation techniques may contribute towards both goals. MEV-Boost, for example, is technically out-of-protocol, yet its sole goal is to prevent the negative externalities of MEV.

Moreover, the constraints in the two problems are different. In-protocol mechanisms must be designed with hardware requirements and a neutral protocol in mind. In contrast, the constraints of out-of-protocol MEV mitigation techniques depend on the desiderata of the application or infrastructure designers, which can suit a particular use case.

Since these problems have different objectives and constraints, it is intuitive that no single solution can address both. Moreover, there may be a more fundamental dichotomy between the two problems. This section sketches an argument for this dichotomy, also presented in a paper by Davide Crapis and myself.

Application designers want to reduce the MEV per unit of value because doing so would attract more users and thus increase the total value these applications facilitate. If the MEV per unit of value decreases but the total value facilitated increases, the total amount of MEV could decrease but could also increase. In-protocol MEV mechanisms care about the total amount of MEV that consensus agents can extract. Even if the total amount of MEV is a negligible fraction of the value Ethereum facilitates, it is not clear that the protocol does not still need to firewall the different consensus roles necessary to prevent centralization in Ethereum’s consensus participants.

As an example of this argument, consider the case of Loss-Versus-Rebalancing (LVR), introduced earlier as the latency arbitrage losses liquidity providers in AMMs face because their on-chain quotes stay stale between blocks compared to the continuously updating external market. In their work, Milionis et al. find that cumulative LVR over a slot is proportional to the slot time to the power of 3/2.

On first inspection, this would suggest that decreasing the slot time also decreases MEV. LVR, however, is the arbitrage losses per unit of liquidity. Moreover, Joel Hasbrouck, Thomas Rivera, and Fahad Saleh showed that individual LP positions can be considered investable assets. Expected returns of assets are typically based on their risk. It is unclear how the risk of an LP position would change as slot times decrease, but for the sake of argument, assume it stays constant. Then, the returns to an LP position should stay constant regardless of slot times; hence, if the costs per unit of liquidity decrease, the revenues per unit of liquidity must also decrease. In AMMs, revenues would decrease because more liquidity flows into the AMM. More liquidity means more units of liquidity face LVR. Hence, the aggregate effect is ambiguous. So, it is unclear how the total amount of MEV stemming from LVR would change if slot times change, even though the MEV per unit of value may decrease.

Additionally, decreasing LVR would make AMMs more attractive places to trade because there is more liquidity, meaning that more fee-paying traders use the AMM, leading to even more liquidity. In addition, the user experience benefits from shorter slot times, and the total amount of MEV stemming from LVR may increase with slot times. This is problematic for the protocol, even though users enjoy more efficient trades.

Table 1: Impact of slot times on LVR, the amount of liquidity, and the amount of total MEV. This table shows how the slot time affects the LVR per slot and the factor by which liquidity is multiplied. It assumes that the fee revenues stay constant and the opportunity cost per slot is zero. The results are normalized with the values corresponding to the 12-second slot time used as a baseline.

Table 1 shows that the total amount of MEV originated from LVR may stay the same even if the slot time decreases. The values in this table are generated assuming that fees are the only revenue, latency arbitrage is the only cost for liquidity providers, and the per-slot opportunity cost stays constant at zero. These assumptions are overly simplistic. Therefore, these numbers may present upper bounds on the increased liquidity per slot and, thus, on the total amount of MEV.

It is hard to say how these predictions will hold up. The ecosystem knows little about liquidity providers’ motivations and risk-reward tradeoffs and even less about liquidity traders’ behavior. Perhaps LPs consider the risk of LP positions differently depending on slot times, which could help to predict what happens with the total amount of MEV as slot times decrease.

Potentially, this example can be generalized. Out-of-protocol MEV mitigation techniques that aim to minimize the MEV per unit of value simultaneously induce more value that flows through the system; hence, the impact of MEV mitigation on the total amount of MEV is ambiguous. Therefore, I believe Ethereum cannot rely on out-of-protocol MEV mitigation to prevent the negative externalities of MEV on consensus agents.

Disclaimer:

1. This article is reprinted from [Julian Ma], All copyrights belong to the original author [Julian Ma]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.