Base Playground on-

The key takeaway here is that the extraction of MEV has created a competitive supply chain for user transactions, with many actors vying for a share of value. Whenever a validator running MEV-boost is proposing a block, all transactions in that block have gone through at least one competitive auction (block level auction), usually two (searcher auction) and possibly even three (order-flow auction, “OFA”, see our report on OFAs for further reading).

It is paramount to have an understanding of this supply chain and the fundamental motivators behind the actors in it, for how we address MEV will determine whether crypto will ever be able to reach its potential as a truly decentralized and open ecosystem.

In the rest of the article, we will dive deeper into how the externalities of MEV extraction have shaped the market into what it is today, what are the downsides of the current system, and how we might see a shift from this simple “MEV supply chain” into a “transaction supply network” [3].

Blockchain transactions have not always been subjected to such a game. So how did we arrive at the current MEV ecosystem? In this section, we provide a brief overview of the story so far.

Block proposers (miners/validators) having the ability to extract value out of pending transactions through reordering has been a concern even before smart contracts and DeFi were a thing. The idea of miners potentially being able to use their privileged position in transaction inclusion to extract profit was first discussed in 2013.

Back then, Peter Todd, a Bitcoin Core developer, offered a bounty of 2.48 BTC for anyone who was able to show a hash collision against the SHA-1 cryptographic algorithm [4]. The proof was to be submitted on-chain, which proved to be problematic. A miner aware of the bounty could see the bounty-collecting transaction, reorganize the chain to block the transaction and thus claim the reward for themselves. While it was not called MEV then, this was one of the first known times miner’s ability to extract value out of users’ transactions was acknowledged.

For the reorganization of transactions to be worthwhile, there needs to be some sort of value to capture. The lack of more complex use cases than peer-to-peer transactions, like DEX trading or lending protocols, on native Bitcoin means that miners do not have much reason to reorganize blocks. Because of this lack of expressivity in Bitcoin transactions, there are few ways to extract MEV on Bitcoin without attacking the consensus of the entire chain (e.g, intentional reorgs). Extracting MEV by attacking consensus is an order of magnitude more difficult than extracting MEV on Ethereum. The small size of the opportunity and the difficulty of extraction have meant that MEV extraction has not garnered a similar level of attention on Bitcoin as it has on other ecosystems. [5]

While the threat of MEV was known before smart contract blockchains like Ethereum existed, the concerns around reordering attacks became much more serious after Ethereum and other general purpose blockchains started gaining traction.

In the Ethereum ecosystem, reordering attacks were first thought of in 2014 in a post on the Ethereum subreddit [6], in which an ETH researcher, pmcgoohan, wondered what was to stop a miner from frontrunning traders on marketplaces built on top of Ethereum, given the miners autonomy in block construction. There were many different suggested solutions, even by Vitalik, but no clear answer to the problem was identified.

While MEV was identified as a problem (without the term being coined yet), discussion around the topic only really started picking up steam after the first DeFi applications gained adoption and brought with them the first major sources for extractable value: liquidations (DAI in 2017) and DEX arbitrages (0x and EtherDelta in 2017, first wave of AMMs in 2018 with Bancor and Uniswap).

Early analysis of these decentralized exchanges showed ways in which users could suffer from frontrunning due to miners reordering transactions to their advantage. In the paper “The Cost of Decentralization in 0x and EtherDelta” [7], a team of researchers described the same frontrunning phenomenon as pmcgoohan did 3 years earlier. The authors estimated that in practice they could be able to extract nearly 1 million dollars a year running an arbitrage bot on these early exchanges. James Prestwich was also early to raise the issue of miners potentially extracting value from users in his post “Miners aren’t your friends" [8] from January 2018, illustrating how miners could reorder, insert and censor transactions to extract value from users.

Still, discussion around these issues did not really kick into full gear until 2019 and the Flash Boys 2.0 paper [9] by Daian et al., where the term Miner Extractable Value was first coined and formalized. In the paper, the researchers documented the practice of bots searching for pure-profit opportunities (searchers), like arbitrages across decentralized exchanges, and raised concerns over the potential risks for Ethereum, if these bots were left unchecked. At this point, the focus was more on the consensus-level risks to Ethereum rather than on negative externalities to the user experience. The fear was that the existence of MEV could make a 51% attack profitable if a miner was able to use significant resources to reverse the chain's history and extract all the available MEV in previous blocks for themselves (so-called time-bandit attacks [10]).

This was before there was any off-chain infrastructure to settle execution rights between searchers, which meant that competition for opportunities was happening on-chain either through priority gas auctions (“PGAs” - see section 6.1) or backrunning. This on-chain competition had a few undesirable externalities that affected not just searchers, but Ethereum users as a whole, including network and blockspace congestion (including more volatile/higher gas prices). Because there was no open market for searchers to compete for opportunities as is today, there was a trend towards vertical integration between miners and searchers. Some mining pools started cooperating with trading firms to ensure that specific searchers' strategies were included by their miners over others.

The negative externalities of handling MEV on-chain led to the founding of Flashbots [11] (section 6) in late 2020. Flashbots is a research and development organization which was formed to illuminate the dark forest of MEV, democratize the extraction of it and distribute the gains. The main concerns that Flashbots wanted to alleviate at the time were congestion of both blockspace and the networking layer due to searchers competing in PGAs (more on this later) and the aforementioned time-bandit attacks.

