Title: Modular MEV; Part 1---The Introduction

Written by: rain and coffee

Compiled by: Yangz, The Path of DeFi

Maximum Extractable Value, or MEV, has always been a hot topic in Crypto. MEV refers to the value extracted from users through the reordering, insertion, and censorship of transactions within blocks, as well as profiting from benign MEV (such as arbitrage, liquidation, etc.). It was first mentioned by /u/pmcgoohan on the Ethereum subreddit back in 2014.

One of the earliest examples of quantifiable MEV occurred during the craze of CryptoKitties. Specifically, to complete a CryptoKitties pregnancy (giving birth to a new cat), anyone could call the smart contract's giveBirth() after the cat's birthing block. Subsequently, users could receive Eth rewards. This could potentially be run in advance, generating profit (MEV). As Markus Koch pointed out in 2018—early in the game's history, there were only a few accounts giving birth to kittens. Over time, other accounts began calling giveBirth() as they saw profits to be made for free. Data shows that only a few midwives accounted for the majority of births.

Top giveBirth callers (midwives) income

Additionally, midwives competed through gas fees (as, despite being relatively average in code efficiency, some midwives appeared more successful and profitable than others in executing giveBirth() calls). The conclusion at the time was that birthing fees made CryptoKitties gameplay more expensive than it would have been without that mechanism. This example illustrates that MEV equates to poor transaction execution for end users, as it inflated gas fees during the birthing period.

Another example is the front-running that occurred on Bancor in mid to late 2017. In June 2017, Phil Daian (co-founder of Flashbots) and Emin (founder of Avax) pointed out this possibility. They indicated that miners would be able to front-run any transaction on Bancor, as miners could freely reorder transactions within the blocks they mined. In August of the same year, Ivan Bogatyy took this further by creating a program that could monitor and execute front-running opportunities on Bancor as a non-miner (just a seeker!). This was possible because the blockchain and its mempools are public. If you want to understand the early MEV world, you can read this nice piece (link).

Since then, MEV has rapidly evolved, becoming an important component of protocol design with the increase in on-chain economic activity and the emergence of DeFi since 2019. With the rise of L2s, bridges, application chains, etc., it is interesting to explore the potential impact of researching the "modular" design space on MEV. But first, we must outline the current participants in MEV.

In the MEV ecosystem, there are various participants. Among them, seekers are typically the most profitable MEV participants (from a first principles perspective, although more "general" value is ultimately captured by builders and validators as they aggregate the value of many seekers). Let’s first explain who they are. It is also worth noting that due to protocol design reasons, some participants collude more than others. Participants (bar users and wallets) include seekers (S), builders (B), and validators (V). Their roles in the MEV supply chain are as follows:

• Seekers: Attempt to find all extractable value on-chain through various methods. Seekers collaborate with builders because they are willing to pay high gas fees to have their transactions included. This is important because many things we take for granted, such as arbitrage and liquidation, are executed by seekers. Seekers bundle transactions together and hand them over to builders.
• Builders: Take the bundled transactions and place them into blocks for the initiators. In addition to the seekers' transactions, several bundled transactions can be combined as a block, and it is also possible to include other pending transactions from users in the mempool; bundled transactions can also be targeted for inclusion in specific blocks.
• Validators: Play a consensus role by validating blocks. They sell block space to profit-seeking seekers and builders, in return receiving a portion of the rewards. Remember that validators earn rewards from issuance (initiators, proof-of-stake, synchronization) and execution rewards (MEV + Tips).

So, why do some people say MEV is harmful, even though it seemingly provides value to the ecosystem and security budget? Because MEV competes through priority gas auctions (PGAs). PGAs are auctions where fees are obtained through competitive bidding for transaction priority. Fee estimators use inflated gas prices from PGAs as a reference, leading users to pay more for their transactions. It should be noted that this was primarily how things operated before MEV-Geth/Boost and Flashbots. After the release of MEV-Geth, most MEV-related computations were moved off-chain, replaced by a permissionless side relay that allows MEV seekers to communicate directly with nodes and other participants. Congestion fees decreased. When comparing the shares of vanilla builders and MEV-Boost, this becomes more apparent.

At its core, the issue stems from the fact that users and bots are in the same pool, regardless of whether they are pursuing MEV.

• Participants have a huge incentive to extort users for profit.
• Participants have a huge incentive to centralize (move closer to validators/builders).
• Although the system is permissionless, extortion can become credible through the centralization of coordinators (regardless of who executes shared layer mechanisms such as ordering, settlement, security, liquidity, messaging, etc.).

Thus, extortion can and will happen (through centralization).

