PART ONE

INTRODUCTION TO MEV

1.1 WHAT IS MEV?

Maximal extractable value (“MEV”) is defined as the value that block proposers (miners or validators) can extract from a blockchain by using their ability to order, insert and censor transactions within the blocks that they produce.

MEV’s tentacles touch the entire transaction supply chain of blockchains and significantly impact their user experience, consensus mechanisms, and design considerations. Every application and protocol developer needs to consider how their design choices might expose them and their users to the extractors of value that patiently lie in wait for new opportunities.

MEV is a double-edged sword. It can be a hindrance to the adoption of blockchain applications if value extraction comes at a cost to the user experience, but also a powerful incentivization mechanism that developers can leverage as an integral part of their protocols.

In this report, we explore how the extraction of MEV has evolved into a highly complex game where (teams of) crypto natives and quant trading firms compete for the chance to capture a sliver of the value available.

We have chosen to focus on the Ethereum ecosystem in this report. We appreciate that MEV exists and needs to be addressed in other blockchain ecosystems as well. We will dive deeper into MEV outside Ethereum in our forthcoming reports.

To understand how MEV is extracted, let’s start with the fundamentals. Let’s consider the lifecycle of a standard Ethereum Transaction (post-Merge) to see where and how value gets extracted:

Figure 1 summarizes the current transaction flow and the actors that interact with a user transaction before it gets added to the blockchain.

Figure 1: The lifecycle of a Ethereum transaction.

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” [2].

PART TWO

A BRIEF HISTORY OF MEV

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).

PART THREE

CATEGORIZATION & SIZE OF THE MEV MARKET

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:

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.

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

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

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:

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.

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.

Figure 2: Estimates of on-chain MEV & Gas (since the Merge), note spikes around FTX and USDC depeg. (source: mevboost.pics)

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.

Figure 3: Difference between quantified extractable value, extracted value & maximal extractable value

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:

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.

PART FOUR

THE CURRENT MEV SUPPLY CHAIN

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:

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:

Figure 4: Value flows in the Ethereum MEV ecosystem (source: Stephane Gosselin)

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”).

4.1 SEARCHERS

As discussed above, searchers scan the pending transactions visible in the mempool and compete against each other for opportunities to execute their MEV extraction strategies (section 6). This raises a few questions:

After a searcher has identified an MEV opportunity, it needs to construct a sequence of transactions, a bundle, that exploits the opportunity and then submit the bundle to a block builder. There are most likely other searchers competing for the same opportunity. Thus, the searcher has to “bribe” the block builder with a promise of a specific amount being paid to the validator, which is larger than the base gas fee (per unit of gas) that the transaction would pay otherwise. In addition to this, the builder receiving the searcher's bundle has to win against the other builders in the builder auction (next section). Because searchers have little control over this (it relies on the rest of the transactions that the builder has access to), the best strategy for them is to send their bundles to as many builders as they trust.

A major reason why MEV is so competitive is the fact that a large share of the opportunities (specifically, EV_ordering) can be exploited risk-free. This is enabled by things like bundle reversion if a searcher fails to win an opportunity and flash loans.[18] This stands as a contrast to many other sophisticated, and potentially profitable trading strategies, where the profit is only statistically guaranteed; in atomic MEV, if you notice and win an opportunity, you are deterministically guaranteed to make money.

Theoretically, anyone with a computer, an ability to code and a willingness to find opportunities can start working on MEV. Practically, this is not what happens anymore, at least not on most competitive opportunities, which require teams of sophisticated traders/engineers. Opportunities like arbitrage, liquidations, frontrunning and sandwiching are among this “short-tail” of MEV strategies.

Searchers that want to compete on the most profitable / in-demand forms of EV_ordering, have to be great at optimizing smart contract code. The bribe for inclusion to the validator is paid out of the MEV profit that is available from the transaction. Remember that a searcher can pay more than any other searcher as a bribe to the validator, then they will win the opportunity. Let’s say there is a MEV opportunity of $100 available. If searcher A’s strategy costs $10 in gas, and searcher B’s strategy costs $5, then searcher B will be more competitive in the auction. The lower the searcher can make the gas costs, the more headroom they will have to bribe the validator to win (in this case $95 vs. $90).

This means that specific strategies often become a winner-take-all marketplace. A searcher finds an optimization to a specific type of MEV strategy and controls the market until someone else finds an optimization that allows them to bid more than the current incumbent.

