Unbundling MEV Supply Chain Part 1: History and Evolution

By Chris Maree, Venture Partner at Hack VC

Introduction

Maximum Extractable Value (MEV) has become increasingly prevalent over the last few years, drawing parallels with high-frequency trading in traditional markets but operating within the realm of decentralized systems. At its core, MEV refers to the value that can be extracted by the strategic reordering, insertion, and censorship of transactions within a block. MEV involves many actors along the lifecycle of a transaction. From submission to eventual inclusion within a block, this lifecycle can be modeled as a “supply chain.” This article, which is the first part in a two-part series, breaks down the MEV supply chain by looking at the evolution of the actors involved as the MEV space matured. The second part will examine  how the disintermediation of actors along the supply chain can create new revenue opportunities for projects and explore the future of MEV internalization.

Overview and history of MEV

The essence of MEV

Before diving into the evolution of the MEV supply chain, it would be helpful to outline the essence of MEV to provide some important context. 

MEV is derived from the privileged position a block producer has when constructing a block. A block producer can choose: (1) what transactions to include, (2) the order in which to include them, (3) and whether they’d like to insert their own transactions. MEV is derived from the exploitation of this privilege to extract value from other transactions within a block.

Decentralized Exchange (DEX) arbitrage serves as an illustrative example of MEV in action. In the Decentralized Finance (DeFi) ecosystem, different DEXs often momentarily display varying prices for the same asset due to differences in liquidity or trading volumes—or simply the asynchronous nature of blockchain updates. DEX arbitrageurs monitor these price discrepancies across exchanges. When a disparity is detected, their bots swiftly buy the asset at a lower price from one DEX and sell it at a higher price on another, pocketing the difference.

The window of opportunity, however, is often fleeting. To ensure their trades are executed before the price discrepancy resolves naturally (or before someone else takes it), arbitrageurs often pay higher fees or use strategies like frontrunning to ensure that they capture the opportunity. The MEV here represents the potential profit the arbitrageur can extract from the transaction sequence, minus the attendant costs, such as gas fees. This is, of course, just one example of MEV; the current MEV landscape is vast and complex, with many different sources and strategies of extraction.

The evolution of the MEV Supply chain

Now that the basic foundation is laid, we can build up the actors within the MEV supply chain by analyzing its evolution.

Early days (pre-flashbots)

In the early days MEV was extracted by searchers (sophisticated users specialized in the identification and extraction of MEV opportunities) submitting transactions with high gas prices to try and influence their transaction’s position within a block to extract MEV from other transactions in the same block. Some examples of MEV in the early days include:

• DEX arbitrage due to price discrepancies between exchanges
• Transaction sandwiching of poorly specified DEX trades with high slippage
• Back-running oracle updates, enabling searchers to win liquidations

Priority gas auctions

It didn’t take long for others to catch on to what was happening and a battle over MEV ensued through Priority Gas Auctions (PGA). PGA effectively operated by bots bidding simultaneously for inclusion within a block, submitting progressively increasing gas bids to try and outcompete the other bot’s bids. The graph below is taken from the pivotal paper on DEX frontrunning from 2019, Flashbots 2.0 which showed an early PGA where auction participants bid with sequentially increasing gas prices to influence their order within a block.

Another strategy employed by searchers at the time was to spam the network. At this time, Geth (the majority ethereum client) ordered transactions by gas, first, and then randomly thereafter. Searchers aiming to land a back-run transaction immediately after a target transaction would spam the network to increase their chances of landing directly behind the target transaction. Geth was eventually updated to include transactions ordered by receive time, rather than randomly, if they had the same gas price. This removed the incentive to spam the network to backrun transactions. The problem still remained, however, that there was no explicit venue to bid on blockspace and the allocation thereof, with the only meaningful way to influence the position of a transaction within a block being paying higher gas prices as compared to the other transactions in the mempool.

Impact on Ethereum network

The effect of PGA bots bidding to backrun public transactions and the resultant network spam was the degradation of the user experience on Ethereum L1 for all other users, with gas prices regularly reaching the high hundreds of Gwei. This resulted in a number of undesirable externalities on the Ethereum network, including:

• Failed MEV transaction attempts that landed within a block but did not capture MEV used valuable block space, which filled blocks with useless reverts rather than meaningful user transactions
• Gas price was artificially inflated due to the PGA compared to the “true” demand on-chain, meaning that searcher behavior made all other user transactions far more expensive than they needed to be
• Gas price volatility made it difficult for users to consistently and correctly price their transactions, meaning that transactions would often get stuck due to the gas being priced too low low, which often required users to re-submit transactions, resulting in a slow and confusing UX for users
• Miners had an unfair advantage in MEV extraction as they did not need to bid within the public mempool to extract MEV (they could arbitrarily reorder transactions), which created a centralizing force for miners because sophisticated MEV extracting miners would have better unit economics compared to standard miners (more on this later)
• Spam transactions placed a larger-than-necessary load on node operators, with the mempool being flooded with many repeated transactions