Moreover, the barriers to participating in MEV are rising, leading to further centralization. This is partly due to the fact that seekers must constantly maintain their MEV bots. Competition is brutal, and the code is constantly being updated. If you find an advantage, you are less likely to share it, even though blockchains are open ledgers and will eventually be discovered. The MEV "market," such as Flashbots, is also quite centralized, as the vast majority of blocks flow through Flashbots (70%!), even though the MEV-Boost relay is permissionless and has several endpoints (according to Flashbots, there are 11 endpoints).

It is important to note that they plan to decentralize the entire MEV supply chain, and we believe the Flashbots team is well aware of the nuances of the current implementation. Centralized Flashbots relayers do not directly hold any power over validators. Flashbots also cannot censor transactions unrelated to MEV. Validators can still include transactions that have not gone through Flashbots relays. Flashbots is clearly a centralized force, but an alternative world without Flashbots would likely feel worse. Since participants in MEV-Boost earn higher average incomes than non-participants, this also leads to further centralization of actors leveraging it.

But fear not, the answer has always been "We will decentralize!" However, if Flashbots cannot reach a consensus on the MEV issue (as recently mentioned in Phil Daian's podcast), how will the broader community reach a consensus?

If Flashbots as a system ultimately becomes a DAO, it has the potential to decentralize itself. This is similar to Lido and other protocols here. To escape centralization, many protocols claim they will become decentralized DAOs (eventually), just like Flashbots. You could argue that it merely shifts centralization to more layers. However, adding more layers has limited benefits. Ultimately, in most cases, a little decentralization is better than none. However, this also depends on how attackable that decentralization is.

So, why is the participation of actors so important?

Validators want to collect the most fees/MEV to provide the highest staking rates for their users' Eth. This is one of the incentives for validators to select the highest value blocks created by builders.

Builders will aggregate transactions from users, MEV seekers, and their own private order flow to create the highest value blocks possible.

1. Builders with exclusive private order flow should be able to create the most valuable blocks.
2. A builder's block being continuously included will incentivize more private order flow to reach that builder, as users and seekers want their transactions to be included quickly.
3. Pre-selling future block space so that market makers or protocols can secure block space for their transactions or users.

The dynamics of MEV block production and transaction inclusion inherently create an unfair market. Without direct intervention, the market structure cannot improve. The protocol itself must control the market or have mechanisms to support it (as we have seen). Cooperation among initiators (who hold all the power in the market) seems more concerning, especially in a semi-permissioned, semi-decentralized sequencer setup. However, if confiscation occurs during the extraction of MEV, what reason is there to become a sequencer beyond transaction fees?

If you do not release tokens for security, this is especially true, as you gain security from the base layer. Therefore, it is believed that there must be an SBV (Seeker - Builder - Validator/Sequencer) supply chain. This could also lead to a credible social contract among actors. MEV in reality could also become a "problem," more so attacked at the application level, leaving the protocol without direct interference. However, in some cases, MEV can be seen as increasing the security budget of the underlying protocol.

In the competitive block market, there is competition for block space, and applications will ultimately turn to "MEV" (such as priority gas fees). Builders will not waste block space on unprofitable recoveries. The confirmation speed of MEV transactions is faster. Seekers convert MEV into priority fees, giving transactions higher priority. Thus, applications can incorporate MEV into their designs and leverage it to purchase privileged positions in the block space market within specific protocols.

By enabling seekers and hunters to easily search for favorable predictable state changes that lead to MEV, you can incentivize beneficial MEV, increasing the security and efficiency of the protocol. By combining these profitable actions with the sequencer itself, they can share in the profits. This would place the value chain in the hands of both users and sequencers, while also increasing the security budget of the protocol itself. Therefore, users share the value they create themselves. You can only expand its decentralization with the success and adoption (maturity) of a blockchain.

MEV: Beneficial, Harmful, or Both?

One way to reason about the role of MEV is to view it from the perspective of the chain's economic security. Generally, this is seen as "protecting" the value of the chain, the amount of staked assets, or, in the case of Bitcoin, the amount of funds required for a 51% attack. MEV is an important component of this, as it increases the earnings of validators/miners, thus allowing greater economic value to be staked.

Here are two basic reasoning paths. One path considers MEV to be harmful. The reasoning here is that the value extracted (unbeknownst to users) from users is harmful to the user experience, and mature users can extract value from less mature users. Thus, numerous solutions to prevent MEV have emerged, such as threshold cryptography to encrypt pre-orders of transactions and batch auctions with uniform execution prices, all aimed at preventing or minimizing MEV extraction.

The other view is that MEV is actually helpful. The reasoning here is that MEV extraction increases the (potential) value of block space sold by validators/miners, thus allowing for more profits for these individuals. With higher yields, validators/miners are willing to invest more assets to obtain these yields. This would lead to the chain having more economic security. Another way to achieve this economic security is by artificially increasing yields, issuing more native tokens/rewards. However, this comes at the expense of token holders, as their assets face inflation. If you view MEV from this perspective, it is actually a force beneficial to token holders, as it allows them to benefit from economic security while facing less inflation.

Daily Gas and Earnings of Validators on Ethereum

Ultimately, it comes down to where you want the pain to fall. By allowing MEV extraction, you limit the inflation needed to reach a certain level of economic security, at the expense of user experience. Thus, issuance (inflation) becomes the utility required to achieve certain adoption metrics, which will ultimately allow you to reduce it to negligible amounts, while MEV can contribute to the security budget (and serve as the decentralization of the protocol itself).

However, by preventing or minimizing MEV (if possible), you strengthen the general user experience, sacrificing the interests of token holders, as you need more inflation to maintain economic security. Another perhaps more tenuous argument is that for a fully rational actor, extracting the maximum amount of MEV may not be optimal. Because this would become a burden on users, who would stop actively engaging in economic activities on-chain, thus reducing the total amount that can be extracted over the user's entire lifecycle.

While we viewed MEV through the lens of the base layer in the previous section, the same arguments can also be made at the application level (although we believe these will intertwine with application chains). Research by Mekatek shows that at the DEX level, you either allow arbitrage and benefit LPs, or you do not allow arbitrage and compensate LPs with inflation at the expense of token holders. This is similar to the dynamics we just introduced at the infrastructure protocol level.

So, is MEV good or bad? The fairest answer we can give is that it is both, and neither. From one perspective, certain forms of MEV can be seen as bad, but from another perspective, MEV also has its benefits. Overall, we believe MEV is neither good nor bad; it simply is.

Decentralized Sequencers

When you study MEV in L2, the topic of optimizing how much value to extract becomes particularly important. This is because, at present, most sequencers are centralized. They are fully responsible for the ordering of a block, thus deciding how much value to extract. However, like any centralized point in Crypto, the goal is to transition to decentralized sequencers, at which point you encounter the same incentive game theory as with PoS L1. The economics behind sequencers can be expressed as:

Earnings = Issuance (inflation) + Total Fees Collected - DA and Dispute Resolution Costs

(Keep in mind that there are also overheads to consider in terms of the cost of running hardware).

By preventing or limiting MEV extraction from L2, you reduce the total fees collected, thus decreasing the profits of running a sequencer or participating in a decentralized sequencer network. Additionally, in the case of decentralized sequencer pools, you need to consider various factors.

The need for decentralized sequencers is clear—they decentralize and remove trust assumptions from the centralized team building the rollup. Currently, the way rollup sequencers operate is that there is a single sequencer (run by a team) that executes, batches, and finalizes all transactions. This is clearly not ideal in the case of sequencer failure. Furthermore, it places a significant amount of trust assumptions on the team controlling the sequencer and allowing upgrades, as well as on the multi-signature smart contracts in the case of fraud proofs. They have the ability to reorder transactions and extract MEV. While the current way transactions are finalized assumes that the sequencer will not touch, extract, or extort any MEV or transactions, this provides us with soft finality, allowing the sequencer to finalize immediately after receiving transactions. In some cases, such as ZK rollups, actual finality may take up to 10 hours. If you look at the Starkware SHARP stark verifier contract on Ethereum, you can find a good example, where the ZK proof (recursively proving from numerous transactions) is finalized. This usually occurs every 3-10 hours, starting from the first transaction processed in that batch, which is quite a long dispute time.

This is done to reduce the cost of transactions, putting as many transactions as possible into one proof; otherwise, the cost of transactions would rise sharply. This is how transactions are finalized in a rollup—they receive a guarantee of soft finality, meaning they will ultimately be finalized on the underlying layer (in this case, Ethereum). In the case of Optimistic rollups, transactions are instead batched, with the state root (similar to ZKRs) sent to Ethereum's L2 contract along with calldata (transaction state, which is just the state difference of ZKRs). Due to the requirements of the dispute period (the ability to roll back fraudulent transactions), the actual final outcome of Optimistic rollup transactions occurs around 7 days later. This means their actual soft finality guarantee lasts quite a long time, allowing observers to prove any fraudulent behavior that has occurred. These are all issues we need to address in decentralized sequencer pools; soft finality needs to be guaranteed, final finality needs to be achieved, while allowing proofs (validity or fraud) to function as expected.

Below is an image of how rollups currently operate:

Keep in mind that when you rely on L1's consensus, L2's finality is not finality. When you move on-chain consensus from the rollup to the underlying "settlement" layer, this is part of the trade-offs you make. Unless you also handle consensus on the rollup (which would lose derived security but gain sovereignty and leverage the DA layer to ensure data availability). However, the obvious trade-off here is that you split liquidity, increasing the difficulty of interoperability.

Next, let’s explore some possibilities for decentralized rollup sequencers and what impact this would have on MEV.

First, decentralized sequencers mean removing our trust assumptions of a single sequencer run by a team with incentives not to touch MEV or reorder transactions. This provides some "protection" against MEV. However, when it comes to decentralizing the sequencer pool through token binding, it opens up the possibility of permissionless or semi-permissioned validators/sequencers extracting value, as they have already been committed to the rollup's tokens (like the Fuel token model). This means there needs to be a mechanism to ensure the correctness of block ordering and appropriate penalties. The reason for this is to ensure that the sequencer pool remains valid, fair, and does not infer transactions. For example, reordering to place their transactions at the front of the pool—even if they pay less gas fees—usually requires a public mempool or guarantees of inclusion.

Here are some examples:

• PoS proof leader election. This could be similar to the leader election in Tendermint (as we obtain consensus from the base layer) and a penalty module (like the Cosmos SDK module). This is a solution that most rollups I have spoken with seem to adopt. However, there are other options. For PoS, if you allow the largest holders to receive the highest percentage of blocks, it will inevitably lead to centralization. Alternatively, you could switch to MEV auctions, as you bid with opportunity cost rather than direct payment.
• Fair ordering (Arbitrum particularly focuses on this issue). To make it work, you also need a forfeitable bond (to maintain the essence of fairness, it could be the same for everyone). In this setup, you "pay" [opportunity cost per block * number of staked blocks] to gain the right to extract MEV during that period. To make fair sequencing work, you need a fair sequencing protocol that selects a fair event sequence to finalize. This is usually achieved through an honest majority assumption, such as a prioritized service ordering of transaction lists merged by various sequencers. Thus, the system is first-come, first-served, with a 51%-N honesty assumption. In the case of dishonesty, the system can commit to a social fork (if they have sovereignty).

The issue with the second option is particularly that it turns into a race against time, likely leading builders and seekers to cluster as close as possible to the relevant sequencer (as we see in TradFi, and even in the crypto world through optimizing network latency). This clearly leads to geographical centralization.

Additionally, there has been some discussion around MEV auctions (bidding for the rights to extract MEV and propose blocks) to gain ordering slots (especially from the Optimism camp). However, we believe that while it has a permissionless nature, it still pushes towards centralization, and its entry barriers are very high. While some of the methods mentioned earlier may also lead to "centralization," they are less obvious and less harmful to the protocol.

In general, fair ordering mechanisms do not "prevent" or mitigate MEV in any way without adding considerable negative impacts. However, methods like threshold cryptography, time-lock puzzles, batch auctions, and meta mempools (decoupling the roles of mempool and block builders from the shared aggregation/sequencer layer—this could become useful in the cross-domain MEV space, which we will touch on later) may be more successful in providing such properties.

Now that we have seen how sequencers currently operate and some possible methods for decentralization, let’s try to imagine what a decentralized sequencer pool would look like and what it needs to maintain finality guarantees and ensure the protocol functions as expected.

Example of fair ordering in decentralized sequencers

Above is the sequencer setup in a smart contract rollup, and below we will show what a sovereign rollup (a rollup above the DA layer) would look like through PoS leader election. In a fair ordering setup, there is little motivation to purchase and stake the required tokens to become a sequencer, and the overall cryptoeconomic security of the sequencer pool remains relatively low.

Example of decentralized sequencer PoS leader election

In this setup, the operation is quite simple—when selecting a sequencer for a round, the committee simply uses a weighted round-robin method based on staking ratios. With this method, any validator can easily calculate the eligible initiators for a given round. If you want to read about NMTs on Celestia, check out our data structure article. (Keep in mind that in this setup, the dispute window could potentially be reduced, as you are not in a competitive block space like Ethereum).

Additionally, there has been some research and discussion around randomizing leader elections (2017 on the Tendermint repo), which could also be a method to achieve a setup similar to fair ordering, but requiring a random initiator (leader) rather than a first-come, first-served approach. While this does not incentivize sequencers to purchase and stake more tokens (weighted round-robin incentives), it could lower the economic security of the protocol.

The differences in MEV extraction between the two different setups could lead to different distributions and extractions of MEV. There are also other issues to consider, such as finality guarantees and methods for suppressing MEV, which we will discuss in the second part regarding the various participants filling the modular MEV space and how collusion occurs. We will also explore the setup of shared sequencers and meta mempools—so stay tuned for another part in the coming weeks.

Finally, a big thank you to Mathijs van Esch for contributing to the writing of this article, and to Josh Bowen for the initial discussions that led to this series of articles. Thanks to Mekatek for the review.