If a searcher wants to be competitive on EV_signal, they need to be great at optimizing exchange connectivity (to be the quickest to react to price changes), fee tiers, inventory risk management and potentially relationship building with block builders to guarantee inclusion (more on this in the next subsection).

As EV_ordering opportunities have become more competitive and the profit margins have been compressed, some searchers have shifted from trying to extract atomic opportunities to competing on the same strategies (like sandwiching) in a non-atomic, EV_signal, way where profit is not necessarily guaranteed.[19] When successful, risk-taking searchers are able to extract at least as much, and generally more value from the same opportunity as those that refuse to take risk. This does not necessarily mean that such searchers will be more profitable, especially if the risk they take actualizes.

The more niche (capacity/awareness) the opportunity, the more likely a solo searcher will be able to be competitive. This is because the profit opportunity is not large enough to attract sophisticated teams. As an example, some searchers will focus on alternative L1s/L2s or new on-chain applications. These opportunities, especially after launch and before MEV distributing/democratizing solutions are released, can promise relatively large profits (for a sole searcher) in a less competitive market. These include Avalanche [20] and most recently Base with friend.tech [21]. These opportunities are often referred to as long-tail MEV.Depending on the competitiveness of the MEV opportunity, searchers are forced to pay up to 99% of the available value as a bribe to the validator.[22] Opportunities that are simple to notice, simulate, and extract on your own are crowded and the searchers rationally bid up to the point where they will still make a profit over time (considering opportunity and infrastructure costs). This is also because the current MEV auction infrastructure is built in a way that ensures that the searcher either gets the MEV profit from their bundle or the transaction reverts, with the searcher getting back their bid. This was not necessarily the case before off-chain MEV auctions were introduced, as searchers had to take into account the potential cost of losing an opportunity and still having to pay a potentially significant gas fee (priority gas auctions - see section 6.1).

Therefore, we can divide MEV into both competitive and non-competitive opportunities, based on whether the searcher has to bid away a significant portion of their profits to the block proposer in exchange for inclusion.

There are a plethora of MEV opportunities for searchers to compete on, but how do they actually extract them?

After this, the searcher gets included on-chain and receives the difference between the MEV generated by the opportunity and how much they ended up bidding to the validator.

4.2 BLOCK BUILDERS

The role of a block builder was introduced after the Merge. It is part of proposer-builder separation, which was first formalized by Vitalik in 2021. [24]

PBS was introduced as a solution to mitigate centralization risks at the consensus level after the Merge. We’ll dive deeper into why it was necessary to externalize full block construction in proof-of-stake Ethereum in section 6.

As covered in the previous section, block builders collect transactions and searcher bundles to build a block that they submit to a relay, which forwards it to the block proposer in that slot.

To build the most valuable block possible, builders use different algorithms to select and order bundles/transactions. After a builder has finished building a block, it uses a relay to send the proposed block to the validators (on ETH; on other chains might communicate directly). Since transactions are constantly arriving within a single 12 second slot (the blocktime on Ethereum), builders will build and submit a block to a relay multiple times in a slot, as new order flow enables them to create more valuable blocks.

MEV-boost will select the block that pays most to the validator. A natural question that might arise from this is what makes one builder more competitive than another builder, i.e., able to pay more in their block?

Running a block builder is not free since it comes with both significant infrastructure [27] and development costs. How do block builders generate a profit?

It is also important to consider the trustworthiness of block builders.

4.3 BLOCK PROPOSERS

A block proposer is a validator who is responsible for submitting valid blocks to the Ethereum blockchain. On Ethereum, a validator can be chosen to be a block proposer if they have staked at least 32 ETH to the deposit contract. Validators get randomly selected by the Ethereum consensus mechanism to become block proposers. In return for this work and for committing their stake to be slashed if they misbehave, they receive a block reward.

The more economic stake a node operator has, the more likely they are to be selected as the block proposer. All nodes with at least 32 ETH staked have an equal chance of being picked, i.e., a single node does not get picked more often if they have deposited more stake. However, operators can collect many multiples of that amount to run more than one node and therefore get picked more often.[28]

These block proposers are the final step before the MEV-extracting blocks are submitted to the blockchain. Block proposers receive different proposals for blocks from block builders, via third parties called relays, with an associated bribe to the block proposer (which is paid out of the MEV extracted) to incentivize the proposer to select that block over the others submitted to it.