The graph below shows the volatility of Ethereum gas prices during the period around the start of DeFi summer (early August 2020) when the primary venue for influencing transaction ordering was PGA.

MEV supply chain pre-flashbots

At this point in its history, the MEV Supply chain with PGAs looked like the diagram below. Here, we had the transaction sender submitting their transaction to the public mempool, searchers looking within the mempool for opportunities, and miners taking transactions directly from the public mempool to include into blocks. For searchers to express preference on their transaction ordering to influence their positioning within a block, the only variable they had was the gas price of the transaction sent to the public mempool. This was insufficiently expressive for searchers and suboptimal for the whole network as searchers drove up the price of gas through PGA.

It is important to note that, at this point in its evolution, the supply chain had minimal trust assumptions. In theory, miners could have started extracting MEV for themselves. This would have created a dramatic centralization force due to the privilege a miner had in the block construction process. Fortunately, Flashbots launched before this could happen.

MEV-Geth (pre-Merge)

Flashbots launched on mainnet in January 2021 with the launch of MEV-Geth. MEV-Geth functioned by receiving transactions from searchers and forwarding them directly to miners, via the Flashbots relay. The key innovation was removing the need for searchers to send their MEV transactions to the public mempool and rather bid via a sealed bid blockspace auction within a separate, private mempool (MEV-Relay). This allows expression of preference at a more granular level than via the public mempool PGA. The bid acted as a direct ETH transfer to block.coinbase, the address that produced a given block (i.e the miner for that block).

Impact on Ethereum network

MEV-Geth effectively protected the public mempool from the searchers’ bids, thereby removing the negative impact they had on gas price through PGA. This protected users from the negative externality of MEV bids by de-coupling the demand on MEV block space and the resultant network wide gas price.

The introduction of bundles

MEV-Geth also introduced the concept of bundles via a new RPC endpoint, eth_sendBundle. Bundles consist of one or more transactions to be included within an atomic batch. This provided searchers with the ability to be more expressive in their MEV extraction techniques, including multi-transaction strategies, such as sandwich attacks (note that sandwiching did exist before bundles, but only in a non-atomic form). 

To understand sandwiches and why bundles are important, consider a poorly specified DEX trade that has a larger-than-required slippage tolerance. A searcher can sandwich this trade by placing a front-run transaction directly before the swap and a back-run transaction directly behind the swap, thereby “sandwiching” the target swap between the two transactions. The searcher’s transaction bundle would move the price upwards before the user’s swap occurred and then downwards after it to normalize the price discrepancy, capturing the spread created by the user up to their slippage tolerance. The bundle would ensure that either both of the searcher’s transactions were included as specified, or neither (atomic), making this kind of attack cheaper and risk-free in many cases. Before bundles, this kind of atomic action was not possible.

Flashbots relay

The flashbots relay existed between searcher and miners and acted as a mutually trusted intermediary. It existed for two main reasons: (1) to protect the miners from spam by handling all inbound searcher transaction payloads, ensuring that only valid transactions were sent to the miners and (2) to make the process of a searcher finding a miner easier through a single standardized interface. A miner runs MEV-Geth to evaluate all incoming bundles from the relay and chooses the bundles with the most profitable transaction ordering. After building a block, MEV-Geth compares the block to a regular Ethereum block to see which pays the builder more. If the block containing flashbots bundles is more profitable, MEV-Geth starts mining on it—otherwise, the client mines on the regular Ethereum block.

Laying the foundation for the supply chain

MEV-Geth created a clear separation between actors who search for MEV and miners, intermediated through the relay. This separation laid the foundation for the MEV supply chain through different actors taking on specialized roles. 

Relative to PGAs, MEV-Geth auctions provided a number of desirable properties, including:

• Failed transactions and bundles were not included in blocks, unlike before where attempted MEV extraction resulted in blocks being spammed with many failing transactions
• The fair value of blockspace was directly distributed to miners via blockspace auctions, which increased the Ethereum security budget (through increased payments to miners)
• Blockspace auctions were moved away from the public Ethereum mempool and into the MEV-Relay, which critically reduced congestion on the network and fixed a number of critical UX issues that PGA created
• Gas prices on mainnet represented a more accurate “true” demand for block space through the removal of spam transactions and PGA bidding
• MEV extraction was more accessible and targeted, meaning that there was no longer an incentive for miners to extract MEV in-house, reducing the centralization risk of miners