The first solution that Flashbots released was MEV-geth (section 6.2), an off-chain auction for MEV settlement. It allowed any miner to connect with searchers who were seeking to extract MEV.

Before Flashbots, the only stakeholders in the ecosystem were the searchers and the miners/mining pools. After MEV-geth was released, relays were added to the MEV extraction supply chain as a trustless communication channel between miners and searchers. The move to Proof of Stake brought with it fears of sophisticated staking providers causing consensus-level centralization. To address this, after the merge, Flashbots released MEV-boost to separate the roles of the block proposer and the block builder to increase specialization and avoid centralization at the consensus level (section 6.4).

We have now covered the definition of MEV, the history of value extraction on blockchains and how that has lead us to the current supply chain on Ethereum. Seems like MEV is one of the most important topics for protocol and application designers, but how common is this value extraction from users really and what does it look like in practice?

MEV comes in many shapes and sizes. Thinking about how we can classify different phenotypes of MEV allows us to better understand what is creating MEV, who suffers from the negative externalities of MEV extraction and what solutions would be feasible and most effective to address them.

While there are many different ways to think about the MEV market, here we present the following categorizations of MEV:

1. 1. EV_ordering & EV_signal
2. 2. On-chain MEV & off-chain MEV
3. 3. Mafia, Moloch, & Monarch EV

One way to categorize MEV, presented by Frontier Research in “A new game in town” [12], is to consider what kind of information the extraction of value requires, and where this information is sourced from. Based on this, we can split MEV into EV_ordering and EV_signal.

The key differentiator between these two categories is whether the extraction of value can be done purely with information relating to the blockchain, its current state and pending transactions in the mempool, or whether information outside the system is required.

• In the first case, the value is called EV_ordering because extraction happens purely by reordering, adding, or removing transactions in a bundle/within a block(s) [13] and is based on the current state of the blockchain and its mempool.
• The extraction of EV_signal, requires some information outside the blockchain (a signal) in addition to the state of the blockchain and any pending transactions a searcher might be targeting. The most common signal is the price of a token on a centralized exchange.

One related concept that is important to understand here is that of atomicity.

• MEV is atomic if it consists of only one “leg” of extraction, usually a single bundle that reverts if any of the transactions required for MEV extraction fail. Because of the reversion guarantee, an atomic searcher assumes no risk. EV_ordering is an example of atomic MEV, because the value is extracted immediately in one leg, and the searcher is guaranteed profit if their bundle gets included in a block.
• On the other hand, non-atomic MEV consists of multiple legs, each of which has to succeed for the MEV extraction to be profitable. A non-atomic searcher takes execution risk. They might take a loss if one of the legs of the extraction fails, e.g., due to competition against other searchers. Profit is only statistically likely, which is why this type of MEV is sometimes called statistical arbitrage. The main example is CEX-DEX arbitrage more on that in the next section. EV_signal is classified as non-atomic because extraction of value requires multiple legs.

Another important distinction is that of on-chain vs. off-chain MEV.

• On-chain MEV refers to MEV that is fully extracted on-chain. While all EV_ordering is also on-chain, these terms are not equivalent because there are also on-chain MEV extraction strategies, where the extraction is not instant which thus fall under EV_signal.
• Off-chain MEV refers to MEV that where extraction takes place in both an off-chain venue and an on-chain venue. This means that there is more than one leg required for extraction to be successful, and thus all off-chain MEV falls under EV_signal (but not necessarily the other way around).
• It is significantly easier for us to identify how much MEV is extracted on-chain, because all the information about MEV bundles submitted to the chain is public on the blockchain.
• On the contrary, off-chain MEV is much harder to evaluate, because we usually do not have access to information on the off-chain leg (e.g., trades on Binance) of the extraction.

A third way we can look at MEV is to consider who gets to extract (or whether it is extracted) the MEV and why. This categorization (3EV model) was first presented by Xinyuan Sun, in 2022. [14] The model identifies three main ways that MEV is created on blockchains:

1. 1. Mafia EV: the value that can be extracted due to some parties having asymmetric information about other parties’ actions/intents. One example of this is sandwiching users (see next section).
2. 2. Moloch EV: the value that could be (but is not) extracted due to a lack of coordination in the system. As an example, non-atomic strategies usually involve some risk which reduces the amount that searchers are willing to bid for opportunities. The difference between their current bid and what they would bid maximally is lost or surrendered to the Moloch.
3. 3. Monarch EV: the value that accrues to the party (“monarch”) that has the ultimate control over the ordering of transactions and thus the future state of the system, like validators or sequencers.

The definition above is mutually exclusive and completely exhaustive, therefore the total sum of MEV = Mafia + Moloch + Monarch.

MEV is often divided into good and bad types, based on their externalities for users and the ecosystem as a whole.

• We can think of anything that falls under Mafia and Moloch EV as bad MEV. They arise from undesirable inefficiencies or asymmetries in our systems, which should build solutions to address. Ideally, we can turn both the Mafia and Moloch EV completely into Monarch EV. We can then build solutions that distribute the rewards from the monarch back to the users.
• On the other hand, liquidations (see section 5.3) are a canonical example of a good type of MEV. As is common with other types of good MEV, liquidations involve incentivizing sophisticated entities to provide a valuable service in exchange for the MEV they extract, which would be hard to implement in protocol. [15]

Now that we have an idea of how to categorize different types of MEV, how much value extracted falls under each type?