Actually, the proposer only receives so-called “execution payload headers” from the relay. These contain enough information to reliably evaluate the value of a block, but not to execute it (because it does not have the transaction contents). This means that the proposer cannot just steal the MEV by submitting the block without paying the searchers (and possibly the builder). The contents of the block are only revealed after the validator has committed to the payload header, after which it can be proposed as the next block.

Before MEV-boost, block proposers were also responsible for building blocks, but now they can focus on only proposing the blocks that they get sent through the relay. A small minority, 5-10%, of blocks built are not submitted through the MEV-boost client and instead built locally, usually with the default algorithm of the validator client.

Recall from the previous section that MEV-boost running proposers always select the blocks that give them the most economic benefit, i.e., in which the amount bribed to them is maximized. The benefit of participating in the MEV ecosystem is that validators can boost the yields that they get for the ETH that they have staked above the normal block reward, simply by running the MEV-boost sidecar in addition to the other validator software. The yield that validators get is a sum of the block reward, transaction fees and, if the validator is extracting MEV, the bribe paid to the validator out of the MEV available in that block.

MEV extraction also creates a competitive marketplace between different validator operators. Some validators receive their stake through delegation from external stakers, who seek a way to earn a yield for their tokens without running their own validator node (liquid staking/staking-as-a-service). A share of the additional yield that validators receive for participating in MEV extraction can be paid out to these delegated stakers as a bonus. The validator that can pay the most yield will start accumulating more delegated stake than other validators, which forces other validators to start paying a higher yield.

This eventually leads to a situation where, even though validators earn up to 99% of the value of certain MEV opportunities as a bribe, this bribe is in turn immediately paid out to the external stakers and thus redistributed to the wider ecosystem.

There is very little that validators can theoretically [29] do to get higher MEV yields than what is available through MEV-boost. This explains the relative dominance of blocks that are built using MEV-boost, and why there are no significant node operators running custom MEV strategies/clients.

While the dominant strategy might be to run MEV-boost, some block proposers have recently started to play so-called timing games within this system. Generally, proposers request blocks (built by the block builders) from the relays they are connected to immediately at the start of their slot. By delaying this request slightly, they are able to propose a higher value block (more time => more MEV opportunities => builders’ blocks are higher value).[30]

Figure 5: Illustration of additional profit available to block proposer by delaying block requestPART FIVE

TYPES OF MEV STRATEGIES

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

2. Backrunning

3. Sandwiching

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

5.1 ARBITRAGE

When executing an arbitrage, a searcher takes advantage of the mispricing between two different trading venues. By buying the asset on the venue where the price is lower and selling on the venue where the price is higher (or selling then buying) the searcher profits the spread minus the gas he paid to get that execution.

Arbitrage is the most common form of MEV and the most competitive one. For the on-chain MEV opportunities tracked by EigenPhi [31], arbitrages made up over 47% of the profits, 68% of transactions and 82% of the bots. And this is without considering off-chain MEV, which. depending on market volatility, can be more than half of the entire MEV opportunity.

There are two main types of arbitrage DEX arbitrage and CEX-DEX arbitrage.

DEX arbitrage:

Most decentralized exchanges today are AMMs, which means that the market price of a specific trading pair changes in a completely deterministic manner in reaction to customer orders. When these orders are large enough, they create a difference in prices between two or more liquidity pools.

Searchers need to constantly simulate whether incoming transactions in the mempool create large enough moves in asset prices on specific exchanges to create an arbitrage opportunity. If this is the case, a searcher will try to backrun this transaction with their own buy and sell orders.

DEX arbitrages are atomic or EV_ordering, that means that there is only one on-chain leg of the trade, within a single bundle. The searcher does not hold inventory between buying and selling, since everything is executed within the same block.

Figure 6: Trading pairs represented as a graph. The red cycle represents an arbitrage opportunity. Edge weights represent the logarithm of the exchange rate. Log is taken here because of the algorithm used looks for positive sums of edges. (source: Daniel D. McKinnon)

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:

Figure 7: Example of a multi-hop 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]

Figure 8: Illustration of a CEX-DEX arbitrage. (source: Frontier Research)

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_ordering. 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.

Figure 9: An example of the on-chain leg of a CEX-DEX arbitrage executed by beaverbuild. The bot sold 3073 ETH for $5.7M USDC to arbitrage the price between some CEX (most likely Binance) and the Uniswap V3 USDC/WETH pool.

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.