The most competitive MEV opportunities, such as top-of-block atomic arbitrage and trade sandwiching, saw searcher bids approach the total size of the opportunity. This was due to complete information being shared between all searches due to the public nature of the mempool. As a result, almost all MEV that could be extracted from these kinds of opportunities was captured by miners. The searchers with the most gas efficient and highly optimized strategies were those that ended up winning these auctions because they could afford to give more to the miner while still making a profit.

MEV-Geth MEV supply chain

The diagram below shows the MEV supply chain with flashbot's MEV-Geth auctions. Here, relays have been introduced into the supply chain. Transactions are sent by users to the public mempool directly. Searchers observe the mempool and when they detect MEV opportunities, rather than bidding directly in the public mempool via a PGA, they submit their MEV extracting transactions to the MEV-Relay in the form of bundles. The MEV-Relay then passes the bundles onto the miners who construct the block.

Trust Assumptions

The introduction of the MEV-Relay added a number of important trust assumptions not present before MEV-Geth. In this design, both the miner and the relay had some degree of trust placed on them. The miner had full access to bundle content and could arbitrarily reorder/steal/censor bundles sent to MEV-Geth by searchers and relayers. This meant that, in theory, they could un-bundle MEV-bundles sent to them and steal the MEV for themselves. They were incentivised, however, not to do this, as Flashbots monitored for misbehavior and would remove miners that misbehaved. As the vast majority of mining was done through mining pools, this became a strong incentive to not steal MEV rewards as a whole mining pool being banned from Flashbots would cost miners disproportionately more than the marginal benefit they would make from stealing a single block’s MEV, not to mention the reputational cost. This was effectively a repeated game: play nicely now (and into the future) to maintain access to the MEV infrastructure. If you misbehave, even once, you lose all future access to the infrastructure. This keeps miners honest as they need to compare the instantaneous amount of MEV they can steal from unbundling one block's worth of MEV against all future rewards they can make by playing by the rules.

The relay was trusted by the searcher to not sensor/unbundle or steal their MEV and was trusted by the miners to send them the most profitable blocks and not withhold blocks. Flashbots was incentivized to not defect due to loss of social capital and market share should they become a bad actor.

MEV-Boost (post-merge)

The Ethereum ecosystem underwent a monumental shift with the Merge in September 2022, transitioning from a proof-of-work to a proof-of-stake consensus mechanism. This change, while significant in its own right, also brought about a new chapter for MEV with the launch of MEV-Boost. Today, we are in a post-merge world, with MEV-Boost defining the MEV landscape. 

Out-of-protocol proposer builder separation

MEV-Boost allows Ethereum validators to source fully built blocks from a competitive block builder marketplace. This effectively achieves out-of-protocol proposer-builder separation (PBS) as an interim solution while in-protocol PBS is developed over the coming years. PBS separates the processes of building a block and proposing a block (i.e., the “builder” and “proposer” are separated). By default, post-merge blocks are constructed by the validator who chooses the most profitable transactions to include from the mempool, while trying to build the fullest blocks (they are both the builder and proposer). MEV-Boost block construction is outsourced to more sophisticated actors, called builders, who can construct more optimal blocks through better compute, private order flow, and importantly connections with searchers who find MEV opportunities. This separation between the building and the proposing of a block amounts to out-of-protocol PBS. 

MEV-Geth vs MEV-Boost

Under MEV-Geth, the miner was still responsible for building blocks and was only given bundles from the relayer. Under MEV-Boost, the builder gives a fully constructed block to the proposer (validator). This reduces the computational complexity of running a validator, as the validator no longer needs to build blocks. This also enables validators to continue running on consumer-grade hardware while still being competitive with more sophisticated actors as they’ve outsourced the difficult part of building the most profitable block. This unbundling keeps naive validators competitive with more sophisticated validators since they both source blocks from the same set of builders. This hardens Ethereum’s decentralization and censorship resistance and, in the long term, can facilitate protocol designs that require much more complicated and intensive block building, such as Danksharding, without bloating the validator requirements.

The introduction of the builder enabled further specialization along the supply chain, with clearly delineated roles between the discovery of MEV opportunities, the construction of optimal blocks, and the proposal of blocks. Builders use private order flow and the public mempool and take transactions from searchers and package this all together to build the most optimal block.

MEV-Boost supply chain diagram

The diagram below shows the actors in the MEV supply chain at present under MEV-Boost. Here, users submit transactions to the public Ethereum mempool. Searchers identify MEV opportunities from the mempool and send their bundles to builders who try to construct optimal blocks with inputs from searchers, the public Ethereum mempool, and private orderflow. These constructed blocks are then passed to the proposer (validator) via the relay.