The amount of MEV available in each block varies widely depending on the general market conditions and transactions available in the mempool. MEV opportunities are usually most abundant in high volume and volatility environments because users are often willing to trade with bad execution (to de-risk quickly) or because prices are moving quickly on off-chain exchanges. These conditions create systemic dislocations that result in arbitrage and liquidation opportunities. Examples of this include the Terra/Luna collapse, USDC depeg or FTX collapse.

It is also important to understand that MEV is defined as maximal extractable value, which is the hypothetical maximum that can be extracted from the blocks. This is different from the actual extracted value from the system. There are many MEV opportunities that are never extracted, e.g., due to not being profitable enough or the opportunity being too niche. The true extracted value is also not fully visible to us, because we lack the methods to track off-chain or non-atomic MEV.

Because our data collection methods are limited, the numbers below represent only a subset of the true extracted value on each chain, the so-called Quantified Extracted Value. Below we provide a lower bound for the MEV extracted on selected chains where relevant data is available for 2021 and 2022. [16]

These figures might seem relatively small at first glance. They might even make one question the mental effort that is spent on engineering solutions for MEV. We will see later in this article how the incentives to compete in this MEV extraction game can, in the worst case, result in a centralized, monopolistic ecosystem with very high barriers to entry.

This is why MEV is regarded as an existential issue to blockchains. We see this resulting from two main negative externalities:

1. 1. Centralization: MEV is a threat to decentralization. Due to the nature/structure of the MEV marketplace, if left unchecked, it leads to centralization at the builder/validator level. This might result in censorship, geographic centralization (& exposure to regulatory capture), and other dystopian futures that make a truly decentralized and permissionless blockchain impossible.
2. 2. Worsened user experience: Some MEV strategies, like sandwiching, result in worse execution for users (high slippage) or unprofitability for liquidity providers (CEX-DEX arbitrage). On certain blockchains, dominant strategy for searchers is to simply spam transactions to extract value, which increases congestion and transaction fees.

So, the real cost of MEV, which is much harder to quantify, is an opportunity cost. The value that is lost by not having a truly decentralized ecosystem and lower protocol adoption due to subpar user experience compared to centralized alternatives. [15] We must address MEV in a way that aligns the incentives of the different participants in the market in a way that ensures decentralization and democratizes access to the benefits.

The importance of addressing MEV is also validated by the continued interest of both founders and investors in building solutions addressing the negative externalities of MEV. Fundraises from companies like bloXroute, Flashbots, Eden Network, Skip & Jito among others support this.

Competition between solutions is fierce and will drive margins lower than they are today. Despite this, we believe there is significant value that can be captured. Highly technical teams can build a moat by compounding their early-mover advantage and building solutions that grow the pie of total on-chain value. Even if their sliver of the pie is smaller, a larger pie means that these teams will be able to capture higher absolute revenues.

In an ideal world, we would not have to bear these negative externalities from MEV. We need to build solutions that align the incentives of the different stakeholders involved in value extraction with those of end-users. Who are these entities exactly, and what incentivizes them to participate in the MEV supply chain?

We briefly mentioned the main stakeholders in our earlier illustration of the transaction lifecycle on Ethereum, but let’s recap them here. The main parties involved in the current MEV supply chain are:

1. 1. Users: have an intention to interact with a blockchain to achieve some goal.
2. 2. Wallet: cryptographically signs the calldata, created by a dApp, which achieves the user’s goals and creates a transaction or signed message from them and sends it to an RPC node.
3. 3. Searchers: compete against each other to extract MEV with bundles of transactions or operations.
4. 4. Block builders: try to build the most profitable block using the searchers’ bundles and other transactions available in the mempool.
5. 5. Relays: a communication layer between block builders and proposers.
6. 6. Block proposers: validators who run MEV-boost, select and add the most profitable block to the chain.

The process of extracting MEV proceeds in the same order as the list above. Each step represents an opportunity for some sort of settlement regarding the distribution of the MEV in the original transaction. This is illustrated in the following figure:

The most important participants for the extraction of MEV (on Ethereum) are the searchers, block builders and proposers. In the following section, we do a deep dive on each of these participants.

There are also other entities that are involved in the MEV supply chain, like relays, solvers in intent-based systems, and order-flow auctions. For a deeper analysis of relays, check out: "Optimistic relays and where to find them" by Frontier Research and for the latter two, check out our post on order-flow auctions (“OFAs”).

MEV is a billion-dollar market, where sophisticated parties compete in a complex repeated game to get a slice of the pie. The searchers are responsible for actually identifying and extracting value from opportunities. In the following, we analyze what strategies the searchers actually use to extract MEV.

There are three main “primitive” types of bundles that the searchers use to extract MEV opportunities:

1. Frontrunning

• The searcher sees a pending transaction in the mempool and aims to build a bundle where their transaction is included before the original transaction.

2. Backrunning

• A searcher aims to insert their own MEV extracting transaction immediately after another user’s transaction

3. Sandwiching

• A combination of both frontrunning and backrunning, where the searcher tries to insert a transaction before and after a pending transaction in the mempool.

In the following, we describe how searchers use these three primitives in different MEV strategies to extract value from transactions.

Practically, searchers save the space of tokens that they want to conduct arbitrages on in some sort of data structure, where they constantly update the prices across different venues. In the above figure, pairs are saved as a multigraph where each node represents a token and each edge between tokens represents a trading venue, with the weight of that edge representing the exchange rate. The searchers’ job is to find some closed cycle (say ETH->ETH) for which the product of the weights of the edges is larger than one, meaning that you get more at the end of the loop than what you put in.

