The MEV Book: A Comprehensive Guide to Maximal Extractable Value

BY Monoceros Ventures
  1. 1. Introduction to MEV
  2. 2. A Brief History of MEV
  3. 3. Categorization & Size of the MEV Market
  4. 4. The Current MEV Supply Chain
  5. 5. Types of MEV Strategies
  6. 6. Flashbots & MEV on Ethereum
Part One

Introduction to MEV

1.1 What is MEV?

Listen to "the MEV Audiobook": 🔊

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:

  1. 1. When a user has the intent to use some blockchain application, they need to translate this intent, say swapping ETH for USDC, to some sequence of instructions that the Ethereum Virtual Machine (“EVM”) can understand. Because most users do not speak in bytecode, the user interacts with a front-end UI that captures the user’s inputs (e.g., how much ETH they want to sell) and creates calldata that achieves the user’s goal when executed by the EVM.

    Before the application can interact with the user’s account (based on the calldata created through the front end), the chain needs to know that the user has in fact authorized the interaction. The user’s wallet takes the dApp calldata and allows the user to sign it cryptographically to create a transaction, which when executed fulfils the user's intent.
  2. 2. After signing, the transaction is forwarded to some validator node to be distributed in the wider peer-to-peer gossiping network for transactions. The receiving node conducts checks to confirm that the transaction is valid and, after certifying validity, adds the transaction to its collection of pending transactions, the so-called mempool. [1]

    After inclusion into the mempool, transactions stay in a pending state until they are selected to be a part of the next block to be added to the blockchain by the block proposer. On Ethereum, for each slot, this proposer is chosen randomly from the set of validators, nodes with 32 ETH staked on the network.

    On Ethereum, the default way a block proposer sequences transactions in their block is by a gas auction - including the highest tip paying transactions in decreasing order. When sending a transaction, a user needs to pay a gas fee based on the computational complexity of the transaction and the current per unit cost of gas. In addition to this, they can include a priority fee (tip), to incentivize a validator to include their transaction ahead of other pending transactions.

    The priority fee paid by an unsophisticated retail user might not actually be a good indicator of the “true value” of that transaction. Sometimes the true value of a transaction is much higher than what the user has promised to pay, as we will see later. This value can be captured using different MEV strategies (section 5). Block proposers have full autonomy on what sort of blocks they add to the blockchain (not just the default ordering by priority fees paid). This includes reordering, not including/censoring and adding transactions into the blocks they submit, which enables them to extract this value.

    Consider our earlier swap transaction: since there are multiple other DEX liquidity pools trading the ETH/USDC pair, our trade could create an arbitrage opportunity, where the price in the pool after our trade would be lower than in a pool on another DEX. The block proposer could include a transaction immediately following ours, which would buy some ETH from the pool we just traded with and sell on the higher-priced pool, arbitraging the difference in price.

    We will dive deeper into this in the later sections, but while block proposers can extract MEV in the way illustrated above, the level of required sophistication to do so effectively means that the proposers are better off letting other sophisticated actors called searchers (section 4.1) suggest to them how to extract value from the transactions available (what transactions to include and in which order).

    This is a win-win situation, since validators get to keep a portion of the MEV profits (often a significant majority, up to 99% in atomic MEV - section 3) without investing significant amounts to strategy development, and the searchers get to constantly extract value out of transactions without staking 32 ETH and having to wait to be selected as a block proposer.
  3. 3. These searchers constantly scan the public mempool for new transactions, simulate their effect on their own instance of the EVM and, if there is a profitable strategy, create bundles of transactions, by inserting their own transactions before and/or after the target transaction, and submit them to one or more block builders for inclusion in the next block, not directly to the proposer.

    So, the validators have not only outsourced the extraction of MEV to searchers but also the construction of blocks from the searchers’ bundles and other transactions in the mempool [2] to a second group of sophisticated third parties, the block builders. This is called proposer-builder separation (“PBS”) more on that later (section 6.3).

    These block builders try to assemble a block that allows them to maximize the amount they pay to the proposer of the next block (from the MEV available). Builders need to build blocks using non-overlapping bundles, meaning that the same transaction cannot be included twice in the block. Thus, the builder usually selects the searcher whose bundle promises to pay it the most (the searcher auction, more in section 4.1).
  4. 4. The block proposer for that slot selects the most valuable block submitted to it by the block builders (via relays, section 6.2). To do this, the proposer runs a software, MEV-boost (section 6.4), on top of their consensus client that processes the blocks it receives and automatically submits the most valuable one it received to the network.

    The commitment to submit the most valuable block forces the builders to try to maximize the amount they pay to the proposer. Otherwise, they risk not having their block proposed and losing in the block-level auction (section 4.2).

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

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:

  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.

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

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 extracted value, extracted value & maximal extractable value
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:

  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.

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:

  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:

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:

  • Who are these searchers?
  • Why do they participate in the extraction game?
  • How exactly do they make a profit?
  • How do they ensure that their strategies get executed?
  • What makes a searcher competitive?

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 [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 two ways an MEV opportunity can be non-competitive. Either there is only one searcher that has seen the MEV creating transaction, or the transaction is visible to everyone, but there is only one searcher that has a strategy to extract MEV out of it (long-tail MEV).
  • A transaction would be seen by only one searcher if they somehow have an exclusive orderflow agreement [23] with the originator of that transaction. It might even be that the MEV-creating transaction is created by the searchers themselves.
  • For non-competitive MEV opportunities, the searcher only needs to pay a nominal amount, just enough to get included in the block by the validator. This can be even less than 0.01% of the MEV opportunity on offer.

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

  • First the searcher has to notice an opportunity (or, search) from the pending transactions in the mempool. They run algorithms that scan the pending transactions for opportunities that they are interested in exploiting.
  • Note that there is no single mempool. Each node has its own constantly updating pool of pending transactions. Nodes also propagate the valid transactions they receive to other nodes. Many searchers therefore run their own Ethereum full nodes to have access to transactions in the mempool. Others pay for mempool services (e.g., bloXroute or Blocknative) to receive mempool data at a minimal latency, or to not run their own nodes. Latency optimization can be important for searchers because it allows them to compete for opportunities that arrive just before the end of the 12-second slot.
  • After noticing an interesting transaction, the searcher bot uses a simulation engine to check whether an opportunity is profitable for them. These tools, usually run off-chain, take the targeted transaction, simulate its effect on the blockchain and determine whether they can create a bundle that extracts profit from the transaction. As with mempool connectivity, optimizing the latency of the simulation engine is key if the searcher wants to be able to react to transactions arriving near the end of a slot.
  • After a searcher has simulated an opportunity, they build the bundles of transactions to be submitted to block builders with some associated bid they assume to be enough to win the opportunity.
  • The on-chain games start at this point. The searchers have deployed smart contracts on Ethereum, which contain the actual code that extracts the MEV (like executing a swap on a DEX). A searcher’s bundle contains a call to one of these smart contracts (say buying a token on Uniswap before a retail user) and then the transaction that the searcher wants to extract MEV from.

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?

  • Like searching, building is also a highly specialized and competitive marketplace.
  • Orderflow represents the biggest advantage that builders have over each other. If a builder has access to bundles that other builders do not and if those bundles contain more MEV than what competing builders have access to, a builder will be able to submit higher value blocks to the validators and land on chain more often.
    • Some builders have been able to secure exclusivity agreements with certain wallets and applications to route their transactions only to them. In exchange for this exclusive order flow, the builders pay compensation to the transaction originators.
    • Searchers do not submit their bundles to every available builder, which differentiates order flow between builders. While it may seem that the optimal strategy for searchers is to send their bundles to all builders (to maximize the chance of being included in the next block), this does not happen in practice. Every searcher does not trust every builder (due to the potential for MEV stealing and other adverse execution) and some builders charge a fee for their services, which might affect the profitability of specific strategies such that they prefer not to send bundles to such builders.
    • This means that many searchers will send their bundles to the block builders who are historically most successful at landing their blocks on chain.[25] These searchers do not send bundles to less successful builders unless they can be certain that their bundles will not get stolen or censored. This trust is a very defensible moat for the incumbents. New builders can only really break into the market by initially operating at a loss through block subsidies (i.e., paying above the value of the block to win the PBS auction) or by paying for exclusive order flow.
    • Note that different sources of orderflow will have a varying amount of value in different blocks. This explains why the builders’ respective market shares fluctuate in the short term. In the long term, builder sophistication and ability to secure relationships with order flow originators explain the gradual changes in market share.
  • Another contributor to differentiated order flow is the fact that some builders run their own searchers. Such searcher-builders might be willing to pay a larger share of the MEV they extract, because even if they do not make a profit with their searcher, the value of landing the next block might be enough to compensate.
  • This is best exemplified by a few specific builders (like, beaverbuilder & rsync) that compete on CEX-DEX arbitrages (section 5.2) with their own integrated searchers. Research has shown [26] that when prices on CEXes change significantly within the span of a single block, a builder-searcher’s chances of winning the next block increase drastically, specifically due to their ability to subsidize their blocks with their CEX-DEX arbitrage profits. Data analysis in the article showed that if the price of a liquid token changed over 2% within the 12-second block time, the chance that a CEX-DEX extracting builder-searcher won was over 96%.
  • Builders also make different decisions on which bundles to include in the blocks that they submit. Some relays censor blocks that aren’t compliant with US sanction regulation (OFAC), while others run different block building algorithms and are able to construct more profitable blocks that way. Some block proposers are only connected to such relays, and therefore when it is their turn, only builders that also build “regulated” blocks can win.

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?

  • Some builders operate their services as a public good, to ensure censorship resistance, that there is a neutral alternative that searchers and users can send their bundles through.
  • Other builders offer the service as sort of a loss-leader as a part of a full-stack of MEV solutions that they offer to searchers, some of which would not work without a dedicated builder. Examples include transaction simulation, fast access to mempool data or co-location with infrastructure (to lower latency).
  • Lastly, the searcher-builders extract MEV using their internal searchers and by capturing MEV that is left on the table by other searchers, by, for example, merging bundles and conducting bottom-of-the-block arbitrage.
  • Some builders have also charged fees from searchers but this seems to have fallen out of fashion. A builder could charge a fee for its services if it produces blocks that are more valuable than the competition by at least the fee amount.
  • This can be possible if the builder has access to exclusive order flow or runs their own searcher that increases their block value. As MEV opportunities can disappear quickly, some searchers are also willing to submit bundles to such builders, if this increases their chances of being included in the next block.

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

  • It might be that a block builder can be trusted to in 99% of cases, when the MEV extracted is relatively small. In cases where the opportunity is large enough that it is equivalent to months or years of block building revenue, a builder might be tempted to steal the bundle. This is even though this would most likely end their business, as other searchers would not trust them after this.
  • Even if builders do not outright steal bundles from searchers, they can still benefit from their position. This includes frontrunning transactions, outbidding competing searchers with their internal searcher (knowing the exact amount they bid), or using the information from the transactions off-chain.
  • This explains why many searchers only submit to so-called “neutral builders”, builders that do not run an integrated searcher that could create a conflict of interest with other searchers. Builders' actions are opaque, especially if they exploit their informational advantage on off-chain venues. Verifying that a “neutral” builder is truly neutral is difficult, and trust that can really only be built over time and by building relationships.
  • A natural question to ask is: how can it be guaranteed that a builder loses its business after stealing a bundle? How would other searchers even find out?
    • The searcher whose bundle was stolen by the builder would be able to see that a different address from theirs executed the bundle that they originally submitted. After this, the searcher whose MEV was stolen would likely stop using that builder.
    • If this builder were to continue stealing bundles, eventually enough searchers would stop using it such that the builder’s orderflow would be significantly worse than the other builders. After this, it would no longer be able to produce valuable enough blocks to send to the validator for inclusion on-chain. This is because it would be building blocks from a much smaller selection of bundles than other builders, which limits the likelihood that it constructs the most valuable block available.
    • Consider that this is the dynamic even when no searcher leaks the information that their MEV was stolen by a builder. Since most searchers communicate with each other on channels like Discord & Twitter, the information about stealing would likely leak eventually and thus cause an even quicker collapse in the bundles submitted to the MEV stealing builder, nailing the final nail in their coffin.

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 request
Part 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

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

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

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:

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

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

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:

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

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?

  • The relay spares miners from denial-of-service attacks. If a miner had to filter through all the bundles that were submitted to it, others could make the miner unable to build blocks by sending it a massive number of worthless bundles. A miner could have executed this attack in order to get rid of its competition.
  • Another benefit is not having to worry about simulating the effect of the bundle before including it in the block. This means miners can focus on mining and still reap the benefits of MEV extraction.
  • In this system, the miners are also unable to steal MEV bundles from searchers without being noticed and put on the Flashbots blacklist. The relay is able to compare the bundles it submits to the miners with the blocks that end up on-chain and to identify if a miner has submitted a bundle from a searcher without paying.
  • In the past, searchers would have to build trust with individual mining pools, which further increased centralization both on the searcher and the miner front (with only specific entities being trusted and therefore being able to extract MEV).
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.

  • By ensuring that all validators have access to the most efficiently built blocks, PBS ensures that even solo validators staking just 32 ETH can earn the same yield as huge validator operators. By minimizing the threshold to get the highest yield available, PBS promotes decentralization at the validator level.
  • From Econ 101, we know that the specialization of actors in a marketplace tends to also result in better outcomes. The belief is that by separating the roles of validator and block builder, builders can focus on trying to create the most profitable blocks without having to worry about running a validator. This in turn leads to higher yields and thus more value produced for the entire ecosystem.

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.

  • Centralization happening at the consensus level (validators) poses a more severe problem than centralization at the block-building level. In a world where block building is centralized, validators can still source blocks through the mempool and circumvent the block builders. If the consensus layer was centralized, there would be no recourse against censoring validators.
  • Additionally, block building is more accessible from a resource intensity point of view. While block building requires significant technical sophistication and capital investment, entering the market is more accessible. Without PBS, new entrants would have to both source the immense capital required to be picked as a block proposer often and develop the necessary block-building algorithms.

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.

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

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

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.

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:

  • Exclusive order flow means that some builders have access to transactions that other builders do not, making them able to land blocks on the chain more often. The more transactions and bundles you have to choose from, the more likely you are to find the most profitable combination available. This effect can compound, because it is easier for builders that have a high win rate to secure exclusive order flow agreements with applications/wallets/searchers. These parties want their transactions to be included on-chain as quickly as possible, which means sending bundles to the builder that wins most often. These exclusivity agreements would include a payment from the builder to the originator, which explains why the wallets would be willing to submit to only one builder.
  • Even if all builders had access to the same transaction flow, building the most profitable block out of those transactions is a difficult engineering challenge. The best-capitalized teams will be able to spend more to research and optimize their block-building algorithms, leading to a situation where only a few builders have the necessary capital to compete in the market.
  • Flashbots feared that cross-domain MEV would mean that block builders with resources to extract MEV across multiple chains/domains would be more competitive than builders that only build for one chain. This is validated by the fact that one of the largest contributors to block builder centralization is integrated searcher-builders having a significant competitive advantage on CEX-DEX arbitrage (a form of cross-domain MEV).

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:

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:

  • 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:

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?

  • 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?


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.


  1. 1.

    Note that there is no global mempool. It is local to each validator and always evolving. Ethereum nodes become aware of transactions at different times, because transactions are gossiped in the peer-to-peer network, not sent to everyone at the same time. For further exploration of the mempool, check out by Blocknative.

  2. 2.

    Block builders are responsible for the construction of the entire block, so transactions that are not included in a searchers bundle (because there is no MEV to extract from them, or no one is willing to extract it) are also included because the block builder picks them from the mempool.

  3. 3.

    Term coined by Ethereum Robust Incentives Group. See also: Infinite Games, Frontier Research.

  4. 4.
  5. 5.

    With the possible caveat of ordinal NFTs.

    See also: On the Instability of Bitcoin Without the Block Reward, 2016, Carlsten et al. Describes how Bitcoin miners could steal transaction fees from previous blocks through intentional reorg attacks.

  6. 6.

    Miners Frontrunning, pmcgoohan, 2014

  7. 7.
  8. 8.
  9. 9.
  10. 10.
  11. 11.
  12. 12.

    A new game in town, Frontier Research, 2023

  13. 13.

    We include multiple blocks here because in some forms of multi-block MEV, extraction happens across multiple blocks, but by pure reordering, like in sandwiching.

  14. 14.

    This is MEV, Xinyuan Sun, 2022

  15. 15.

    Something being a valuable, even necessary service does not mean that the current way in which it is provided is unambiguously “good”. Designs might make users overpay for a service, meaning that the MEV / cost of service is higher than it would be in a system with better mechanism design.

  16. 16.
  17. 17.

    MEV Supply Chain, Stephane Gosselin, 2022

  18. 18.

    Further reading: What are Flash Loans?

  19. 19.

    As an example, the MEV bot jaredfromsubway.eth takes inventory risk by holding memecoins while sandwiching users trades: "How Jaredfromsubway.eth Dominates Sandwich Bots and Rules the Meme Crypto Market", 0xFF

  20. 20.
  21. 21.
  22. 22.
  23. 23.

    Note that this is different from an OFA, because opportunities are still available for competition in an OFA.

  24. 24.
  25. 25.

    This data is publicly available on sites like or

  26. 26.
  27. 27.

    From discussions with a block builder: the cost of running a builder is over 30k/month + salaries for multiple developers.

  28. 28.

    This is how decentralized staking pools like LIDO, Rocket Pool or Ankr on Ethereum are able to generate yield for much more than just 32 ETH.

  29. 29.

    One example is multi-block MEV, where a node operator that knows they are proposing two blocks in a row, can hold off on extracting MEV in the first block, to maximize the amount that can be extracted in the second (i.e., allowing prices to diverge, to maximize arbitrages). Practically, there have been very few examples and in the absence of such opportunities, operators would be better off running MEV-boost.

  30. 30.
  31. 31.
  32. 32.
  33. 33.

    A Tale of Two Arbitrages, Chen et al., 2023

  34. 34.

    Robert Miller from Flashbots on jaredfromsubway:

  35. 35.
  36. 36.

    Example of such an attack, where a bot bought 200k worth of a token, but was unable to sell the whole position afterwards:

    A developer can program some safeguards to check for such attacks, but it is difficult to cover all potential attack vectors and they make the bot less gas efficient.

  37. 37.
  38. 38.

    Even this was not enough to fully protect from MEV stealing, it just made it extremely rare. A vulnerability in the Flashbots relay made it possible for a block proposer to submit an invalid block header, which allowed it to submit steal $20M from a searcher without having to “outrace” the relay. This has been fixed:

  39. 39.

    Ideas for incentivizing relays, Daniel Marzec, 2022

  40. 40.

    Dashboard visualizing the current situation relating to censorship of OFAC-sanctioned transactions:

  41. 41.
  42. 42.
  43. 43.
  44. 44.

Everything You Need To Know About Order Flow Auctions

BY Monoceros Ventures
Order Flow Auctions
  1. 1. Introduction
  2. 2. What is an Order Flow Auction?
  3. 3. The history of OFAs
  4. 4. Do we really need OFAs?
  5. 5. How to design an OFA: desired properties & architectural dimensions
  6. 6. Design Dimensions of an OFA
  7. 7. The Order Flow Auction landscape
  8. 8. Conclusion
Part One


The capturing of Maximal Extractable Value ("MEV") usually comes at a cost to the end users of a protocol. Users might need to pay significantly higher prices for tokens and wait longer for transactions to be confirmed. This threatens the adoption of DeFi apps, as centralized alternatives are able to provide a better user experience.

One solution that has gained significant traction in the past year is Order Flow Auctions ("OFAs"). Users send their orders (transactions or intents) to a third-party auction, where MEV-extracting searchers pay for exclusive rights to run strategies on their orders. A significant portion of the proceeds in the auction are then paid back to the user, to compensate them for the value that they create.

We identified over 27 different OFA solutions, many of which have collected significant funding. The design space for these solutions is wide and teams have to make trade-offs between user welfare maximization, decentralization, and trustlessness, among others. We identify two main axes of differentiation between deployed/announced solutions. OFAs can be intent or transaction-based, and they can be specialized or general.

Part Two

What is an Order Flow Auction?

Users interact with Ethereum in a way that allows sophisticated third parties to extract value from their interactions. We call this value Maximal Extractable Value or MEV (stay on the lookout for our forthcoming primer on MEV). Currently, most users get nothing in return for the value they create for third parties to feast on.

Let’s recap the usual lifecycle of a blockchain transaction on Ethereum to understand where the value that users generate is currently flowing.

Consider a user who wants to swap ETH for USDC.

  • Step 1 - Intent expression: They express their intent to swap through a dApp front-end, which prepares calldata (which instructs the Ethereum Virtual Machine what to actually do) for a transaction.
  • Step 2 - Transaction signing: The user signs this transaction using a wallet and sends it to the Ethereum mempool through an RPC endpoint.
  • Step 3 - Searching: The mempool is constantly scanned by searchers looking for transactions that they can include in a bundle and send to a block builder.
  • Step 4 - Block construction: The block builder collects bundles from multiple searchers and tries to create the most valuable block from the bundles sent to it and other transactions it has access to (e.g, simple transfers, transactions not included in a bundle by a searcher). The block builders send the blocks they assemble to the block proposer via a relay.
  • Step 5 - Block proposal: The block proposer commits the most profitable block it receives and propagates it to other nodes in the Ethereum network.

Block builders must construct blocks using non-overlapping bundles. This means that if two or more bundles contain the same transaction (which is basically a guarantee for most opportunities), a builder can generally only choose one of them. Builders will thus usually choose to include the bundle that promises to pay it the most since that maximizes the amount that they can pay to the proposer for inclusion. This means that searchers will iteratively bid up the promised tip to the builder, even up to the point where most of the MEV is paid to them. [1]

The key takeaway here is that validators, who are just running the right software (MEV-boost), receive most of the value extracted. The searchers and builders who do the hard work of actually extracting the MEV often only get a small share (depending on the strategy) and the users creating the transactions get nothing.

Order flow auctions (“OFAs”) help us flip this dynamic on its head and compensate those at the beginning of the funnel (users, wallets and dApps) for the order flow they originate.

Informally, an OFA is a mechanism to pay back the users for the value that their transactions contain. It achieves this by selling user orders in an auction where searchers compete for the exclusive right to extract value from them. A portion of the auction revenues is then paid back to the users.

The user sends their transactions to the auction instead of the public mempool. The searcher bidding the most in the OFA wins the right to extract the MEV. One way to achieve this is to withhold full transaction data until the transaction has been sold. This would mean that only one searcher could submit a bundle with the auctioned transaction to a block builder.

Where previously searchers had to tip the validator to secure a placement in a block, now, since no other searcher has the same transaction, they can bid the minimum to be included in a block and still extract the MEV. This does not mean that the searcher profits more, the competition just happens at the OFA level, with the profits being competed away at the benefit of the order seller. With OFAs, validators receive less MEV, and a portion of those profits flows back to the user.

Now that we have a high-level understanding of OFAs and their purpose, let's approach this more formally.

TLDR: As the name implies, an OFA is an auction. Therefore, there must be a seller, a buyer, and an auctioneer.

  • The auctioneers are the OFA platforms.
  • The sellers are the order flow originators (dApps, Wallets, users).
  • The buyers are the searchers/bidders.

What is being auctioned?

  • Orders, that can be blockchain transactions or other arbitrary signed messages (i.e., intents, more on this later).

How do the transactions auctioned get added to the blockchain?

  • Block builders connect to the OFAs & build the most valuable block available to them, hoping their one is the highest profit that the block proposer receives.

We refer to the framework proposed by Frontier Research to formalize the concept of OFAs. [2] Most OFA designs should have the following stakeholders, although some of the roles might be shared by the same entity through vertical integration (more on this later):

1. Order Flow Originators (“OFO”)

  • OFOs are either the wallets, dApps or custodians that the users interact with to transact on-chain.
  • Depending on the OFO used, the order is either a fully formed transaction or other cryptographic commitment (signed message/intent), which if executed allows access to the user’s funds on-chain.
  • OFOs send the orders to a specific preselected order flow auction provider (auctioneer – see below). They are incentivized to send a specific order to only one OFA at a time (to maximise payout).

2. Auctioneer

  • Receives orders from OFOs and holds the OFAs. The auctioneer will reveal varying degrees of information about the orders in the auction, and select the winner based on a predetermined winner selection function (like max rebate to the user, max fees paid, or best price offered).
  • In some OFAs, the auctioneer forwards the winning bundle to the block builder directly, in others the winning bidder submits the bundle to its preferred block builder(s).
  • If a user’s transaction contains no MEV and searchers do not bid for it, the auction still forwards the transaction to builders, or alternatively the public mempool.

3. Bidders

  • Bidders will compete to buy the right to execute the transaction in the auction.
  • They scan the orders on offer in the auction, simulate their strategies on orders they’re interested in, and submit bids according to their expected profits. In some auctions, bidders are also responsible for submitting the MEV bundles to the block builders instead of the auction.

4. Block builders [3]

  • Receive the OFA bundles from either the auctioneer itself or the bidder who won the opportunity. Builders try to integrate with as many OFAs as possible to ensure they can build the most profitable block possible. Builders then build blocks combining order flow from OFAs with other sources the builder has access to.
  • Note that inclusion by a block builder is only a guarantee of inclusion by the validator as long as that block is the most valuable proposed in that slot. This means that most auctions/bidders will submit to multiple block builders to try to minimize the time it takes for a transaction to land on-chain. We will dive deeper into block building and OFAs later in this post.
Figure 1: Illustration of the MEV supply chain (source: Frontier Research)

But how do these transactions on sale end up in the OFA in the first place? As the transaction lifecycle above denotes, historically users have sent their transactions blindly into the public mempool, unaware of the dangers they expose themselves to in the dark forest of Ethereum. Slightly more sophisticated users might have used a private RPC endpoint to send their transactions to specific block builders, hiding their transactions so that MEV searchers could not frontrun or sandwich them.

An OFA is essentially a more versatile version of a private RPC, and it mainly gets its flow through two avenues.

Firstly, most wallets allow users to manually edit the RPC endpoint that their transactions get routed to. A user aware of the dangers of MEV, who wants to get a kickback of the value that their transaction might contain, can select an OFA provider amongst the plethora of offerings available today and replace their wallet’s default RPC URL with the OFA’s. The main problem with this approach is that most users of crypto are completely unaware of the dangers of MEV, let alone the fact that they could monetize their order flow.

Therefore, the second (and more significant avenue) of order flow acquisition is exclusivity deals with wallets/dApps. The specifics of these agreements vary, but generally, the wallets agree to set a specific OFA as their default endpoint to submit transactions. In exchange for favouring one OFA provider, they get a share of the auction revenues, some of which they might pay back to the user. This means that if the user does not edit their RPC choice (if that is even enabled by the wallet), then all transactions will go through the OFA before inclusion on the blockchain. As an example, the Telegram trading bot Maestro, signed an exclusivity agreement with bloXroute to route their orderflow through their private RPC.

On the demand side, searchers are incentivized to integrate with as many OFA providers as possible, in order to have access to the highest amount of order flow and thus potential MEV to extract. Depending on the design of the OFAs, participating in the auction can be as simple as subscribing to a data feed but might also be limited to only a permissioned set of trusted/KYCed participants or might require the deployment of on-chain smart contracts. More on this in the section on OFA designs.

Readers aware of the crypto narratives du jour might have noticed that our initial definition refers specifically to the selling of exclusive access to transactions or the explicit sets of instructions that inform the EVM on how to achieve users’ goals. But this definition is limited, as it fails to cover many potential and existing types of OFAs.

Consider the transaction flow that we outlined at the start of this chapter, the process starts with the user having some intent about the state of the blockchain in the future. Currently, we get help from dApp frontends to turn that intent (e.g. “I have X ETH, and want at least Y USDC”) into a transaction.

Instead, we could directly express this intent as some signed message, giving some third party the right to formulate a transaction for us. We can similarly sell these signed messages in an auction. The winner of the intent auction is determined either by the highest bid or by most effectively meeting the user's needs.

Some limited intent-based systems already exist (e.g., CoWswap, 1inch Fusion, UniswapX) and will become more common in the future. More on the benefits of such systems at the end of this post.

Therefore, to be more general, we give the following definition:

An OFA is a mechanism for order flow originators to be compensated for the value that their intents contain by forcing sophisticated third parties to compete in an auction for the exclusive right to fulfil those intents.

It should now be clear that one of the major implications of OFAs is that MEV value re-distribution changes significantly. Most of the MEV profits get paid to the users instead of the validators.

We think this is a desirable outcome. Ideally, most of the auction revenue would be paid to the users who create these transactions to compensate them for selling their order flow and provide them with better execution by negating some of the negative externalities of MEV.

Part Three

The history of OFAs

3.1 TradFi Origins - Payment for Order Flow

As with many things in crypto, some of the ideas around OFAs were explored in traditional finance before they made their way into the mind of crypto Twitter. For OFAs, the relevant TradFi parallel is payment for order flow (“PFOF”). PFOF is the compensation that brokerages receive for routing their clients’ trades to be executed by a particular market maker (“MM”)/liquidity provider. While mainstream awareness of PFOF increased after the retail trading boom and the emergence of commission-free trading, the topic has been explored since at least 1984 when the SEC mentioned it in a letter to the National Association of Securities Dealers (now FINRA). [4]

Why would market makers want to pay a pretty penny for the right to execute retail order flow? The main reason is a concept called order flow toxicity. [5] Simplifying, the more information that the trader has when submitting an order to a market maker, the more toxic their flow is. These traders use their informational advantage (alpha), to “pick off” mispriced quotes from market makers, which causes losses to the MMs. On the other hand, non-toxic, or uninformed flow is profitable to fill, because on average, the traders do not have an informational advantage, making it less likely that the market maker is trading at wrong prices.

So, the goal for the market maker is to try to source as much non-toxic volume as possible. The smartest traders, like hedge funds or prop trading firms, are generally not buying their Tesla calls from retail brokerages, so by paying to access flow from Robinhood, MMs can be more confident that executing against flow coming from them will generate a profit.

Does the user benefit from these dealings? While the jury seems to be somewhat out on this, research points to users generally benefitting from PFOF agreements. [6] One clear benefit is that the retail brokerages use some of the payments to cover execution costs for the users so that they can trade without fees. Secondly, users can benefit from better execution due to MMs being more comfortable quoting better prices to traders they know are less sophisticated than them.

On the other hand, best execution possible execution for the user is not necessarily guaranteed. In PFOF trades get routed to the MM that pays most to the brokerage, instead of the one promising the best execution for the trader. These two can be the same entity, but there is still a conflict of interest which is commonly cited in papers opposed to PFOF. [7]

To summarize, much like in traditional finance, in crypto, we also have parties interested in paying for user order flow because it is profitable for them. In fact, PFOF was the most common term used for the current crypto OFAs until late last year. The two terms do not exactly mean the same thing, though.

A fundamental difference is that in PFOF, the brokerage needs to find a counterparty to fill a user’s order (e.g. selling to a buyer). Crypto OFAs can be more expressive. We sell exclusive access to an order (transaction or intent), which depending on the OFA, can give the winner the right to do more than just fill a trade. In fact, in the current paradigm, transactions already define the counterparty, say an AMM liquidity pool, that the user will transact with. In this case, the searcher is just bidding to extract some of the value leakages that are inherent in our current dApps rather than to fill the order (with the caveat of JIT LPing [8]). If we move towards an intents/RFQ-based paradigm, we will see more searchers actually also act as market makers, as is the case with solvers on CoWswap or market makers on aggregators like 1inch or 0x. More on this later.

Another distinction is that OFAs can be fundamentally more open than TradFi PFOF. In TradFi, retail brokerages will sell access to order flow only to specific sophisticated market makers, like Citadel, SIG or Virtu. The promise of crypto OFAs is that we can have credible mechanisms that allow for the democratization and permissionless of access to orders. This means that anyone from Citadel to a 13-year-old can bid in the auction for user orders. However, this is not a guarantee – some OFAs will optimize for different properties, which might result in similarly concentrated markets as we see in TradFi – more on this later.

Finally, users in crypto have much more control over where their orderflow gets routed to. In PFOF the brokerage makes the choice of counterparty and auction mechanism for the trader. In crypto OFAs, wallets might set defaults, but users can also choose to send their orders through a different OFA.

So, OFAs are an old TradFi concept that was ported into crypto. When did the first OFA protocols for crypto get built? We can identify two main “eras” of innovation in OFAs, the pre-merge and post-merge eras.

3.2 OFAs before the Merge

The publication of the “Flash Boys 2.0” [9] paper triggered community-wide discussions around MEV and its impact on user execution. The first iteration of solutions involved hiding user transactions from the mempool – this is effectively what we now call private RPCs.

BloXroute was the first to the game, releasing a private transaction service for DeFi traders paying for their platform. It sent transactions directly to selected mining pools, who promised to keep a transaction private until it was mined. This service was expanded to retail users when in November 2020, 1inch released a private transactions feature that sent user transactions to trusted miners, directly through their front-end. Other similar solutions were later deployed by Taichi and mistX.

Hiding transactions did not take full advantage of the value inherent to them, and sending to trusted parties did not even necessarily prevent frontrunning (because you’re trusting the miner or its integrated searchers not to do so).

The first solution that started to resemble the OFAs that we have today was KeeperDAO’s (later known as ROOK protocol) “Hiding Game”, launched in February 2021. Users would route their trades to the KeeperDAO MEV bots which would try to extract any MEV value available. This MEV would then be redistributed in the form of $ROOK amongst participants in the Rook ecosystem (searchers, LPs, integrated DeFi protocols) according to a share that was determined by the protocol. Users could claim the rewards once per epoch (24 hours).

Bloxroute expanded its private transaction service to offer kickbacks by releasing BackRunMe in May 2021. By submitting transactions to the bloXroute RPC, a user would agree to their transaction potentially being backrun by a searcher in exchange for a 40% share of the MEV extracted. The searcher that was able to extract the most profit would be given the right to have their transaction included immediately after the user transaction (by miners that BackRunMe was integrated with).

Figure 2: Illustration of BackRunMe architecture (source: bloXroute)

The big difference between these two was that Rook hid transactions by wrapping orders in a way that only allowed Keepers that KeeperDAO had whitelisted to extract value. This also meant that users had to either use the custom trading app by KeeperDAO or a DeFi protocol integrated with them to benefit from the protection. BackRunMe theoretically supported all protocols on Ethereum by running an auction for the user transactions through an RPC (theoretically, since coverage depends on what strategies the integrated searchers were running), but it also initially required users to register with bloXroute to use the service.

In June 2021, ArcherSwap (now Eden Network), also released a product that promised users some refunds from their MEV. ArcherDAO ran bots that would extract MEV out of their user’s trades. This profit would go back to the DAO and be used to buy $ARCH tokens from the market, these tokens would in turn be redistributed back to users that had traded on the platform. Other MEV cashback or gas-free trading protocols were released in 2021 by mistX & OpenMEV.

Another significant protocol launch around this time was CoWswap, which was initially launched as Gnosis Protocol in April 2021 and spun out of Gnosis in March 2022. CoWswap was one of the earliest implementations of an intent-based swapping protocol/OFA, where users would sign an intent to trade, which would allow third-party “solvers” to compete for the right to settle the user's order. The user's transactions did not hit the mempool, protecting them from MEV. Users were compensated for their flow in the form of better prices.

Even though MEV extraction was at its then highest-ever levels during the 2021 bull market, the previous solutions did not achieve significant adoption in the market. The dark forest had not yet been illuminated, and most users were (and still are) oblivious to the perils of MEV. The market was not yet controlled by any single player and seemed ripe for the taking, but users were slow to adopt MEV protection.

3.3 Order Flow Auctions after the Merge

The merge, with its move to proposer-builder separation (“PBS”) through MEV-Boost, reinvigorated the discussion around OFAs and acted as the catalyst for the second wave of solutions popping up. PBS was meant to reduce centralization at the consensus layer, by separating the roles of block construction and proposing.

PBS is certainly successful at addressing centralization at the consensus level, allowing even the smallest validators access to the most sophisticated and profitable blocks. But it did not remove all centralization vectors, rather pushed them to the block-building layer, where sourcing exclusive order flow proved to be the main competitive advantage for block builders vying for a share of the pie.

Given the increased importance of sourcing exclusive order flow and a market opportunity that had not yet been filled, a new wave of OFAs started to enter the market. Following the example of BackRunMe, similar simple OFA architectures (generalized transaction auctions, see section 7), started to be announced in late 2022, including the likes of Blink Labs, Wallchain, Kolibrio and others.

Worried about the centralizing effects of OFAs through exclusive order flow (more on this later), Flashbots outlined the design for SUAVE in November 2022. [10] It is an extremely ambitious project with the aim to create a decentralized block builder which will also include an auction for user intents. The release of SUAVE will take some time, but in the interim, Flashbots released their own OFA, MEV-share, in February 2023. It is built around the concept of programmable privacy, where users and order flow originators can choose how much information about their transactions they reveal to the bidders in the auction. We will dive deeper into why this is important later. Here, it is enough to understand that this helps with enabling permissionless access to order flow and protecting users from frontrunning.

Due to their higher versatility and potential for higher user welfare (more on this later), intent-based OFAs, similar to CoWswap, focusing on user execution improvement have been on the rise recently. DFLow was the first to follow CoWswap, being first announced in March 2022, with 1inch Fusion being released in December 2022, and most recently UniswapX in July 2023.

Given the number of solutions announced/deployed so far, the market is starting to look somewhat saturated. As of July 2023, 1 in 10 Ethereum transactions is sent through private mempools, either through an OFA or a private RPC. [11] The main limiting factor to OFA adoption is still the lack of awareness, but as wallets, or more familiar dApps like Uniswap adopt OFAs, we can expect this number to rise significantly. This race for order flow is likely to have only a few main winners. It remains to be seen whether the first movers will emerge as the victors, or whether newer protocols can find better designs in the vast OFA design space (which we will analyze in section 6).

Part Four

Do we really need OFAs?

4.1 Why is MEV mitigation difficult?

The general approach to reducing the negative effects of MEV in Ethereum is two-pronged. Firstly, we want to reduce the total amount of MEV that exists and secondly, for the MEV that remains, we want to democratize extraction and redistribute the rewards more fairly.

OFAs fall into the latter category of solutions. They do not address the fundamental causes of MEV but create mechanisms that redistribute value back to those that originate it.

Why should we re-distribute rather than mitigate MEV? Could we not just try to get rid of it altogether at the application and protocol layer instead of building ad-hoc solutions that further complicate the transaction supply chain?

The short answer is yes, but it is hard.

Currently, the most common MEV strategies are CEX-DEX and DEX-DEX arbitrages, sandwiching, and liquidations. How would we go about addressing each at the application level?

Data from EigenPhi estimates the size of the DEX-DEX opportunity to have been 48% (or $145M) of the on-chain MEV opportunity in 2022.[12] Combining this with Frontier Research's lower bound estimate of $100M for CEX-DEX arbitrage for the same year [13], we see that these two types of MEV account for the vast majority of MEV that exists today (~$250M vs. ~$150M for other types).[14]

Arbitrageurs provide a valuable service of keeping on-chain prices between different liquidity pools and off-chain venues in line with each other. What we really need to ask, is how much we should pay for this service and who should be the one footing the bill. The answer to this will determine whether DeFi can ever rival TradFi and CEXes in financial efficiency and become something more than degens playing a game of musical chairs on various animal-themed coins.

The size of the CEX-DEX opportunity today is explained by two main factors:

  1. 1. Prices on an AMM only move when someone makes a trade
  2. 2. Ethereum blocks get committed on-chain in 12-second intervals

Both make on-chain prices stale. Price discovery occurs on higher liquidity and frequency off-chain venues, meaning that DEX prices will always lag the most up-to-date price of an asset. The LPs are the ones paying the arbitrageurs to provide the service of updating the CEX price on-chain.

The measure for this cost is called loss-versus-rebalancing (“LVR”), presented in Milionis et al. 2022 [15]. Simply put, it is the loss that the LPs suffer due to selling to arbitrageurs at an outdated price compared to if they were able to update or rebalance their LP position according to the new CEX price.

Recall our earlier definition of toxic flow. LPs trading against these arbitrageurs is a perfect case of toxic flow, which we know will cause most LPs, especially unsophisticated ones, to be unprofitable in the long term.

One proposed solution to the LVR issue has been to reduce block times significantly from the current 12 seconds. In Milionis et al., 2023, [16], it was shown that lower block times reduce the probability that a profitable arbitrage exists within a block. There will always exist a price difference to CEXes but if block times are lower, the difference in price after each block will be smaller. This means that arbitrageurs are less likely to be profitable after fees are taken into account. Lowering block times would therefore reduce the size of the biggest MEV strategy, CEX-DEX arbitrage, and help with one of the biggest issues with AMMs today, LP profitability.

Unfortunately, this would represent a significant design choice that seems counter to the current Ethereum roadmap and would have significant implications for things like home staking.

Another proposed solution is to use oracles and force users to provide an update to the price at which LPs trade, reducing losses. One could also use dynamic fees in conjunction with oracles to capture arbitrage losses for the LPs. [17]

While CEX-DEX arbitrage is a result of the difficulty of communicating between on-chain and off-chain venues, DEX-DEX arbitrage is fundamentally the result of bad order routing. If the price of a DEX pool after a trade deviates from other on-chain pools so much that even net of LP fees there is a profitable arbitrage available, the trade should have been split up across multiple pools. In this case, any backrun arbitrage profits that the searcher extracts could have been redistributed to the user as better execution.

In fact, the solutions to this form of MEV already exist, handling execution through aggregators or allowing a sophisticated third party to source the liquidity through multiple on-chain sources, like on CoWswap or what SUAVE is aiming to support.

Sandwiching represents the second highest volume MEV strategy after arbitrages. Users are exposed to sandwiching purely due to the parameters in the swaps they submit to DEXes. Setting too high a slippage tolerance means that a searcher can frontrun a user by buying a token before their buy and then selling immediately after the user to make a profit on the price change caused by the user’s trade.

There are many outlined solutions to reducing users’ exposure to sandwiching:

1. Hiding the transactions from searchers

  • If the searchers cannot see the transactions before they are confirmed on-chain, then the user cannot realistically be sandwiched. Naturally, one way to achieve this is to avoid sending transactions through the public mempool, either through an OFA (that bans sandwiching) or a private RPC.
  • If one does not want to trust the searchers in an OFA or block builders that receive the orders, encrypting transactions is one way to avoid sandwiching. One major roadblock for encryption as a solution is a decrease in UX due to latency and the required trust assumptions for things like threshold encryption or trusted execution environments. Shutter Network is one project working on this, and outside Ethereum we see teams like Osmosis and Penumbra building private transactions.
  • Privacy as a solution is also applicable to other forms of MEV where extraction strategies involve a frontrunning component, like JIT LPing or generalized front running.

2. Setting better-informed slippage tolerances.

  • Sandwiching is only really possible because users tolerate significant price changes when they are trading on DEXes. On low-liquid and volatile tokens, this can be even in line with user expectations, as speculative mania often makes users want to buy at any price. In other cases, it is just another symptom of users not understanding what MEV is and how a poorly set slippage tolerance gives free money to searchers.
  • Therefore, applications can set slippage tolerances better. DEXes can adjust slippage tolerances dynamically based on statistical patterns, mempool state, volatility of the pool, or oracle prices. While doing this, the DEX has to strike a delicate balance between avoiding leaving room for sandwich bots and ensuring that user transactions do not revert
  • A solution implemented by 0x, “Slippage Protection”, takes into account statistical patterns of slippage, when trading with specific pools, to optimize order routing and minimize the slippage suffered. [18]

3. Batch execution or singular price per block

  • Sandwiching relies on orders within a block being executed at different prices. One could require that all orders within a block settle at a specific price, which ensures that no one trading in the same pool gets executed at a better or worse price than anyone else, leaving no opportunity for sandwiching. CoWswap is one protocol that currently has currently implemented this.
  • Liquidations are another significant MEV frontier that we can address with application-level changes.
  • When a lending position crosses the liquidation threshold, MEV searchers compete for the right to liquidate a position, which involves buying the underlying collateral at a discount by repaying the loan and selling the acquired collateral for profit within the same atomic bundle.
  • Lending protocols usually pay a fixed liquidation bonus to the searchers to incentivize quick liquidations for positions that become too risky/unhealthy. But since this bonus is a fixed share of the collateral, in most cases it overpays the searcher for doing a relatively simple and commoditized strategy.
  • To avoid this, newer protocols, like Euler Finance, have used Dutch auctions to gradually increase the bonus until some searcher is willing to execute the liquidation, which ensures that the protocol is not overpaying the searchers, thus reducing the size and impact of MEV on the users.

4.2 What types of MEV can OFAs address?

Now that we have inspected how we could mitigate MEV at the application level (per MEV strategy), let’s try to formalize a framework to reason about MEV mitigation. Are there specific MEV vectors that seem particularly nebulous, and hard to address?

Frontier Research’s excellent article “A New Game In Town” [19], presents a high-level framework for reasoning about different types of MEV. In the article, the MEV available from a transaction is split into two distinct types:

1. EV_ordering [20] refers to the value that can be extracted from transactions by purely reordering, inserting, and censoring transactions on a blockchain.

  • This type of MEV does not require any risk-taking or information outside of the blockchain, meaning that if the searcher gets their bundle/strategy included in a block by a validator, they are guaranteed to make a profit.
  • MEV strategies that fall under this category are DEX arbitrages, sandwiching and liquidations.

2. EV_signal refers to the value that can be extracted through strategies that reorder, insert and censor transactions on a blockchain in conjunction with some information, or signal, outside the blockchain’s state.

  • The most common EV_signal strategy is CEX-DEX arbitraging, where a searcher executes an arbitrage non-atomically on both a centralized exchange and an on-chain decentralized exchange. The out-of-blockchain signal in this case is the price of an asset on a centralized exchange.
  • The EV_signal of a specific transaction consists of both the value of the transaction as a leg of some strategy, like a CEX-DEX arb, and the informational value that the transaction provides. One example of the latter would be using transactions from certain wallets to predict the prices of an NFT in the future.
  • Note that EV_signal depends on the utility function of the searcher. Certain transactions have EV_signal value only for certain market participants. This is because only certain sophisticated searchers can be competitive in CEX-DEX arbitraging, which requires low latency and fee tiers on a CEX, access to a block builder, the ability to warehouse inventory across multiple venues and to take on risk when competing for opportunities. This scale and sophistication advantage is a major contributor to centralization in the MEV supply chain, more on this later.
  • This is contrary to EV_ordering, where most searchers will arrive at the same value since access to the strategies is commoditized (code up a searcher and bid better than your competition) and trading requires almost no capital (due to flash loans).

Let’s consider the previous analysis of solutions to address MEV at the application level. It seems like the solutions for EV_ordering, like better order routing, hiding transactions and Dutch auctions, are easier for us to implement than the ones related to EV_signal.

This makes sense, as EV_ordering only concerns itself with the current state of the blockchain and how including transactions in specific types of bundles alters it. With better application design, we will be able to create transactions that leave less room for this kind of atomic MEV to exist.

EV_signal strategies will be harder to completely remove even if we come up with better designs because, by definition, their value relies on information that is not contained within the blockchain. [21]

Even though applications might be able to estimate the EV_signal value of certain transactions, it is likely that these estimates will not be fully accurate. It is also unlikely that a dApp would be able to extract as much EV_signal as the most informed searcher. The best searchers have a competitive advantage, for example, lower fee tiers and latency on CEXes. Even with protocol-level changes, it seems unfeasible to get rid of the informational value of some transactions (like whales selling their holdings). As long as that is the case, it makes sense to have some mechanism to sell access to and redistribute that value.

This means that no matter how hard we try, there is likely to always be residual MEV that we cannot eliminate, either due to theoretical constraints or due to the trade-offs for doing so being too steep.

It seems that solutions to address EV_ordering exist, and we seem to have some ideas on how to reduce the impact of EV_signal so… why are users still suffering from MEV and do we still need OFAs?

As with many things in tech, sophisticated solutions mean nothing without distribution. Unfortunately, most of the existing protocols have sticky user bases, most of whom are not even aware of the MEV they expose themselves to. While a new application might be better at reducing its MEV exposure, onboarding both users and potential LPs to a completely new protocol and front-end is a significant challenge. [22]

While we might expect applications to address their MEV exposure through better designs in the long term, we will still need a solution in the short-to-medium term that can address the negative externalities of MEV without requiring significant user behaviour change.

In fact, it is the ease of adoption that makes OFAs a very powerful solution for MEV mitigation. Getting MEV rebates or protection as a user can be as simple as using a wallet which sends their flow directly to an OFA (or just changing the URL of the RPC endpoint in a wallet’s settings).

But are OFAs a good enough solution in the interim? Fundamentally, we want to build solutions that give users the best possible execution. We run an auction, instead of say making users sell their own transactions because users are not able to value their transactions as well as sophisticated third parties specialized in value extraction.

OFAs achieve best execution for users because rational bidders in competitive auctions will end up bidding close to the true MEV, the sum of EV_ordering and EV_signal, of a transaction. We see this game play out in the searcher marketplace for the most competitive opportunities, and we saw this game play out in the priority gas auctions (PGAs) [23] that settled MEV before PBS was introduced. OFAs reintroduce the same iterative process of searchers seeking alpha from transactions, getting closer to the true MEV of that transaction and bidding away most of the profits in competition against each other. The competition just happens in a different venue and the main benefactor is the user, not the validators.

We will further explore this later, but it is somewhat reductive to think about OFAs as mere tools for mitigating MEV.

We can think of OFAs as counterparty discovery for users seeking the best execution for their orders. OFAs, due to their position in the transaction supply chain, are primed to benefit from a move to more intent-based applications – using MEV mitigation as a user acquisition feature, while providing services like coincidence of wants or order route optimization for orders sent through them.

To summarize, OFAs mitigate the negative externalities of MEV extraction relatively easily without forcing users to change the applications they use. Even though it is likely that a significant amount of MEV will be reduced through application-level design improvements in the long term, there is also likely to be remaining MEV that can be redistributed via the use of OFAs.

Part Five

How to design an OFA: desired properties & architectural dimensions

Designing OFAs seems quite simple: just build an auction whose winners get to exclusively execute user orders and pay the users/originators for the flow.

Unfortunately, auctions are never quite that easy. That we have a whole subfield of economics, auction theory, whose Nobel laureates are contracted by the US government to design wireless spectrum auctions should serve as a testament to that. [24]

Thus, it should come as no surprise that there has been a diverse set of OFA designs proposed and built. It is important to understand the different design dimensions of OFAs since even seemingly insignificant differences in design choices can have large effects on how the market dynamics of the OFA develop.

Before we analyze the exact design dimensions of OFAs, it will be useful to determine some of the desired properties [25] that we would like to have.

Considering the potential benefits for end users, OFAs could end up touching the majority of transactions that end up on-chain. We think the must-haves for OFAs are:

  1. 1. Maximizing user welfare
  2. 2. Robustness
  3. 3. Trust-minimization

It is also important for an OFA to 4. not significantly further the centralization of the MEV supply chain and 5. to be easy to use.

5.1 Maximizing user welfare

The main goal of an OFA should be to optimize for the welfare of the order flow originators. As described before, this can be in the form of a direct rebate as a payment for the order flow, or alternatively better execution, e.g. better price for a swap, the minimization of gas fees or optimization of other parameters that can be defined in the auction.

There are three major contributors to the welfare of someone using an OFA:

  1. 1. Execution improvement/rebate payments,
  2. 2. Speed and rate of inclusion
  3. 3. Competitiveness of the OFA.

Thus, the value that we want to optimize for can be defined as Welfare=Rebate+U(execution)Welfare = Rebate + U(execution), where U is the utility function of the user that depends on how the user's intent or transaction is executed on-chain by the winning bidder of the auction. In addition to things like price, utility depends on the speed and certainty of inclusion. The design of the OFA has significant implications on whether the user welfare increase is in the form of a direct rebate or some improvement in the outcome, more on this in the next section.

Optimizing for user welfare is not simple because most of the value that is paid back to the originator is taken from the validator. OFAs present a constrained optimization problem, where the more that is paid to the originator, the less likely inclusion becomes in the next block.

This is because the winning bidder would contribute less to the value of the block it is included in (if it even gets included). If the OFA only submits to select block builders, there is a chance that the proposing validator will have access to a more valuable block, which does not include transactions from this OFA. This becomes an even larger problem as order flow gets fragmented to multiple different OFAs, each potentially submitting to non-overlapping sets of builders, meaning that user orders compete against each other for inclusion, which further drives down the rebate.

For UX purposes, bidders participating in the auction should provide some sort of credible commitment to the user that their transaction will end up on-chain. Users should be confident that the transactions they submit through OFAs will eventually make it on-chain. There are multiple solutions to this (each with its own drawbacks), including forcing bidders to pay the users even if they don’t get included (non-contingent fees), slashing penalties or a reputation system.

The chance of eventually being included in a block is important for UX but so is the latency of inclusion. As a rule of thumb, one can estimate the average time for inclusion by taking the inverse of the total market share of the builders the OFA is integrated with, or which the searcher submits to. If a bundle is submitted to builders whose cumulative share of the builder market is 50%, one can expect to get executed within 2 blocks.

All block builders are not created equal, though. During volatile times, searcher-builders win blocks significantly more often due to exclusive order flow, and most OFAs are wary of submitting to them, which means that inclusion time increases as markets get more volatile. The obvious solution seems to send orders to as many builders as possible – however, this increases (the chances of) value leakage (more on this later).

It is reasonable to assume that OF originators, like wallets, might optimize for inclusion rates rather than best execution/rebates when choosing which OFA to send their flow to as users are more likely to notice increased latency vs better execution, e.g. price impact. This can probably be addressed at the UI/wallet level though, by highlighting in each transaction pop-up how much better the execution was relative to non-OFA execution.

Since different users have different utilities for quick inclusion, OFAs can and do also allow the user to indicate their execution preferences, whether to optimize for speed of execution (send to everyone), maximize the expected welfare (send to only specific builders), or keep the transaction completely private from the bidders and send directly to a neutral builder.

Lastly, it is also very important that there is a competitive market both between OFAs and within a single OFA. If the rewards for the stakeholders, like searchers, to participate in the OFAs are pushed too thin, or the requirements to enter are too steep, there is a danger of only a few winners emerging. These winners can then further compound their advantages through economies of scale. In general, the fewer parties bidding, the higher the chance for collusion and rent-seeking behaviour, which comes at a cost to the user due to reduced auction revenues.

5.2 Robustness

OFAs must be robust to adversarial environments – they should assume their participants are constantly trying to find ways to exploit design choices for their gain. The systems we design should still achieve the other must-have properties, even if the participants cannot be assumed to act honestly all the time.

For example, OFAs need to decide on how they deal with the same entity bidding using multiple identities (Sybil bidders), how they counter spam bids and DOS attacks or whether auction participants can collude to extract profits. Each of these considerations plays into the decisions on how to design auctions, for example, combinatorial auctions (where one bids for collections of orders rather than just one) become difficult in the presence of Sybil bidders. [26]

OFA designers and users need to fully understand the vectors of attack and respective repercussions (e.g., can any OFA participants lose funds if the system fails to work as expected?).

5.3 Trust-minimization

Given that OFAs could potentially interact with most blockchain transactions, it is important that we build systems that require minimal trust in third parties. OFAs should guarantee that winners are selected fairly, that information is not leaked to privileged parties for their gain, and that any deviations from the promises the auction makes to its stakeholders can be noticed quickly.

Most of the OFAs currently deployed are compromising in this area as most auctions are run by opaque centralized entities.

One added complexity to designing trust-minimized OFAs is the number of different vectors for collusion. OFAs could extract rents by colluding with order flow originators, select searchers or block builders. The challenge is that in crypto users are not necessarily protected by things like best-execution regulations, so some market participants can, and do, do things that are in a legal grey zone. [27]

It’s important to highlight that the fear of collusion or other market-distorting behaviour is not unfounded. As an example, Google was recently sued by the DOJ for anti-competitive behaviour in their AdSense auction [28].

One possible way to minimize trust assumptions is to decentralize the auction. However, unfortunately, trust removal often comes at a cost. Decentralization potentially results in increased latency and lower computational efficiency. Furthermore, it introduces the need to provide economic incentives for the entities running the decentralized system.

Censorship is also another consideration when decentralizing auctions/having them on-chain, as long as block building is done by parties that might have the incentive and ability to do so. One solution proposed in Fox et al. (2023), is having multiple concurrent block proposers. [29]

For many OFA designs, the bottleneck for decentralization is still technological. The theoretical designs might exist but rely on technology that isn’t quite production-ready yet. This is denoted by how Flashbots has approached the development of MEV-share, where the plan is to progressively decentralize as encryption technologies mature.

5.4. Avoiding centralization in the MEV supply chain

As covered previously, the current MEV settlement infrastructure, built around proposer-builder separation (PBS), was created to alleviate the centralization pressures arising from MEV extraction at the validator level. What it did not do is get rid of the centralization vectors completely, just moved them from the consensus layer to the block-building layer.

So MEV is a centralizing force in both vanilla block proposing and PBS, but as we will see in the next section, the introduction of OFAs can further centralization at the block builder level due to exclusive order flow and informational asymmetry. If only searcher-builders will be able to win in the auction due to their informational edge or scale advantage, we end up trusting a few trading firms with the processing of a majority of the transactions on Ethereum.

We want to create designs that do not establish an oligopolistic market of a few winning builders or searchers. But this might be a tall order, given the parallels in TradFi, we might expect only a few entities to be competitive.

It is important to differentiate between a completely decentralized market, a centralized but contestable, and a centralized but uncontestable market. It might be that a market that has a few sophisticated centralized entities winning is acceptable as long as it can be realistically contested by other entrants (which is why we think this is a nice-to-have, not a must-have for OFAs). It might even be that a centralized market that is contestable results in better user welfare if the decentralized solutions have to make trade-offs with latency or expressivity.

5.5 Ease of use

Ideally, users don’t need to know of MEV/OFAs to benefit from MEV distribution. Currently, most OFAs require the user to manually change their RPC to the OFAs, but as the space matures, we expect wallets to sign deals with OFA providers to exclusively send their order flow to them, in which case no user behaviour change is required.

It is important that the friction for bidders to join the OFA is low to ensure the market is as competitive as possible.

Given the nascency of the field of solutions, we can expect both the searcher and user experiences to improve as designs mature and are battle-tested in production. Laminar, which aggregates and standardizes orders from multiple different OFAs, is a great example of solutions bridging the UX gap. [30]

Part Six

Design Dimensions of an OFA

Next, we want to consider the different design choices that can be made when building an OFA, and how these choices affect how the OFA accomplishes each of the desired properties outlined in the previous section.

In this section, we cover the following dimensions:

  1. 1. Auction scope
  2. 2. Order types
  3. 3. Winner selection
  4. 4. Auction mechanism
  5. 5. Degree of information reveal
  6. 6. Access to order flow
  7. 7. Bidders

It is important to note that most of the dimensions are just that, a spectrum rather than a binary choice. This explains the plethora of different OFA solutions currently on the market, which we will dive deeper into in the next chapter.

6.1 Auction scope: generalized vs. app-specific OFAs

First things first, when building an OFA, one of the key things to decide on is the scope of the auctions.

We have two options:

  1. 1. Niche in and focus on single order types (usually swaps) potentially originated exclusively from a small set of applications (e.g. UniswapX)
  2. 2. Generalize and support multiple applications.

Generalized and app-specific auctions differ in the user welfare they generate, how that welfare is redistributed and, whether applications can use the OFA as a revenue stream.

Whether app-specific or generalized OFAs produce more welfare to the user is still up for debate.

The pro-specialization argument says that:

  1. 1. Users can be better compensated in the form of implicit execution improvement, which is also more efficient from a fee perspective.
  2. 2. Apps can vertically integrate by creating their own OFA and secure an extra revenue stream
  3. 3. Currently, most MEV is created by only one transaction type, swaps.

OFAs that focus on a specific type of order, like a swap, will find it easier to pay the user back in some form of implicit improvement in execution rather than a rebate transaction. This is because bidders in these auctions can specialize in filling only one order type, say swaps. The more order types are included, the more complex the auction becomes from the perspective of compensating users in terms of implicit improvement.

Implicit improvement is also more efficient from a fee perspective. To see this, let’s think about a backrun arbitrage. We have two trades, by the user and the searcher, both of which have to pay LP and gas fees. We also pay fees for the rebate transaction paid to the user for selling their transaction in an OFA. If the OFA compensation came in the form of a price improvement, there would only be one transaction, paying LP and gas fees only once.

Another advantage that specialized specific auctions have relative to generalized ones is that they can serve as an additional revenue source for dApps. In many OFAs, the auctioneer takes a cut of the revenues on offer as compensation for building and maintaining the service. If a dApp creates its own OFA and incentivizes sending flow from its app to that OFA, then they’re able to retain some value that would otherwise leak to the generalized auctioneer. As an example, the Uniswap Governance will have an ability to charge a fee of up to 0.05% from the output of each UniswapX transaction.

The pro-generalization argument is twofold:

  1. 1. OFAs want to maximize their potential addressable market
  2. 2. The whole can be larger than the sum of its parts (all single-order types). The more orders and order types in an auction the higher the chance of complementary order flow

There are cases where the searcher will be willing to bid more for two transactions in the same auction, due to complementary order flow, than for those transactions separately. As an example, a searcher could bid for an oracle update that would enable a liquidation, which in turn would create an arbitrage opportunity on some DEX pool. The searcher is willing to pay more in a general OFA, due to the certainty that winning a single auction provides, vs. having to potentially compete for these opportunities across multiple auctions.

It’s important to note that this also has a second-order effect: because OFAs benefit from a flywheel effect (the more orderflow, the better the execution, the more order flow,….) it is reasonable to assume that the market might see significant concentration, which is further exacerbated by the fact that OFAs generally operate under exclusivity agreements. Wallets will want to use the OFA that optimizes either their users' execution or provides them with the most cash flow. If complementary order flow makes each transaction in that auction more valuable, then wallets are more likely to choose a general OFA as their provider.

While it might be more efficient from a gas and blockspace perspective to provide better execution rather than paying rebates, it is worth considering the commercial implications of this decision. For the average user, rebates will be more easily noticeable than improved execution.

An analogous example from the real world is grocery rewards programs, where a customer might earn some points that they can use towards other purchases in some store. The customers could just instead go to a discount store without any loyalty programs and buy the goods for cheaper, but it feels better to accumulate some rewards than just pay a lower price.

6.2 Order Types: Transactions vs. Intents

OFAs need to decide whether the orders on auction are transactions or intents. Both types of orders represent some wish that a user has on the future state of a blockchain but differ in what kind of constraints they put on the execution of that wish.

Let’s consider a user with 10000 USDC that they want to swap for as much ETH as possible. We can represent this order as both an intent and a transaction.

A transaction in this case is a set of explicit instructions, or computational path, that transition the state of the Ethereum Virtual Machine to one where the user’s wishes are met. In our example, the transaction would explicitly specify which smart contracts need to be interacted with (e.g. Uniswap) and what data must be provided to them (e.g., how much the user is willing to trade, slippage tolerance).

An intent on the other hand would be a signed message sent to a third party, that instructs its receiver to work within certain constraints (e.g., net at least 5 ETH or fill the swap within the next 10 blocks) to create a transaction that achieves the goal specified in the intent (swap as much of my 10000 USDC to ETH as you can).

So, the difference is that in the first case, the user has already set the computational path that must be taken and there is very little that the winner of an auction can do to change the execution of the transaction. In the intent case, the third party, or the winner in the OFA, needs to craft a computational path and create a transaction that achieves the user's goals within the constraints provided.

In intent-based systems, participants in the auction need to be specialists in execution optimization. It is up to the bidders to formulate the explicit computational path, or blockchain transaction, that achieves the user's need, like swapping 10000 USDC to as much ETH as possible. The benefit here is that because the auctioneer can simulate the outcome of the proposed transactions, it can also select the winner of the auction to be the third party that achieves the largest optimization in execution rather than who bids the most.

All the currently released intent-based auctions allow only permissioned actors to execute user intents. This is because relative to transaction-based systems, users have to put a lot more trust to the solvers in intent-based auctions.

This is because the user gives relatively free reign for the solver to formulate transactions that achieve their intent. To protect users from malicious solvers, protocols like CoWswap require the solvers to bond a significant amount of value that can be slashed and paid back to victims in case of malicious or unintended behaviour.

Looking at the other desired properties of OFAs, intent-based auctions seem to further centralization in the MEV-supply chain as providing optimal execution will require a lot of sophistication, potentially even the willingness to take on risk (using active on-chain liquidity to match user orders) or to hedge positions accumulated on CEXes. It seems likely that intent auction participants integrated with block builders will be in an advantaged position. This is further exacerbated by the fact that, unless trust assumptions for the executors can be relaxed, access to the orders will be permissioned.

Interestingly, if we think about any intent-based architecture for a blockchain app, if the selection of the third party that gets the right to execute the user's intent happens through a competition to improve the user’s execution, then this architecture meets our definition of an OFA. Even though most of the currently deployed OFA protocols are transaction-based, as intent-based architectures become more common, so do intent-based OFAs.

Intent-based OFAs do not have to be completely general (e.g. SUAVE) and can instead focus on just a specific type of intent (e.g., CoWswap). More on this in the next section.

6.3 Winner Selection

OFAs need to make a choice about what auction type to implement, which price the winning bidder pays, first-price, second-price or maybe even a descending price (Dutch auction) and whether to make the bids public or private.

Each choice affects the auction’s competitive dynamics in subtle ways and limits the extent to which the auctions are resistant to different types of adversarial bidders or sellers. Most of the currently released OFAs are sealed-bid first-price auctions.

Fundamentally, we want to design systems that maximize user welfare. From our previous analysis, we know that selecting the bidder that promises the highest rebate might not achieve this because the inclusion rate might be decreased. So, the auction needs to decide whether to sell the order flow to the bidder which promises the validator the most or which promises the originator the most. Most OFAs seem to have chosen to impose a specific split of MEV back to the originator and the validator, anywhere from 40/60 to 90/10 (with a small fee potentially taken by the OFA itself), trying to find the sweet spot that maximizes utility as a function of inclusion rate and auction revenue.

Alternatively, the OFA could just let the free market decide the split, giving execution rights to the bidder that promises to pay the user the most. In this case, inclusion times could become a serious issue as the competitive market would probably drive the user refund near 99%, at which point the validator could often find more valuable transactions to include in the next block. This explains why currently only MEV-share seems to have allowed searchers to customize the split.

Intent-based OFAs need to consider different notions of a winning bid because there the competition can happen on the improvement in execution, not just the rebate, so the auction has to have a clear notion of what it means to achieve better execution. This will be easier in app-specific auctions, like swaps, where you can select the transaction bundle that achieved the best price.

6.4 Auction Mechanism: Per Order vs. Batch Auctions

Most OFA solutions in the market are per order, meaning that bidders bid on the right to execute specific orders. In a batch auction system, like CoWswap, the bids are submitted for the right to execute some batch of orders, e.g., all the orders going into the next block.

Batch auctions are better at uncovering the synergies of order flow thus potentially resulting in higher auction revenues. They are not as easy to implement and suffer from an attribution problem, though. If a bidder is paying a certain amount for a batch of orders, it is hard to say how much each order in the batch contributed to the value of that bid and therefore “fair” redistribution to the originators is harder.

An interesting variation of this is combinatorial auctions, where you are able to bid varying degrees based on a combination of different orders on offer. One could imagine a situation where an auction has orders A, B, and C on offer and a bidder has a strategy that he could extract value from only if he could execute on all three orders. In this case, a per-order auction would result in lower bids overall, because the bidder would have to take into account the risk of not winning the other two auctions. In a combinatorial auction, this preference could be expressed as a conditional bid, where the searcher would bid X for all three orders, but 0 for any other combination of them.

Robustness is not easy to achieve with combinatorial auctions. Just consider a case where one of the orders (say A) on auction was submitted by someone also bidding in the auction. If this entity wanted to have access to orders A and B, they could now bid higher than others for that same combination, because they will get a portion of the auction revenue (as they are selling one of the orders on auction). So, for a combinatorial auction to be robust and competitive, it needs to ensure that the same parties cannot be bidding and selling transactions, which might be difficult to achieve in crypto, at least without trade-offs.

6.5 Degree of Information Reveal: Private vs. Public Orders

OFAs must decide on how much information (about the orders) they reveal to the bidders. How much information gets revealed and to whom is important because the more information about the orders you provide, the more value from the transaction can leak outside the system.

Value leaks from the auction if users get frontrun by searchers but this is only possible if searchers are aware of the transaction in the first place.

Since we are selling the orders in an OFA, we could just not allow searchers to submit sandwich bundles, as a condition for participating in the auction. The first problem with this is that it introduces additional trust assumptions, but the bigger issue is that it might only fix frontrunning within a bundle. Block builders and searchers might still able to sandwich or frontrun users as part of other bundles included in the same block, before and after the targeted transaction or by using the information provided by the transaction trading on off-chain venues.

From section 4.2, we know that in a competitive auction, bidders bid close to the MEV of a transaction. This value is the sum of the EV_ordering and the EV_signal of that transaction. The goal of the bidders is to arrive at estimates for both of these values on each order they bid on. The less information that is shared about the order, the less confident the bidder can be about their bid being profitable, which likely leads to smaller revenues overall. Here it is likely that more sophisticated players who are able to take more risk will win more often in the OFA, potentially leading to further centralization in the MEV supply chain. One way to address this issue is to build an auction that enables the bids to be changed based on the contents of the orders (programmable bids), but this does not seem easy to achieve.

Let’s consider a concrete example to understand what kind of data can be hidden. Given an order to swap assets on Uniswap, a privacy-optimizing auction would potentially only reveal the pool that a user is trading in, but not the size or direction of the swap, making it impossible to sandwich if trust assumptions hold. A searcher could try to extract value here by submitting two orders, one buying and one selling, where one of the transactions would revert. Alternatively, the strategies can also be run on-chain, where the strategy triggers itself when the user transaction (and the information it contains), the input of the strategy, gets revealed.

One could also design auctions where only the winner has full access to the information of the order. This is valuable since some EV_signal strategies rely on certain information only being available to as few people as possible. We call this the exclusive informational value of a transaction. As an example, there might be a big pending sell order on a token one has exposure to. If this order was submitted to an OFA where every bidder had full access to this information, there would be no exclusive informational value, as every bidder could react even without winning the auction. If the full information of the order is given only to the winner, the bids could be higher, as they can take into account the exclusive informational value of the order (e.g., how much less you lose on a trade because you can hedge based on the information in the auction). On the other side, the searchers would have to bid based on some expected value model, with uncertainty that could reduce the auction revenues overall.

We could develop this idea even further. Instead of only revealing information about a single transaction to the winner of the auction, we could auction access to order flow for an entire block. The bidders in the auction would bid based on the expected value of the order flow. Because only the winner of the auction has access to the full information about the transactions, they can capture the maximum EV_signal (extraction and informational value) and EV_ordering (increased due to order flow synergies) available from that order flow.

Going back to our definition of user welfare (which we want to optimize for), on one hand, hiding information might make U(outcome) better because users are protected from frontrunning strategies, on the other, the less information the bidders have, the less they will bid (to avoid losses), which reduces the rebate paid.

It is also very important to understand the trust assumptions while using a privacy-enabling OFA. Orders going through an OFA will always have to be processed by some intermediary that runs the auction logic. The stakeholders in the auction will need to be confident that no information is being shared with any other participants for their gain. Because block builders need to see the contents of the transactions to build blocks the private auctions can only send to a trusted set of builders, contributing to centralization.

Solutions to this include forcing builders to commit some capital subject to slashing conditions (which could still limit the set of builders) or using trusted execution environments. Building a credible system that can enable some of these privacy functionalities without centralizing the MEV supply chain is one of the reasons SUAVE is in development.

Optimizing for privacy while ensuring that the system is credible requires quite complex designs, which can potentially limit the expressivity of privacy-focused OFAs in the short- to medium-term. Things like intent-based swap fills with active liquidity become much more difficult to achieve and the less information you provide to a market maker, the worse a price you will get.

6.6 Access to Order Flow: Permissionless vs. Permissioned

The OFA must decide who has access to the order flow that is on auction. The OFA can choose to offer anyone access to the order flow (e.g., through an API) or alternatively limit access to only specific approved parties. With most current designs, the OFA also has to choose which block builders have access to the flow.

Given that limiting the bidder set makes the auction less competitive, which results in less revenue and user welfare, why would an OFA want to limit the set of bidders?

There are a few potential reasons:

  1. 1. OFAs want to avoid value leakage
  2. 2. Permissioned/permissionless OFAs optimize for different trust assumptions
  3. 3. The ability to KYC the stakeholders in the auction.

A permissioned auction is able to credibly enforce its rules. Both the bidders and the block builders integrated with the OFA can, depending on the design, take advantage of their position at a cost to the user, e.g., by frontrunning or censoring users’ transactions.

If some stakeholders misuse their position in a permissioned OFA, they can be blocked from accessing the order flow. Any malicious actor would then have to weigh the potential losses in revenue, against the gain from acting maliciously. In addition to blocking access to future cash flows, the auction can require the bidders to bond some capital that can be slashed in case the bidders misbehave.

The problem with permissionless auctions is the fact that new identities are cheap, especially in crypto. If someone misbehaves, banning is not a credible solution because circumvention is trivial in an auction that allows anyone access. The auction will therefore either have to be permissioned or require no trust in the searcher’s behaviour.

Block builders are a trusted party within the MEV supply chain. They can unbundle searcher transactions, construct blocks that cause worse execution for users for their gain, share bundles sent to them with other parties or refuse to pay the auction rebate to the user. OFAs will attempt to provide users with certain guarantees regarding to how bidders/searchers can handle their transactions, promising not to accept bundles that frontrun or sandwich users, but this is hard to enforce at the block builder level. For this reason, it might make sense to work only with a limited set of builders that have committed to specific rules on how transactions should be handled (this is what we see in the market today).[29]

In addition to trust and user welfare considerations, regulatory concerns might play a role in deciding whether to limit access to the OFA. OFAs can act as a significant source of revenue for wallets and thus, depending on regulation some wallets will want to understand who their counterparties are. It is likely that US-based wallets would have to comply with OFAC regulations and would not be able to sell their order flow to sanctioned entities, which would require KYCing all the bidders/block builders participating in the auction (or alternatively segmenting bidders/originators, much like we do with OFAC compliant relays today).

One significant issue with OFAs limiting the set of bidders and the set of block builders they submit to is that it creates difficult barriers to entry. While technical challenges might make it difficult to achieve this right now, considering the significance of the solutions that are being built, we must ensure that there is a roadmap to reducing as many reputational and trust-based barriers to entry. Otherwise, permissioned access to order flow is just another way that OFAs contribute to the centralization of the MEV supply chain.

6.7 Bidders: Builder-Oriented vs. Searcher-Oriented OFAs

Another important consideration that affects the long-term dynamics of the OFA market is to whom the auction sells extraction rights. The most natural choice is existing searchers, but an OFA could just as well sell order flow directly to block builders who run searching strategies. We can thus divide the OFA space into two categories, searcher-oriented (“SOFAs”) and builder-oriented (“BOFAs”). [32]

All of the current OFA designs on the market are SOFAs. A SOFA gives access to searchers to bid on orders and the winning bundle is then submitted to a select group of block builders for inclusion (either by the searcher or by the OFA directly).

In the BOFA case, the bidders in the OFA are the block builders. The point of a BOFA is that the auction not only grants extraction rights of a transaction to the winning bidder but also guarantees that no other block builder will have access to that transaction. To understand why this is significant, recall that builders compete against each other to be chosen by the block proposer of that slot in the PBS auction. To win, a block builder needs to build the most valuable block given the transactions and bundles it has access to. The more transactions a builder has access to (relative to the other builders) the more likely that it can construct the most valuable block in that slot. Any source of exclusive order flow will therefore make you more competitive, more likely to land a block, and thus profit. The hypothesis is that because of this, builders are willing to pay more for order flow than searchers, which would result in higher auction revenues and thus potentially better welfare for the users.

Why would a builder pay more in a BOFA?

Builders can generate profit in two ways

  1. 1. On the difference between the tips it gets paid by the searchers and what it promises the validator
  2. 2. By running their own proprietary MEV strategies that extract value by inserting new transactions, reordering and merging bundles

We expect that in a competitive auction, the bidders will bid up to the MEV available in the bundle, the sum of EV_signal and EV_ordering. Block builders are willing to bid more than searchers, because each order that they have (in a BOFA) makes them more likely to win the next block, which makes them more likely to be able to extract MEV with their builder-searching strategies.

To formalize, the builder is willing to bid EV_signal + EV_ordering + EV_builder. Where EV_builder = the increase in block win probability * builder strategy profit, i.e., the change in the expected value of the block if the order on auction is exclusive to one builder. We can see this is larger than what a normal searcher is willing to bid. [33] Further reading on this in the excellent paper by Gupta et. al 2023 [34].

So, BOFAs have the potential to result in higher auction revenues and rebates to the user, but whether they are able to generate more welfare will remain up to question as the market becomes more concentrated and the potential for rent extraction increases. While there are currently no BOFAs released, we expect this architecture to be deployed in the future, especially as builder searchers continue to have a dominant position in the block-building market.

Conclusions on OFA design

The previous analysis illuminates the difficulty of successful mechanism design. While OFAs might initially seem like a simple design, we hope it is clear from this chapter that designing OFAs is all but that. This endeavour requires a team with a sophisticated command of auction, game and blockchain theory. Teams need to thoroughly evaluate the design choices they have made and understand and be comfortable with the trade-offs that they imply. While building around and finding out might have been a valid way to build protocols when crypto and DeFi were much more nascent, when operating in naturally adversarial environments with profit-motivated participants, we must ensure that designs are made with a solid understanding of their implications.

We can choose to seek short-term efficiency and build systems that only work when limited to a known group of participants or we can build systems that do not instate a winning class due to barriers to entry. There might be a price that we pay in efficiency, but the ethos of Ethereum is not to value efficiency over all other goals – otherwise, we might as well run everything on Binance’s servers.

Part Seven

The Order Flow Auction landscape

These inherent difficulties have not deterred teams from building solutions to monetize users’ order flow. There has been a significant amount of venture capital deployed to teams building dedicated OFA solutions and in addition to this, major investments have also been made by existing teams expanding their product scope to include OFA solutions.

Let’s recall our earlier definition of OFAs – it is a mechanism for order flow originators or users to be compensated for the value that their intents contain by forcing sophisticated third parties to compete in an auction for exclusive execution rights.

We identified at least 27 solutions in public that fit this description: 1inch Fusion, Anoma, Aperture Finance, API3 OEV, Blink, BackRunMe, Brink, CoWSwap, DFlow, Essential, Flood, Fastlane Atlas, Hashflow, Kolibrio, Matcha, Memswap, Merkle, MEV-Blocker, MEV-Share, MEVWallet, Nectar, OpenMEV, PropellerHeads, Skip, SUAVE, UniswapX, and Wallchain.

This frenzy of solutions has also translated into real changes in the transaction supply chain. Recall from earlier that Blocknative data shows nearly 15% of all transactions on Ethereum are now bypassing the normal mempool and going through OFAs and private RPCs.

Figure 3: Share of private transactions (not available in the public mempool) on Ethereum (source: Blocknative)

There are many different ways we could formulate a categorization from the previously specified design dimensions. Coming up with a mutually exclusive and completely exhaustive categorization for all OFAs is difficult because even seemingly small changes in OFA design can result in large differences in how an OFA works.

We have chosen to focus on two important axes:

  1. 1. Auction generality: General vs. Specialized
  2. 2. Order types: Transactions vs. Intents

This gives us the following four types of auctions:

  1. 1. General transaction-based auctions
  2. 2. Specialized transaction-based auctions
  3. 3. Specialized intent-based auctions
  4. 4. General intent-based auctions

The following market map looks at the major released OFAs based on this segmentation into general/specialized, transaction/intent-based auctions:

Figure 4: Segmentation of the OFA landscape

1. General transaction-based auctions

General transaction-based auctions sell access to signed transactions which interact with all types of on-chain applications (DEXes, DeFi protocols, Oracles, etc.).

Most of the currently operating OFAs are of this type, which is explained by three main factors:

  1. 1. The auction infrastructure is relatively simple to implement. The OFA just needs to collect user transactions (usually via a public RPC endpoint), strip them of their signature and put them up for auction, giving the winner of the auction the full transaction with the signature and thus the exclusive right to execute. After the winner has been selected, the searcher’s bundle is sent to one or more block builders for inclusion in the next block.
  2. 2. By not limiting the types of transactions that can be put on sale, the OFA aims to maximize their potential market.
  3. 3. As we know from the previous section, auction revenues benefit from the complementarity of order flow.

While these types of auctions are easier to implement than intent-based ones, a major downside is the fact that users cannot be compensated for their order flow implicitly, with better execution. As discussed before, since the computational path is already set, the winner of the auction cannot change, for example, the order routing of a swap to make it more efficient.

Instead, these OFAs usually compensate the user by paying some share of the auction revenues (i.e., the MEV the transaction contains) to the originator with an on-chain transaction. Other models for compensation, like token-based rebates or gas payments, exist as well.

Currently, the OFAs that can be classified under this architecture are the following: Blink, BackRunMe, Kolibrio, Merkle, MEV-Blocker, MEV-Share, MEV-Wallet, and Nectar.

2. Specialized transaction-based auctions

Specialized transaction-based auctions sell rights of execution to transactions coming from specific applications.

Going back to the history of OFAs, we notice that the first released OFAs were of this type, focusing on providing DEX traders with gas-free trades or cash-back. This makes sense considering that MEV was mostly associated with (and still mostly is) DEX trading.

Because these applications are application specific, they do not need to rely only on the user changing the RPC provider of their wallet. In addition, they can directly integrate with the application to capture the MEV from the user's transactions. This can be beneficial in bridging the adoption gap with OFAs, since benefitting from rebates might not require any user behaviour change.

Deployed OFAs that can be classified under this category are API3 OEV, Skip’s OFA, OpenMEV (SushiGuard), and Wallchain.

3. Specialized intent-based auctions

In specialized intent-based auctions, users expose their use-case specific (e.g. token swapping, lending) intents to specialized third parties, who come up with a solution to the user’s wishes, a set of transactions that achieve the user’s intent within the parameters provided. This explains a commonly used name for these third parties, solvers.

One of the main benefits of these types of auctions is that being intent-based means the auction can select the winner based on execution improvement instead of how much the bidder is willing to pay as a rebate. Execution improvement can be in the form of better order routing or a market maker providing better quotes than what is available on the market, for example.

In addition to this, short-term specialized auctions are easier to implement and integrate with, as the third parties responsible for execution can specialize in one specific type of intent, like a token swap. The more general the auction gets, the more complex it will be for third parties to find the optimal way to execute user orders, which likely means that execution will suffer.

Currently, the only projects that fit under this categorization are swap-specific protocols, where users’ intents to trade are sent to third parties, either solvers or market makers, who use different off-chain or on-chain liquidity sources to fulfil the order at the best possible price. Given that most of MEV today is caused by DEX trades, an app-specific approach, focused on filling users’ trades, is not a bad solution in the short term. We expect that other types of app-specific intent use cases will emerge as the space matures, for example in NFT trading or bridging.

All of the currently released intent-based auctions allow only permissioned actors to execute user intents. This is because relative to transaction-based systems, users have to put a lot more trust in the solvers in intent-based auctions. This is because the user gives relatively free reign for the solver to formulate transactions that achieve their intent. To protect users from malicious solvers, protocols like CoWswap require the solvers to bond a significant amount of value that can be slashed and paid back to victims in case of malicious or unintended behaviour.

Currently announced/released app-specific intent protocols are 1inch Fusion, Aperture Finance, CoWSwap DFlow, Flood, PropellerHeads, Matcha, MemSwap, HashFlow, UniswapX.

4. General intent-based auctions

General intent-based auctions seem like the holy grail of OFA design. In a perfect world, all order flow would go through one trust-minimized, fully robust, composable, and user welfare maximizing OFA, whose orders are intents. This would allow us to maximize synergies of order flow, optimize for user execution and avoid market fragmentation.

Whether this world is feasible without making significant trade-offs is a separate question. There are significant barriers to achieving an auction that would be able to process all kinds of user intents.

Flashbots, with SUAVE, is one of the most prominent teams attempting to build out a generalized solution. We can think of SUAVE as a platform on top of which OFAs can be deployed and compete against each other in a permissionless/trust-minimized manner.

One such solution is Fastlane Atlas: a framework for dApps to create their own OFAs, which can be deployed on top of SUAVE as a smart contract.

Other teams that are building in this category are Anoma, Brink and Essential. Anoma is building an architecture for creating intent-based blockchains. Brink & Essential are also creating a protocol for the expression and fulfilment of general intents, and are currently focused on EVM chains.

Part Eight


In this report, we covered the past, present and future of Order Flow Auctions.

We have seen how addressing the negative externalities of MEV extraction is an existential question for the whole on-chain economy.

While addressing MEV at the application layer might be desirable, it often requires user behaviour change. Due to user stickiness and general unawareness about MEV, application-level mitigation seems like a solution that is only viable in the long term. It is also likely that even if application/infra-level MEV mitigation is successful, there will always remain some residual MEV that can be redistributed.

OFAs are an attractive solution in the short- to medium-term because they provide a way to mitigate MEV without requiring significant user behaviour change. OFAs are not a monolith, there are a plethora of designs, that optimize the user experience in different ways.

In the future, OFAs, especially intent-based solutions, can contribute to further centralization of the MEV supply chain. It is imperative for us to ensure that MEV mitigation does not completely compromise the fundamental values underpinning crypto, censorship resistance & permissionlessness.

Thank you to Mike Neuder, Danning Sui, Uri Klarman, 0xTaker, Jannik Luhn, Greg Vardy, Eduardo Carvalho, Alex Watts, Barry Plunkett, Maghnus Mareneck & the CoWswap team for your valuable feedback.


  1. 1.

    95-99% of the MEV available in the most competitive public opportunities, like liquidations and atomic DEX arbitrage

  2. 2.

    Originally presented in the excellent Frontier Tech post “The Order Flow Auction Design Space”:

  3. 3.

    Note that this also refers to validators not running MEV-boost but building blocks on their own, although no practical examples of validators integrating with OFAs exist currently.

  4. 4.
  5. 5.

    Flow Toxicity and Liquidity in a High Frequency World, Easley, Lopez de Prado, & O'Hara, 2023

  6. 6.
  7. 7.

    Payment For Order Flow, CFA Institute, 2016

  8. 8.
  9. 9.
  10. 10.
  11. 11.

    Tweet, Blocknative

  12. 12.

    MEV Outlook 2023, EigenPhi, 2023

  13. 13.

    A new game in town, Frontier Research, 2023

  14. 14.

    Note that these are back-of-the-envelope estimates using the two referenced articles. The main point is to illustrate the relative sizes between arbitrage vs. non-arbitrage MEV, not the exact figures which are hard to estimate.

  15. 15.
  16. 16.
  17. 17.

    Arbitrage loss and how to fix it, PropellerHeads, 2023

  18. 18.
  19. 19.

    A New Game In Town, Frontier Research, 2023

  20. 20.

    EV = Extractable Value

  21. 21.

    One could argue that our hope, in this case, is trying to incorporate as much of this external information on the blockchain as possible therefore turning EV_signal to EV_ordering.

  22. 22.

    There's an interesting question here about why we have been exposed to so much MEV in the first place; some of the most popular application and protocol-level designs were made when the dark forest of MEV was not yet illuminated. Nowadays, application developers ignore their protocols MEV exposure at their own risk. Testing in production does not work as well when there are teams of profit-driven on-chain prodigies ready to take advantage of every suboptimal design choice.

  23. 23.

    Coined in the Flash Boys 2.0 paper

  24. 24.

    Selling Spectrum Rights, McMillan, 1994

  25. 25.
  26. 26.
  27. 27.
  28. 28.
  29. 29.
  30. 30.
  31. 31.
  32. 32.
  33. 33.

    Note that this also applies in SOFAs where block builders can bid and send the bundle only to their builder, but to our knowledge, the only example was Rook, which is no longer in operation. In fact, these auctions would likely eventually become BOFAs, as only searcher-builders would be competitive in such an auction in the medium- to long-term.

  34. 34.