There are also some alternative transaction flows, such as users submitting their transactions to shielded mempools (like MEV-Share or MEV-Blocker) wherein searchers are given partial information on the users’ transaction. These services act to kick back parts of the MEV to the user who submitted them and add additional actors to the supply chain. Part two of this article will go deeper into how these kinds of services affect the supply chain and how this creates new opportunities for protocols.

Trust assumptions

Under MEV-Boost, builders abstract block building away from validators, which makes running a competitive validator more accessible. The centralizing effects are not eliminated; rather, they are moved to the block builder layer. Given no MEV opportunities and a public mempool, it’s easy to construct the optimal block simply by ordering to maximize builder fees against the finite resource of block size (each block can contain, at maximum 30mm gas; order transactions by those that pay you most to fill the finite block size, i.e., knapsack problem). This means that, in the absence of other advantages, all builders will have an equally profitable block. But other advantages are not usually absent, and so profitability at the builder level comes from advantages that other builders don't have.

As a general matter, a block builder that can construct more profitable blocks will win more block auctions. There are three main differentiating factors between block builders: (1) the quantity and quality of bundle flow from searchers, (2) the private order flow to which they might have access, and (3) whether they extract their own MEV (vertically integrated searcher + builder combos) through techniques like CEX/DEX arbitrage.

Searchers will only send bundles to builders that provide a fair auction and strong bid privacy guarantees. Additionally, searchers need to be confident that the builder they send their bundles to has high validator penetration to ensure that inclusion times are as low as possible. This creates a centralizing force through the self-perpetuating cycle of the biggest builder getting the most flow, which results in better block construction, creating more revenue for validators and incenting more validators to connect to that builder via their relay selection. Additionally, if searches only send their bundles to one particular builder, this acts as private bundle flow, meaning that these builders have a better chance of constructing more profitable blocks. The same is true for receiving private order flow, with which block builders that have better insight into where transactions are coming from and are privy to transactions that other builders are not can build better blocks. 

Lastly, builders can also extract their own MEV. Builders have an unfair advantage in this regard over searchers as they are not limited to bundle abstraction and can thereby extract MEV in ways that are not normally accessible to searchers. A clear example of this is end-of-block arbitrage. Searchers currently capture end-of-block arbitrage by being at the top of the next block. If a builder is extracting MEV, then they can place transactions strategically in the final position of the block and capture this MEV for themselves(the same goes for top of block arbitrage). Only the builder has absolute control of this kind of precise ordering, giving them an unfair advantage compared to searchers with respect to these kinds of strategies. In short, builders that can execute successful top and end-of-block arbitrage will win more blocks than other builders.

Resultantly, the current MEV-Boost supply chain sees trust placed in the builders as well as centralizing forces due to economies of scale and benefits from vertical integration at the builder level (i.e., searcher-builder integration). The rest of the supply chain has pretty similar trust assumptions to MEV-Geth. Relay is still trusted by both searchers and proposers (previously mining pool) and validators have similar trust assumptions placed in them.

Conclusion

The MEV ecosystem has evolved from a simple, inefficient system creating negative externalities on the Ethereum network to a sophisticated supply chain with discrete actors. In this article, we examined the evolution of this supply chain, from its infancy to present day, and looked at the trust assumptions and design space along this history. 

Part 2 will examine how this supply chain is evolving into the future and explore how the internalization of MEV by different actors along the supply chain can create new revenue opportunities for protocols and users alike.

The information herein is for general information purposes only and does not, and is not intended to, constitute investment advice and should not be used in the evaluation of any investment decision. Such information should not be relied upon for accounting, legal, tax, business, investment, or other relevant advice. You should consult your own advisers, including your own counsel, for accounting, legal, tax, business, investment, or other relevant advice, including with respect to anything discussed herein.

This post reflects the current opinions of the author(s) and is not made on behalf of Hack VC or its affiliates, including any funds managed by Hack VC, and does not necessarily reflect the opinions of Hack VC, its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC. Certain information contained herein has been obtained from published sources and/or prepared by third parties and in certain cases has not been updated through the date hereof. While such sources are believed to be reliable, neither Hack VC, its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC are making representations as to their accuracy or completeness, and they should not be relied on as such or be the basis for an accounting, legal, tax, business, investment, or other decision. The information herein does not purport to be complete and is subject to change and Hack VC does not have any obligation to update such information or make any notification if such information becomes inaccurate.

Past performance is not necessarily indicative of future results. Any forward-looking statements made herein are based on certain assumptions and analyses made by the author in light of his experience and perception of historical trends, current conditions, and expected future developments, as well as other factors he believes are appropriate under the circumstances. Such statements are not guarantees of future performance and are subject to certain risks, uncertainties, and assumptions that are difficult to predict.