As a concrete example in figure 2, the red cycle represents an arbitrage opportunity because when you convert 1 USD to EUR to CAD back to USD you get 1.5 cents (-0.29 + 0.31 + -0.005 = 0.015, exp(0.015) = 1.015, we take the exponent because prices are the logarithms of the real prices).

This is an example of a cyclic arbitrage [32], where one trades through one or more intermediary tokens (USD->EUR-CAD->USD) before trading back to the original token.

Another common type of arbitrage is a simple arb, where the same trading pair has a different price in two venues and the trade goes through only one token say (USDC->ETH->USDC).

There are multiple algorithms that exist for this job, but an added problem is the complexity of the search space in crypto.

There are thousands of liquidity pools across multiple exchanges. If you want to be the first to extract an arbitrage opportunity, you need to be able to optimize your search space (prune the graph of unnecessary pools) so that you are able to find the (best) arbitrage opportunities in time to exploit them.

Thus, the searcher needs to find the relevant transactions in the mempool (and optimize latency if they want to react to opportunities near the end of the slot), accurately simulate their effect on rates across multiple pairs, find the most profitable route (there can be more than one profitable) and submit a bundle to the next block.

We consider the following concrete example of an arbitrage opportunity:

Here, the searcher has noticed a positive cycle between three different pools: ETH/USDC, USDC/SIL and SIL/ETH, where at the end of the three hops the searcher has turned 16 ETH into 32 ETH. Usually arbitrage opportunities yield a much smaller return because price differences are arbitraged away almost immediately, which means they do not grow very large.

It is likely that in this case, a retail user sold a massive amount of SIL in one go on the USDC/SIL pool, shifting the price so much that it created a large arbitrage opportunity.

Another important facet of on-chain atomic arbitrage is the ability to use flash loans to supply capital for the trades. This is since the DEX arbitrage is atomic and flash loans require the loan to be returned within the same block. A searcher can take out a flash loan for a specific token, use it to supply the capital for the arbitrage and take home the arbitrage profit while returning the initial capital. This means that even the most profitable type of MEV is accessible with a low capital base.

CEX-DEX arbitrage

As the name suggests, CEX-DEX arbitrage is a strategy that profits off the price difference on a trading pair between a centralized exchange and a decentralized exchange. CEX-DEX arbitrages represent a significant portion of the arbitrage opportunity on Ethereum, with some estimates indicating that it made up 60% of arbitrage revenues in Q1 2023. [33]

Because the execution of CEX-DEX requires at least two legs that are non-atomic, an on-chain and an off-chain trade, it is classified as EV_signal. A searcher is not guaranteed to be able to execute both legs of the arbitrage. They could buy a token on a centralized exchange but be outbid by someone trading on the decentralized exchange, or the block-builder(s) that they submit to might not win the block auction. Either way, the searcher bought without closing the position, potentially exposing them to a loss.

What contributes to the significant size of the CEX-DEX arbitrage opportunity is the fact that prices on decentralized exchanges update only when blocks get added and trades are made in a pool. Base layer Ethereum finalizes blocks every 12 seconds, which means that trades happen at prices that are potentially 12 seconds behind the centralized exchange price, which updates up to millions of times a second. This means that prices are almost constantly divergent between the exchanges, creating many opportunities.

Searchers engaging in this sort of arbitrage have large amounts of capital on both a centralized exchange and a decentralized exchange. As mentioned previously, CEX-DEX arbitrageurs also need to have low latency to the centralized exchange and a block builder (most CEX-DEX arbitrage is done by block builders themselves), so that they can update their trade to reflect the price just before the block gets submitted to a proposer.

CEX-DEX arbitrage is very important to keep the on-chain prices in line with the centralized exchanges, where price discovery happens on the most liquid pairs. CEX-DEX arbitrageurs are a form of price-feed for the on-chain economy. In general, CEX-DEX arbitrages are most common for pairs that are highly liquid and where price discovery happens on centralized exchanges.

To compensate for the higher risk CEX-DEX arbitrageurs take, they do not bid their profits away as aggressively. This means that searchers can often bid significantly less than 99% of the MEV profit to the proposer (which might be required in atomic opportunities) and still win. Some estimates put these figures at 35-75% of the revenue.

While CEX-DEX arbitrage provides a valuable service in keeping on-chain prices in-line with the most liquid venues, it is extracted at a significant cost to the LPs. Whenever a CEX-DEX arbitrageur trades against a DEX, it means that LPs are either selling for too cheap or buying for too much. Either way, the LP makes a loss.

The current consensus is that LVR makes it mostly unprofitable for passive LPs to provide any liquidity on DEXes like Uniswap. The discussion around LVR and its connection to LP profitability has significantly increased in the last year. There are many DeFi protocols in development to address this issue. Uniswap’s newest version (v4) promises to feature tooling that could allow LPs to avoid or be compensated for some of their losses.

DEXes are aware of this strategy and there are a few ways to mitigate it:

A user can set a low slippage tolerance, which limits the amount by which a price can change while a trade is being executed. This reduces sandwiching, because the searchers’ transactions mean the trader gets worse slippage, which could exceed the tolerance set by the trader. Searchers are still able to exploit opportunities, since they know the slippage tolerance in the trade and can size their own frontrunning transactions in a way that guarantees the tolerance will not be violated. Sometimes setting a low slippage tolerance is not even possible. If the pool has low liquidity and high volatility, users have to set a high slippage tolerance if they want their trade to go through. The boom in memecoin trading has created a significant opportunity for some sandwich bots, like “jaredfromsubway.eth”.[34]

Routing transactions through private RPCs like Flashbots Protect means that the trades never enter the public mempool, and thus cannot be seen/exploited by any searcher. This is an example of an exclusive orderflow that the Flashbots-run block builder has been able to secure. As these solutions get more popular, especially with the advent of OFAs, we can expect sandwich volumes to be reduced in the medium to long-term.

Sandwiching is seen as a form of bad MEV (Mafia EV) that extracts value from retail users in the form of worse execution, which is why many design efforts have been made to mitigate it.

The generalized frontrunner bot was able to simulate the cumulative effect of the transaction chain above. With the exploiters work call still pending in the public mempool, it realized that the final work call resulted in the sender’s address increasing by $80k. Thus the bot copied every transaction from the exploiter (in the last 50 blocks, including the pending work call) and submitted them in the same order. The bot did this just before the exploiters last transaction, and walked away with the $80k instead. Because the exploit had already been executed, the final transaction from the exploiter fails.

While it is difficult to establish whether the bot creator expected it to frontrun an exploit, this frontrunning sequence of transactions could also be said to be an accidental exploit. The bot only evaluates whether a certain transaction or sequence of transactions generates a pure profit opportunity, not whether that sequence of transactions is legal or not. This adds another level of complexity for those wishing to run front-running bots. This example also showcases a lack of sophistication from the exploiter's end as they too could have used a private RPC to hide their transaction from the public mempool.

The debate around cross-chain MEV has been a hot topic for some time. The negative externalities from its extraction were even mentioned as a motivating factor for Flashbots pursuing the creation of SUAVE (more on that in the next section).

It was feared that the extraction of cross-chain MEV would require running validators across multiple chains, so that a proposer could guarantee atomic extraction (ensuring they include both legs of the strategy in the blocks they propose). This would cause centralization pressure on the validator set, as only specific entities would be sophisticated enough to run these cross-chain strategies or even have strong enough hardware to run validators on multiple chains.

However, recent criticism has questioned whether it truly exists as described and poses a realistic threat. While MEV might be possible to extract between two chains, it seems more likely that any sort of cross-chain arbitrages will just be settled via a CEX for both chains, as the CEX price will likely always update quicker.

Many ecosystem researchers thought that, if left unaddressed, the way MEV was extracted in the early days (2017-2020), by large mining pools collaborating opaquely with specific searchers, would have made Ethereum more centralized, less democratic, and resulted in a much worse user experience.

There was a clear need for a solution that could fix issues around MEV and align the incentives of MEV extraction with the greater good of the Ethereum ecosystem. As mentioned in the history section, Flashbots was founded in 2020 by Stephane Gosselin and Phil Daian to build MEV solutions and increase awareness around the negative externalities caused by extraction. They outlined their main goals as:

1. Illuminate the state of MEV in Ethereum

• MEV was a dark forest before Flashbots started releasing research on the size of the market and the negative impacts of MEV extraction on users.

2. Democratize the extraction of MEV.

• Flashbots did not want to wait for the (purposefully) slow-moving Ethereum Foundation to start addressing the issue at the protocol level.
• Instead, they chose to develop an off-chain infrastructure that reduced the barriers to entry and mitigated centralization pressures, which increased competition in the space.

3. Distribute the benefits.

• Flashbots recognized MEV as a potential source of income for the ecosystem, protocols, and developers.
• They wanted to create mechanisms to redistribute some of the MEV extraction back to the community to ensure the economic sustainability of the ecosystem.

In the following sections, we explore the past, present, and future of Flashbots and MEV extraction on Ethereum.

The previous graph illustrates how MEV extraction happened before Flashbots. Two searchers competing for an opportunity would iteratively bid up the gas paid by their transactions to ensure that they were offering marginally more than the other searcher. Searchers were willing to bid up the gas all the way to the profit on offer from the MEV opportunity. This was essentially an open-bid first-price auction, which is why this form of competition was called a priority-gas auction (“PGA”).

This on-chain free-for-all had a few undesired consequences:

• Because the auction happened on-chain, the loser of the auction also lost all the gas that they bid for the opportunity. Over time this meant that only well-capitalized searchers could participate in auctions.
• The fact that the loser is also liable to pay the bid from their failed transaction meant that searchers systematically underbid on opportunities to avoid execution risk. In turn, this resulted in lower revenues for miners, which made mining less economically viable.
• Latency optimization is very important when competing in PGAs. The lower a searcher’s latency to the mempool was, the quicker they could react to the competing searcher's bids. This made it more likely that they would be able to submit the final, highest bid before the block was finalized. This gave an advantage to high-frequency trading firms with already existing expertise in latency optimization, furthering centralization.
• Advantages from vertical integration (e.g., latency, censorship of competition) with miners added further difficulty for small-scale searchers to compete on the market. Not everyone could source the required relationships with the mining pools and gain their trust to negotiate a deal to extract MEV for them.
• PGAs limited the searchers’ ability to express specific ordering preferences. To be able to extract value, a searcher would need to either pay more (to frontrun), less gas (to backrun), or both, (to sandwich) than their targeted transaction. This limited their opportunities, as there are strategies where the bundle consists of more than just two transactions immediately following each other in a block.
• PGAs also significantly increased the demand for blockspace. Blocks were filled and reverted transactions from the searchers that did not win the priority gas auction. This contributed to an increase in gas prices for all ecosystem participants.

By submitting the bundles through the relay, the MEV opportunities are extracted without the searchers' transactions ever hitting the mempool. This way searchers are safe from being sandwiched or frontrun by others.

In addition to this, the edge in MEV shifts from minimizing latency to the mempool (so that you can be the last one to update your transactions gas paid) to optimizing gas in transactions (so that you can bribe the miner more for inclusion). This helps new searchers compete against the incumbents, as long as they are smart enough, which democratizes access to MEV extraction.

MEV-geth bundles also gave searchers significantly more control over the ordering of the transactions. They could include as many transactions within their bundle as they wanted, in whichever order they wanted, without worrying about gas prices. Bundles introduced atomicity to multi-leg strategies like sandwiching – either the whole bundle with all of the searcher’s transactions would be included in the block, or the bundle would not be included.

The more competitive the market is, the more searchers will have to pay to the ecosystem for the right to extract MEV. Democratization and removal of capital-based barriers to entry creates more value for the system. Flashbots acted as a neutral intermediary that could be trusted to create a fair marketplace that would allow searchers to find miners and extract value in a trust minimized manner (at least compared to pre MEV-geth).

Validators gain access to the block building market by running MEV-boost as a “sidecar module” with their normal validator clients.

Before the Merge, Flashbots could ensure that searchers’ bundles would not get stolen by having a whitelist of allowed mining pools that could receive bundles. These mining pools were significantly disincentivized from stealing MEV, because doing so would get them blacklisted from the Flashbots relay. This would mean losing access to a very lucrative source of income.

In PoS, this does not work, because all an MEV stealing validator would need to do to get off the blacklist is to restake 32 ETH and use a different address. Therefore, we needed to make MEV stealing unprofitable through a new architecture.

Relays play a similar role as in MEV-geth, acting as a verifying middleman and reducing the validator’s computational cost. They ensure the validity of the blocks (making sure that the proposer does not get slashed for signing an invalid block), calculate the value of the blocks and ensure proposers get paid the bribe they are promised. Relays then send headers of the blocks that they are building (not the full blocks) to the validator responsible for submitting the next block. If this validator is running MEV-boost, it automatically commits to validating the block that has the highest value paid to it.

This commitment consists of signing the block and propagating it in the network. The proposer sees the contents of the block only after it has committed to signing it. This means that if the proposer wanted to steal the MEV, it would have to submit a second block (double signing) where it would be the one extracting the MEV. This would incur slashing penalties, which are usually significant enough to deter it.

In some cases, the value of available MEV could be higher than the slashing penalty. Even then, a proposer is not guaranteed to be able to steal bundles by submitting a second block to the network. This is due to execution risk caused by how relays propagate blocks in MEV-boost.

• After the proposer signs the block header, the relay starts propagating the signed block to other nodes in the network. Crucially, it starts propagating this block even before the MEV-stealing proposer can submit a second block.
• If enough validators in the network see (and attest to) the original block before the altered block, where the proposer steals the MEV, the original will be added to the network. Essentially, to be successful, the stealing proposer would have to outrace the relay’s original block.
• The validator would not only be unable to steal the MEV but would also suffer a slashing penalty. This further deters MEV stealing by validators. [38]

MEV-boost is now run on the majority of blocks validated on Ethereum (see the following figure). Validators not running MEV-boost forego the added yield from MEV. When they are proposing a block, they simply select transactions from the mempool based on fees paid. If a validator not using MEV-boost is responsible for validating a block, searchers can try to extract MEV through priority gas auctions.

MEV-boost has been able to reduce the centralization pressures at the validator level. The problem is that it is an out-of-protocol solution that is critical to the functioning of Ethereum. It also relies on third-party relays that are run essentially as a public good costing 20-100k [39] a year to run.

Relays are being run mainly by the same parties that run the builders. Builders are incentivized to run their own relays to ensure that their blocks make it to the proposer. Builders do not want to leave their revenues in the hands of unnecessary third parties. If they did not run their own relays, any downtime on the third-party relay would mean losing revenue due to something outside of their control.

There are only a few relay operators that supply the vast majority of blocks on Ethereum. Problems surrounding relay centralization have already created issues with censorship. Some relays censor all blocks containing US-sanctioned addresses because there are validators who want to avoid any potential legal ramifications of adding blocks with sanctioned transactions. Ensuring neutrality with regard to regulation is very important for Ethereum, which means that removing this vector of censorship is key.[40]

In fact, the original PBS specification did not include an external relay role. The current plan by the Ethereum Foundation, which is to enshrine PBS in the protocol, involves the creation of a neutral in-protocol relay for Ethereum. Because relays are currently the brokers of trust between builders and validators, an in-protocol solution will need to assure both parties that 1) builders will not have their MEV stolen by the proposer and 2) proposers will get the payment that was promised in the block header.

The current implementation of PBS relies on the Flashbots-built infrastructure, which means that installing the MEV-boost sidecar is still optional. This will not be the case when Ethereum moves to protocol-level proposer-builder separation, where validators automatically source blocks from block builders. Practical details on how the move away from the MEV-boost is still being discussed and there are many potential designs [41] that achieve in-protocol PBS. We will analyze these more deeply in a forthcoming report on PBS.

If we can mitigate centralization at the validator level, why not block building too? This is the era that SUAVE is trying to usher in, but more on that in the next section.

The solution Flashbots created to solve block builder centralization is called the Single Unifying Auction for Value Expression, or SUAVE. The idea is to create a completely new Layer-1 blockchain that acts as a mempool and the block building layer for multiple different blockchains that connect to it.

The information available on the technical implementation of SUAVE is sparse, but Flashbots has outlined the main design framework and goals of the system.[42],[43],[44]

There are three main components to the SUAVE chain: a universal preference environment, an execution market, and the decentralized block-building layer.

Universal Preference Environment

The concept of a user preference is crucial to understanding what SUAVE tries to achieve. Essentially, execution is abstracted away from the user. They do not have to reason about which protocols to use, in what order, or how much gas to pay. Instead, it submits a signed offer (a preference) for a new stakeholder, called the executor, to come up with the optimal way to achieve their goal, subject to specific conditions. If they achieve what the user wants given the conditions, a smart contract unlocks a payment from the user to the executor.

A concrete example of a user preference would be converting ETH on Ethereum to ARB tokens on Arbitrum, with the user conditioning the payment on the transaction being executed within a certain maximum slippage. User preferences can be more complex and the conditions more abstract than this. SUAVE creates an environment where users can communicate these preferences and have sophisticated parties compete for the right to execute them.

This stands in contrast to the current paradigm where users sign transactions that establish a specific computational path that instructs the EVM to execute a state transition achieving the user’s goals. There is little leeway for a third party to optimize execution, which is not the case in the preference environment. Preferences can be thought of as the SUAVE equivalent for intents, which have recently become a hot buzzword.

The universal preference environment can be thought of as a new type of mempool that allows users to express these preferences and propagates them to executors. Preferences can be thought of as the native transaction type on SUAVE. Everything is built to enable the expression, execution, and settlement of these user preferences in a decentralized manner.

It is also important to note that it is not just retail users that can express their preferences on SUAVE. The idea is to allow searchers to express preferences about MEV opportunities. As an example, there could be a cross-chain arbitrage opportunity and a searcher could express a preference for it to be closed. Naturally, this would create another competitive market because other searchers would also be aware of these opportunities. Searchers would compete on who is willing to pay the executor the most to fulfill their preference.

After the user submits their preferences to the universal preference environment, the actor who gets to execute this preference is chosen in the optimal execution market.

Optimal Execution Market

While the preference environment allows to express and share a new type of transactions, the optimal execution market is an auction where specialized parties called the executors listen to the SUAVE mempool for incoming preferences and compete in an auction to execute these preferences in the best possible way. They are incentivized to do so by the associated reward promised by the user.

The executor is a new type of stakeholder in the lifetime of a blockchain transaction. Much like a searcher, executors run specialized algorithms that come up with ways to fulfil the users’ requests and bid for the right to execute according to the reward offered by the user and the potential MEV available.

In fact, the executors in SUAVE are also the searchers. If a user preference creates an MEV opportunity, executors will compete to extract it and pay back as much of it back to the user. This means that the competitive landscape on SUAVE will mimic the one we see with searching on main-chain Ethereum today. Executors are likely to specialize in specific forms of preference execution and run different strategies, both risk-free EV_ordering and more speculative EV_signal to extract MEV out of the SUAVE mempool, while still fulfilling user execution needs. Returning MEV would mean that users could potentially transact with no gas fees or have the slippage their transaction generated returned to them – a feature that we see withorder flow auctions in the market today. The optimal execution market and universal preference environment classify SUAVE as a type of order flow auction. More on those in our dedicated report “Everything you need to know about OFAs”.

The execution market will allow the executors to merge different user preferences for more efficient execution. A simple example of this is one user wanting to sell ETH for USDC and another user wanting to buy USDC for ETH. An executor could see these preferences, match the trades together and source any amount that was not fulfilled by the peer-to-peer trade on-chain, which would reduce slippage significantly.

Redistributing MEV back to the users will mean that the rest of the supply chain has to accept a smaller share of the pie. This is especially true for validators, who currently receive up to 99% of the value in competitive MEV from the searchers’ bribes.

There is not much that these participants can do to prevent this shift in MEV share from happening. Validators could potentially ignore SUAVE as a source for bundles and either create all their blocks through the remaining transactions in the original mempool or use non-SUAVE block builders. The problem here is that since users are incentivized to route their MEV-creating transactions through SUAVE, there might not be a lot of MEV available in the chain’s original mempool. This would mean that while paying much less to validators than what they currently receive, SUAVE-built blocks would still be more profitable than the alternative.

The fact that validators would still be free to choose blocks from non-SUAVE builders, or build the blocks themselves, ensures that SUAVE still must pay some share of the MEV back to the validator. This creates a balancing act between paying the user as much of the MEV as possible, while still being competitive enough to win in the block auction.

Where this equilibrium will end up is hard to predict and will highly depend on the share of the total transaction flow that will get routed through SUAVE. Already released order flow auctions have encoded this share to be anywhere from 50/50 to 90/10 between the user and the validator.

After an executor of a specific preference has been selected, the executor submits a bundle of transactions that achieve the user’s goals to the decentralized block-building network.

Decentralized Block Building

The third main component is a decentralized network that allows block builders to collaborate in building blocks. The builders collect the preferences as bundles from the executors, after which they share information with each other on the block that they are trying to create. By collaborating, the builders can share their order flow and leverage the strengths of each other’s building algorithms to build the most profitable block possible, which creates more value for the entire ecosystem.

There are a few benefits to collaborative block-building:

• It addresses the main reason SUAVE was created in the first place, builder centralization. Because blocks are built collaboratively, the threat from a few parties controlling the entire transaction flow to a chain is removed.
• Having exclusive order flow drives no edge when building on SUAVE because this information is shared (with the contents encrypted) with other builders participating in the decentralized block building. Users and wallets also have no incentive to submit their bundles to only one specific builder to ensure their transactions are private and cannot be frontrun.
• Because the collaborating block builders can specialize to build blocks for different chains, extraction of cross-domain MEV becomes a lot easier, with fewer barriers to entry. Builders can agree that a certain cross-domain MEV opportunity, like an arbitrage, should be extracted in the next block. Using SUAVE, they can now ensure that the next block SUAVE submits on both relevant chains contain the necessary transactions to close the arbitrage opportunity. This can be achieved without requiring every builder to be integrated on each chain, which lowers barrier to entry.

Flashbots wants to ensure that block builders do not leak the user preferences when building the blocks in a decentralized manner. Not having the transactions encrypted could be a problem because a builder could potentially front-run users, if they knew certain transactions would be submitted to a specific chain in the next block by SUAVE.

A simple example could be a sandwich attack, where a builder that knows a user has a preference to buy a token on Ethereum could submit a transaction to buy that same token before the user and sell the token after the user’s transaction is finalized. Even if you could trust certain builders to not do this, the aim of the system is to be completely permissionless & trustless and to allow anyone to participate in the building. Therefore, user preferences need to stay private.

At the moment, the only existing technical solution to this is forcing the builders to run their block building algorithms in a “secure enclave”, which is a dedicated part of the builder’s computer that is able to run code in a fully private manner without leaking information outside of that system. This means that while the builder’s block building algorithm can see the contents of the bundles that it receives, the builder itself cannot do anything with this information, because it would require running unauthorized software inside of this secure enclave, which SUAVE could detect.

The following figure recaps the currently outlined architecture of SUAVE:

Implications and the Future of SUAVE

Why does Flashbots expect other chains to want to outsource their block building and mempool to a completely new chain?

• The connecting chains benefit from maximally decentralized block building. This means that they are more protected from censorship (either due to regulation, like sanctions, or malicious actors). Ensuring that the transaction flow of an entire chain is not in the hands of a small group of stakeholders is the only way these chains can claim to be truly decentralized.
• Users of SUAVE integrated chains benefit from the fact that their transactions are guaranteed privacy and therefore cannot be frontrun. This means that the chains or other actors in that chain’s ecosystem do not have to invest in researching and bootstrapping a custom solution to achieve the same result for their chain, which would also likely take more time.
• Aggregating and matching users’ preferences in a single auction environment is a more efficient way to coordinate users’ needs than having a dedicated auction for each chain individually. It unlocks many exciting applications, such as bridging or low-slippage peer-to-peer trading.

What are the implications of SUAVE on the current MEV supply chain?

• Decentralized block building has the potential to increase the average value of blocks, because builders share all of their order flow. Ceteris paribus, the more order flow a builder has access to, the higher the likelihood that it can construct the most valuable block in a slot. The main problem with this argument is the existence of CEX-DEX arbitrage. It remains to be seen whether a decentralized block builder, with a significant latency disadvantage (communication between builders + running the algorithm in an enclave) could outcompete the existing searcher-builders here.
• Builders/searchers: democratized and open access to user and searcher transactions, which decreases barriers to entry. A universal expression environment allows searchers to express more complex goals than what is possible today with bundles. Cross-chain coordination becomes much easier.
• Users benefit from private transactions that cannot be frontrun with minimal fees and get paid for the MEV that they create.

While SUAVE claims to solve block builder centralization and the suggested components do seem to achieve this goal, they also clearly achieve much more than that. By creating a marketplace for users to express their preferences, and for external parties to compete to offer the best execution of those preferences, SUAVE unlocks a new way for users to interact with blockchains. It also acts as a powerful tool that distributed applications can leverage to achieve the goals of their users, like bridging funds or trading assets.

Flashbots has defined a roadmap that takes the SUAVE ecosystem from a centralized version bootstrapped by Flashbots to a trust-minimized system in which they participate in the development of the marketplace, but do not participate in running any software that enables its functionality. Many of the outlined ideas sound quite abstract, with the technical implementation also being an open research problem in many cases.

There are still many open questions as to how SUAVE will achieve the goals it has identified. These include:

• How exactly will the different chains plug into the SUAVE chain? How will users interact with SUAVE? There are even suggestions to build the SUAVE chain as a roll-up instead of an independent Layer-1 blockchain.
• Will there be MEV on SUAVE? What will be its settlement mechanism?
• How are block builders incentivized in decentralized block building? If one builder’s algorithm contributes more to increasing a specific block's value, how do they get compensated for this?
• What is the exact mechanism that redistributes the MEV back to the users?
• How will the secure enclaves work? What are the potential attack vectors in this solution?
• How does Flashbots find a path to revenue if all the projects they are currently building are meant to be public goods?

Acknowledgements

Thanks to Danning Sui, 0xTaker, Greg Vardy, Eduardo Carvalho, Alex Watts, Barry Plunkett, Maghnus Mareneck, Barnabé Monnot, Justin Drake, 0xPrincess, for your review & valuable feedback.