5.2 SANDWICHING

The sandwich primitive takes its form as an MEV strategy most often through exploiting retail users trading on DEXes.

The searcher scans the mempool for transactions on AMMs that have a high slippage tolerance, that is trades that will still execute even if the price the user gets executed at differs significantly from the price that was displayed when the trade was submitted.

Let’s say a user wants to buy ETH with 100,000 USDC, with a slippage tolerance of 10%. Say this trade would move the price in the pool up by 6%. A searcher that sees this transaction in the mempool can build a bundle where they first buy ETH just before the user’s transaction. The searchers execute at a size that moves the price of the AMM pool up by some amount, but not enough to go over the user’s slippage tolerance and revert the transaction. Now that both the user and searcher have bought ETH, the price in the pool has moved by nearly the slippage tolerance, say 9.9%. The searcher includes a final sell transaction in their bundle, which sells at the new higher price and profits the difference between the buy and sell price minus the trading fees and the gas paid to guarantee execution.

Figure 10: Illustration of a sandwich attack (source: EigenPhi)

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.

5.3 LIQUIDATIONS

Liquidations are a type of backrunning strategy that searchers execute on on-chain lending protocols.

Lending protocols rely on external parties to manage the risk of their loans. To lend from a protocol, a user has to post collateral (usually more than what they borrowed) in some token. Borrowers are obliged to keep the collateral value above a certain ratio to the amount loaned. As an example, on Aave a borrower can borrow up to 80% of the value of the collateral in ETH.

Naturally, the value of this collateral fluctuates much like any cryptocurrencies. If the value of the collateral decreases so that the value of the borrowed assets crosses the liquidation threshold or if the value of the borrowed assets increases so that the liquidation threshold is hit, your collateral can be sold off.

Let’s say that an asset price suddenly started collapsing. Any loans that are collateralized by this asset are now potentially in danger of liquidation because the collateral is no longer enough to cover the assets that were borrowed. This presents a significant risk for the decentralized lending protocols. They need to be able to sell off the collateral in time to avoid credit losses.

The solution these protocols came up with was to allow anyone to liquidate a lending position that has crossed the liquidation threshold by calling a function. In exchange for submitting this call, the lending protocols pay either a flat fee for the service or even a share of the liquidated collateral.

Searchers compete for liquidation opportunities by tracking positions that are near the liquidation threshold. DeFi lending protocols often rely on an external oracle (like Chainlink) to provide them a price feed for their assets. These oracles update their on-chain prices by sending transactions to the chain. The searcher scans the mempool for oracle price updates that would push the price of the collateral below the liquidation threshold. As soon as the searcher notices such an opportunity, it creates a bundle where they insert a backrun transaction immediately after the update transaction.

This backrun is performed as follows (all in a single atomic transaction): 1) the searcher either takes a flash loan (gas intensive) or already has enough of the loaned asset in their account. 2) The searcher then pays off the loan to liquidate the position and collects the remaining collateral (after the liquidation penalty is applied) + the liquidation bonus. This amount should be higher than the value of the loan that the searcher repays, otherwise there would be no incentive to liquidate. Finally, if the searcher took a flash loan, they repay it within the same transaction.

Liquidations are highly competitive as the strategy is simple to perform. This means that it is common to see liquidations paying up to 99.9% of their revenue to the validator.

5.4 GENERALIZED FRONTRUNNING

A simple generalized frontrunner is a bot that simulates the resulting state change of each pending transaction in the mempool. If a certain transaction (or sequence of) yields a net increase in the balance of the wallet initiating the transaction, it creates an opportunity for frontrunning.

In this case, a frontrunning bot will take the pending transaction and replace all the fields referring to the original transaction creator with the bots’ own addresses. After this, it will submit the new transaction to the chain (via mempool or otherwise) with a higher gas fee than the original transaction and potentially anyone else that is trying to frontrun the transaction, to guarantee its transaction is the one that gets executed.

As a toy example, consider the Ethereum version of the Bitcoin bounty by Peter Todd from our history section. Say there is some crypto influencer who has announced a puzzle on Twitter. The solution to this puzzle must be submitted to a smart contract as a transaction with some message. The smart contract will return the first person to send the solution 1 ETH. If this solution transaction is submitted through the public mempool, a generalized frontrunning bot would be able to simulate its effect and notice that it returns 1 ETH to the sender of the transaction. A frontrunning bot would then simply copy the transaction, submit it with a higher gas price, and without having any knowledge about the puzzle or its solution, be able to claim the prize. The solver could have avoided being frontrun, if they had submitted their transaction through a private RPC endpoint, like Flashbots Protect [35]

While the premise seems simple (simulate all the incoming transactions and frontrun those that generate a profit according to the simulation), in practice these bots need to run sophisticated checks to ensure they are not being exploited. There are attacks that are able to make a simple generalized frontrunning bot think that a frontrunning opportunity is available, when, in reality, the bot might lose most of the capital it deploys in the transaction.[36]

Sometimes hackers exploiting DeFi protocols fall victim to these generalized frontrunning bots, because they are not aware of their existence, or are otherwise careless. A recent example of this that also showcases how advanced these bots can become is a recent exploit of a protocol called Roe Finance.[37]

The exploiter created an exploit contract and set up a chain of transactions stretching 50 blocks that set up the protocol to be exploited. Then the exploiter submits the work() call, which fails, because a frontrunning bot recreated the exploit and executed a frontrun.

Figure 11: An exploiter setting up the exploit over a period of 50 blocks, note the latest transaction, which reverted (red exclamation point)

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.

Figure 12: Generalized frontrunner replicating all the transactions of the exploiter in a single block, frontrunning the exploiter.

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.

5.5 CROSS-DOMAIN MEV

Cross-domain MEV refers to the extraction of MEV between two or more different domains. Practically this can mean either between a blockchain and an off-chain venue (e.g., CEX-DEX arbitrage), or another blockchain (cross-chain MEV).

The strategies themselves are not fundamentally different across chains but mainly relate to arbitrage at the moment. It might be that in the future, there will be other MEV strategies that could be exploited across chains.

There are some complications that arise from trying to extract MEV in a non-atomic way across different domains. As with any non-atomic MEV extraction, there is no guarantee that both legs of the MEV extraction land on-chain. In addition to this, the searcher must either have inventory across multiple chains or bridge funds over while executing the strategy, which both increase the risk surface.

Below is an example of cross-domain MEV extraction. A searcher noticed that by swapping from USDT to WETH on Polygon, and then bridging the funds over to ETH, it was possible to extract a profit of 289 USD. Note that if the searcher has ETH on the main Ethereum chain, they can run this strategy without bridging funds over.

Figure 13: Example of cross-chain arbitrage. (Source: odos.xyz)

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.

PART SIX

FLASHBOTS & MEV ON ETHEREUM

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

2. Democratize the extraction of MEV.

3. Distribute the benefits.

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

6.1 PRIORITY GAS AUCTIONS - MEV ON ETHEREUM BEFORE FLASHBOTS

Before proof-of-stake, MEV was called miner extractable value because miners were in control of block construction and therefore of any extraction of value from transactions.

By default, miners would select transactions from the Ethereum mempool based on how much gas they paid. In addition to a block reward, miners received the gas fees paid by transactions in the block, which incentivized them to choose the highest-paying ones. Therefore, for a searcher to win an MEV opportunity, they had to ensure their transaction paid a higher gas fee than others competing for the same opportunity.

Figure 14: Example of a priority gas auction. Note the bids getting progressively higher as the block time gets closer. The bot indicated by the blue circle won this auction, placing the final bid just before the block finalized. (source: Flash Boys 2.0)

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:

6.2 FLASHBOTS BEFORE PROOF OF STAKE

To fix the existing issues with priority gas auctions, Flashbots created a first-price sealed-bid auction for blockspace that enabled the off-chain settlement of the rights to extract MEV from transactions in the mempool. This fixed many issues with priority gas auctions, especially the execution risk, latency advantages, wasted blockspace and lack of ordering control.

Miners would run a fork of the main Ethereum client called MEV-geth, which connected the miners to a relay hosted by Flashbots. This relay acted as a trusted interface between the searchers and the miners, allowing searchers to submit bundles to a network of miners through one endpoint.

The first version of MEV-geth submitted only the most profitable bundle, relative to its gas fees, to the miners. The miner placed the bundle at the top of the block and filled the rest from transactions it had access to locally. However, most of the time, there was more than one non-overlapping MEV bundle available, which is why Flashbots introduced bundle merging. Bundle merging would allow the miner to request as many non-overlapping bundles as they wanted in the block they were mining.

This bundle merging was still done by the miner in the MEV-geth software, which meant that miners would usually only request 2-3 bundles. This was because each additional bundle increased computational complexity exponentially as they would have to be compared against previously added bundles for overlaps.

To allow for the maximum number of bundles to be added in a block, the computational load for each miner had to be reduced. The solution was to make the relay do the hard work of merging bundles for the miner, which allowed it to build so-called mega bundles. The miners would still fill the remaining part of the block with pending transactions in the mempool, but the relay did a significant portion of their work for them. This was the first step towards the proposer-builder separation model introduced after the Merge (more on that next).

One could ask whether the relay is needed here – couldn’t the miners run the auctions themselves?

Figure 15: Architecture of MEV-geth. (source: Flashbots)

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).

6.3 PROPOSER-BUILDER SEPARATION - MEV IN PROOF OF STAKE

The existence of MEV created a concern that after the Merge, there would be significant centralization pressures on the validator set. Due to the complexity of MEV extraction, it was feared that only large entities that could run MEV strategies (or collaborate with searching teams) would be able to be effective validators.

This was because the best MEV extractors would be able to use their MEV profits to capture a larger share of the stake and get chosen as block proposers more often, which would allow them to capture more MEV. They could also use these increased profits to invest into developing better MEV strategies, furthering their advantage in an iterative process that would end up with only a few node operators controlling Ethereum.

It was clear that for Ethereum to stay decentralized in the future, it was necessary to minimize the overhead that would be required to be an effective validator. The solution was to separate the role of building the most profitable block (difficult) from the role of proposing it in the network (trivial).

Proposer-builder separation creates an open market for block proposers to source blocks from block builders, who compete against each other to build the block that can pay the highest fee to the validator.

Proposer-builder separation is able to ensure that MEV is not a contributor to validator centralization. This comes at the cost of pushing centralization to the block builder level, which is believed to be a preferred outcome.

While the importance of PBS was acknowledged going into the Merge, there are some clear theoretical and practical challenges with trying to implement it at the protocol level (enshrined PBS). These include ensuring censorship resistance and decentralizing the relayer role. The decision was made to not delay the merge to solve these issues, and therefore Flashbots took up the challenge to provide a solution for the interim.

6.4 FLASHBOTS AFTER THE MERGE - MEV-BOOST AS PROTO-PBS

Going into the Merge, Flashbots had to adapt the MEV extraction infrastructure that it had built before. Flashbots built MEV-boost as a solution for the period after the Merge but before the enshrinement of PBS at the protocol level.

MEV-boost is often called proto-PBS because the high-level architecture is very similar to how PBS is intended to be implemented in-protocol in the future. MEV-boost provides a market where even unsophisticated validators can have access to the most profitable blocks built in a slot.

The high-level infrastructure is pretty similar to MEV-geth, block producers received suggestions from a relay that received bundles from searchers. Only in this case, there is an additional entity between the relay and the searcher responsible for assembling the bundles.

In the next figure, we see the architecture of MEV-boost (note the addition of the builder role between searchers and relays). In Proof of Work, the relay would simply propagate valid bundles to miners who played both the role of the block proposer and the block builder.

Figure 16: Architecture of MEV-boost (source: Flashbots)

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.

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.

Figure 17: The share of blocks produced by validators running MEV-boost vs. vanilla. (source: mevboost.pics)

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, with the Flashbots relay making up nearly 50% of the volume going through the relays. 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.

6.5 SUAVE - THE FUTURE OF MEV?

In the current model of proposer-builder separation, even though validating is decentralized, centralization risks still exist at the block-builder level. While validators no longer have censorship capabilities if they run MEV-boost, block builders still retain autonomy over which transactions to choose in their blocks and how to order them.

Although anyone can run a block builder, the competitive dynamics that we explored in the previous sections result in a concentrated market. We recap these centralizing dynamics here:

That a small group of stakeholders, in a market with high barriers to entry, can control almost the entire transaction flow to an entire blockchain is a serious issue. Flashbots wants to solve it by decentralizing the block builder role completely.

The following figure illustrates the situation in the block-building space on Ethereum. The top four builders’ control over 75% of all the blocks that are added to the blockchain.

Figure 18: Block builder market share. Data from 12/05/2023 to 12/19/2023 (source: mevboost.pics)

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.

Figure 19: SUAVE aims to replace the mempool and builder roles that exist in chains like Ethereum (source: Flashbots)

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:

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:

Figure 20: The main components of SUAVE (source: Flashbots)

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?

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

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: