# MEV in Prod - A survey [Rough Draft]


Not why MEV, simply all of the branches of the current landscape

### Draft

Without a theory of MEV, our most useful framework to think of it as an unavoidable force in permissionless distributed systems that must be harnessed. To this end we must mitagte what MEV we can, and handle what we cant. Remove as much nuclear waste as possible, and of what we cant get rid of, lets use to create sustainable energy in the value systems of presenet. These are the main two veins to look at the ~ current landscape of ideas ~, mitigate what we can at the dapp level, harness the rest.

Will MEV kill the utopian dreams of onchain realities? No. Can it create a feedback loop that could kill the dream? Yes. Thus it should be classified as an existential risk.

Thus we are left at a cross roads, to devise systems and policies to handle this MEV substance from both sides, chain input channels and on-chain protocols. The dream here has morphed into mitigate the effects that preference ordering has on your protocol, and for what we cannot, create fair auction-like systems around chain inputs.

Total MEV


## Mitgating what we can

MEV is *mostly* a result of app level decisions. There currently exists no strong arguments for why all onchain protocols can't contain MEV but this is held simultaneously with the hope that all dapps will converge on little to no MEV. In practice we have a handful of examples that make this direction promising. We will go over those examples, and then talk about the state of thought around them to understand the limits of dapp level MEV minimization.

One important point about smart contract level approaches are that they must not all require private mempools, aka private orderflow.

#### MKR Liquidations

Over collateralized lending protocols such as Maker, Compound, Aave, etc are one of the first popular Decentralized Finance primitives to emerge in the Ethereum ecosystem. At an extremely high level these systems work as follows. Lenders deposit a principal, an amount of base currency which they then expect to earn yield on from borrowers. From there a borrower who seeks a loan can over-collateralize (~150%) of their borrow amount in various different currencies and then withdraw the desired borrow amount, and they will be forced to pay some interest over time. If the principal and borrow currencies are the same, then interest is the only thing which lowers the health of this loan. But if the currencies are different, and the asset used as collateral goes down, then the loan can reach a threshold where it will get liquidated - and this is where MEV comes in.

Liquidators, a specialized subset of the faceless bots, will race to liquidate loans on these platforms to make the lender whole. Interestingly MEV plays a powerful role in ensuring the functioning of such protocols, as it incentivizes anyone (read: armies of faceless robots) to "press the button" so to speak on making lenders whole, keeping the protocol at large in proper standing using code designed by the protocol creators .


Liquidations can be viewed as a race to access a piece of state on-chain, specifically the state that represents the underwater loan. The beginning of this race is clear, as the start is detected by those capable of detecting the state change that made the loan unhealthy, and encounters your typical race-to-the-bottom behavior as those who can get this update sooner than others have an advantage. And in USD terms, theres a fair bit of incentivizes on the table.


The question then becomes, where does the race end? Semi-generally it ends at the block proposer. But for most of Maker's lifetime it was the miners of the ethereum network, now validators. Miners would run very large arrays of computers networked together to compute the hash that gave them the rights to a block, but at the end of the day, the contents of their block would come from the mempool. This lead to a very common behavior observed in Ethereum like system when preferences are not handled properly known as a Priority Gas Auction.

The only way for these faceless bots to exert their preferences over others was akin to yelling in microphones. Spamming all available mempools with ever increasing amounts of transactions containing increasingly more value to the miner. As we can see below, this style of liqudation generally leads to a proportional increase in gas price for all. Spikes


In one of the first examples of MEV mitigation at the smart contract level, Maker transformed their liqudation from a "first come first serve" system, what can be seen as the default for all dapp Access, to a dutch auction. This had the effect of converting it from a system that was completely open to noisey bidding as soon as state was available, to a tiered system that is only available to those willing to pay at that price, and if there is no interest at a price level the auction lowers itself until someone takes. Even though there is some observed "segmentation of demand", there will still be segements with high demand and therefore a gas war, most likely smaller. These days liquidations are sent via private order flow so we don't

// Graph of this maybe?

[Source ](https://rdi.berkeley.edu/berkeley-defi/assets/material/Lecture%206%20Slides.pdf)

#### NFTs

In general dutch auctions are a great way to combat unwarranted effects of MEV. Their main advantage in the model framed here is in gating access to the contentious state by willingness to pay via a mechanism other than the gas price. Maker DAO is a great example, but there are other use cases as well such as NFTs, where the MEV profile looks different than liquidations. NFT drops are often very bespoke, using different function calls for each drop, and they only last for the duration of the drop.

In 2021 the Bored Ape Yacht Club created the largest NFT MEV event ever, creating so much demand for their 55k Otherdeeds NFTs that over $100m USD in excess gas prices were paid out to miners.


The NFT drop designers for Otherdeeds infamously made the decision to [not use a dutch auction](https://mirror.xyz/0x3ae401F245034dAe25af1e2f9b9Bb8F006b1Dc6e/ErZMh-0TTwMrAKPJ1hlDcjvNfZvQ998G-B-oTS6BVQk) to segment demand. This highlights that there are limitations with this approach. Another extremely popular NFT project [Azuki](https://www.azuki.com/) did chose to go with a datch auction drop mechanism and saw much less bidding activity in the public mempool.

[Gradual Dutch Auctions](https://www.paradigm.xyz/2022/04/gda) are a variant of dutch auctions that give more expressivity to the seller over the traditional linear decrease in price dutch auctions allow for and follows the simple rules below:


Another variant of the GDA was the variable GDA also intrdouced by Paradigm to handle the Art Gobblers NFT sale. But of course these approaches aren't without their MEV as well, as [Kulkarni, Ferreira, Chitra et al](https://people.eecs.berkeley.edu/~ksk/files/GDA.pdf) "show that the seller can deviate from truthfully running a GDA
via an attack in which she initially buys a fraction of the supply available in each dutch auction, forcing buyers to fill their demand with later (more expensive) auctions. This attack is a form of multi-block maximal extractable value (MEV), extending previous work on lending protocols and decentralized exchanges".

#### CFMMs

CFMMs (Constant Function Market Makers, also known as AMMs) are another large class of on-chain protocols that drip with MEV. The MEV profile here involves sandwiches, arbitrage, and more recently with Uniswap v3, [Just In Time Liquidity](https://uniswap.org/blog/jit-liquidity). Shown below we can see a breakdown of the size of abitrage on Uniswap.


The effect of MEV on all CFMM protocol participants, including traders and liquidity providers, is a ***very*** hot topic so we won't get into it much. But [here is an analysis](https://crocswap.medium.com/follow-up-analyses-of-lp-profitability-in-uniswap-v3-2cfc8c5e014e) that shows that the effects of MEV on Uni V3 LPs is atleast pretty bad.

Naturally the brains of the internet have been spinning for some time on how to capture this MEV and redirect it to the protocol. Although the focus of this writing is MEV handling in prod, its worth mentioning the following results which are ***not in prod*** nonetheless.

The first idea is that of a MEV capturing AMM [McAMM](https://ethresear.ch/t/mev-capturing-amm-mcamm/13336) where the core idea is to transfer rights of odering transactions from block builders to smart contract devs by introducing an accounting method + auction for selling the rights to be the first transaction. The main issue here is that this type of preference expression is only enforceable by block builders, not order flow through the public mempool, since it uses coinbase transfers and most mempools simply order by gas price. Ultimately this approach would also only solve for "first-right" arbitrage.

A further variant of the McAMM has been proposed called the Dynamic MEV Capturing AMM [(DMcAMM)](Dynamic MEV Capturing AMM (DMcAMM)). The core idea: "Liquidity pools use a dynamic fee that decays over blocks and resets every time someone swaps through the LP. This mechanism allows LPs to capture backrunning profits, is likely a more profitable fee mechanism than current static fee systems, and has the potential benefit of making sandwich attacks less feasible."

Another similar AMM variant by the first author mentioned is a [Surplus Charging AMM](https://ethresear.ch/t/mev-capturing-amm-mcamm/13336/20?u=dmarz) described as : "The right of first execution is again auctioned off globally for all AMMs, but the auction winner - called the lead-auctioneer - has to re-auction the individual slots per AMM. The lead auctioneer has to determine the auction winners per AMM and bundle their trades into one lead auctioneer’s transaction. This transaction contains the information of the highest bid per AMM-auction, and each AMM will receive their highest bid value as a fee for their LPs. The lead-auctioneer is required to prove that they behaved correctly with a zk-proof, afterwards."

One of the large holes in our understanding of MEV. CEX related arbitrage leaks value out of this pure and closed form economic system we have created. And as we will see later on, this question agains appears itself in things such as block space futures, namely, how do you value the ability to exclusive arbitrage every centralized exchange in the world for 12 seconds?

#### Batch Auction Fuzzing

<insert findings>

#### The Limits of MEV Dapp Minimization

What is extremely clear is that it is possible to minimze some forms of MEV. In fact, some have argued that JIT arbitrage acts like a "janky RFQ" system which helps route users to the best liquidity, furthering the view that when thoughtfully devised, MEV can be used as a driving force in your protocol. Even further in this direction the paper ["Optimal Routing for Constant Function Market Makers"](https://arxiv.org/pdf/2204.05238.pdf) makes the claim that sandwiching increases the total welfare of the system as a whole by forcing trades through the most efficient liquidity. But what is not clear is whether or not it is possible to minimize all forms of MEV from the Dapp level.

## Harness the rest

From this point on we consider dapps as small boxes with assmyptotically diminishing MEV over time. With this view we can consider how inputs get passed into the box, as well how the "outcomes" get incorporated into the chain.

A key part of these appraoches are that they mostly fall under the definition of private order flow. And so as discussed here [Orderflow Auctions and Centralisation 11]("https://writings.flashbots.net/order-flow-auctions-and-centralisation-II") they share the same undesirable properties of: 1) settlement risk through single point of failure and 2) credible auctioneer like issues.

If you squint a bit all of the orderflow auctions mentioned can be seen as auctions to construct partial block, and thusly each partial block auction competes with other partial block auctions for blockspace from block builders discussed later, along with block space consumtpion from the mempool.

In this light the Flashbots Auction is the first harnessing mechanism we have seen in the wild. Their auction originally consisted of a centralized API which would take execution preferences in the form of "bundles" and distribute them directly to miners (in Eth PoW). This approach was wildly succesful in mitigating the negative externalities of MEV caused by gas wars. The goal being proposers can accept blocks from an external network of builders to decrease the chances that individual validators will create their own custom clients for extracting MEV.

Many of these

### Partial Block Markets / Orderflow Auctions

#### Rook Finance
The first of these is Rook, and it most closely resembles the first flashbots auction but it also provides a market for users to auction off the rights to executing their transaction. Roughly this works by making a call to the centralized Rook API with your signed transaction. From there Rook servers will trigger an auction where trusted searchers called "keepers" bid via expressing how much MEV the original will get in return for their execution. This system very closely mimics the Request-for-quote systems of traditional finance. It is one of the largest rebate protocols live in prod. The general concerns with this flavor of protocol are that of the trusted auctioneer, as well as with latency, as more hops will remove the possibility of next block inclusion (perhaps not awful). But this has sparked the meme of "paying for shitty exeuction". On the opposite spectrum of this flavor of solution we have Cow Swap.


#### CowSwap

CowSwap can be thought of a Request-for-solution system. In the protocol designed by Gnosis, users who are trading ERC20s can sign a meta txn that is aggregated at the centralized CowSwap API. Every X seconds the protocol will agreggate all of the desired trading pairs and amounts (also known as user wants) and distribute them to "solvers" who are responsible for finding the best trading route through all these pairs, along with any coincidence of wants. This protocol completely avoids the mempool, and using theory of multi-batch auctions has lead to very large reductions in MEV from erc20 traders. To date the protocol has done $X amount of volume and its impossible to estimate how much MEV it has taken off the table, but it's sufficient to guess that its a decent amount. The general reason why this orderflow protocol is succesful at mitigating MEV is the use of private batch auctions, and the reason its not the final solution is that it's still relatively centralized (trusted auctioneer issues) along with its inability to be composable with other on chain primitives. But it works, and thats a big success!


#### Pikapool

Similiar to CowSwap, [this protocol](https://www.pikapool.cool/docs/) uses meta transactions to settle auctions but instead of focusing on DEXes it focuses on NFT auctions. As previously mentioned, these NFT events are currently handled through first price auctions in the mempool. Even further there have recently been many cases where MEV from NFT drops has been more than the aggregate auction amount to the project. By using meta-txns aggregated at a centralized API, the off-chain auction computes the results according to some bidding configuration and then resolves the bid winners on-chain through a variety of mechanisms including manual minting and publishing a merkle root.

#### General Purpose Private Order Flow Auctions

The flashbots centralized API can be viewed as an auction above all of these auctions, or it can be viewed in tandem with them. Following flashbots many organizations such as Eden, Manifold, BloxRoute, and Blocknative, have deployed their own general purpose and private auctions, largely all following the preference scoring rule published by Flashbots.

### Block Building markets

The learnings from this v1 system inspired their next generation of MEV handling protocols known as mev-boost. One of the main goals of mev-boost was to open the aperture so that block proposers could accept blocks from any party, not just the centralized flashbots API. The concept around this is also generally referred to as Proposer-Builder Separation.

#### MEV-boost

MEV-boost created a market for full blocks to be exchanged between block builders, and

#### batch vs sequential
A brief aside is necessary to look at one of the tools in our box, as well as one of the more religious debates in auction theory - continuous versus batch auctions.

The notion of batch auctions as a silver bullet to rent extraction from those with speed advantages dates back to the landmark paper by XYZ et al (link). The idea is that batch auctions turn continuous-time trading into discrete-time trading. Blockchains already have a notion of discrete-time with the concept of blocks, but within a block trading on an AMM can be considered continuous where access to information faster can lead to rent extraction. (need more here)

But the practical implications of such theorizing is not always clear, and in fact and one of the largest data sets we have around such order systems was collected during the Covid Pandemic when the Taiwenesse Stock Exchange which used Frequent Batch Auctions converted to continuous time auctions. The results are not conclusive, but Citadel wrote a report on the matter (link) and found:
- Orderbook depth increasing 2-5x
- 15% higher trading volume
- Lower bid-ask spreads and decrease in volatility by 18%

(Now let's be honest. The data is highly enigimatic given that it was duing a global recession (am I using that claim right?), but it is compared to the hong kong stock exchange trading activity at the time which feels ~semi-rigorous~ but is in no way conclusive of all markets. In addition the authors represent an organization that profits from MEV in traditional finacial systems.)

The takeway here is that batch auctions are powerful, but they also introduce complexity and may not be the appropriate auction design for all types of MEV. It's even possible batch auction designs will make their way into AMMs and dapp level protocols, perhaps even with some sort of input and output fuzzing to create anonynymity. (insert link)

Another line of work which extends the notion of continuous auctions is that of Ari Jules and Mahetma Kelkar. In their Themis paper they argue for an execution approach which operates as first come first serve. In this manner, it is not possible to extract MEV from a transaction sent sufficiently far in the past. The authors also account for the information based rent extraction that this type of model creates in tradfi by defining a notion of fairness based on time granularity. By bucket transactions come in into sufficiently large enough time periods you can remove the incentive for colocation.

Regardless of your time granularity, spam is still a viable preference expression strategy. Time granularity sort of turns first come first serve into a batch auction, except bidding is expressed in time along with spam.

Interestingly enough, the idea of first come first serve and batch auctions aren't mutually exclusive. In a forum post Flashbots' researcher sxysun outlines the design for a preference handling system which utilizes both a notion of time granularity, and then handles interbucket preference expression via coinbase transfer which allows for an expression vector that isn't spam. Sxysun also posits that 500ms is an ideal time granularity based on historic data around gas fee escalation in the mempool.

The railways for communicating bulk MEV extraction preferences through has been set, and a burgeoning market for coalescing preferences into blocks is in motion. So, where to?

#### Fuzzing Inputs to Batch Auctions

### MEV: To Here Knows When

We've discussed ways to mitigate MEV at the dapp level, as well as ideas for handling MEV that can't be minimized but there are a couple interesting ideas to explode the aperature of MEV handling in general.

#### PEPC

PEPC seeks to make more strictly enforced proposer builder agreements. That is right now the exchange of blocks between block builders and validators is completely trusted. Block Builders can easily lie about the amount of value in a block and get away with it for atleast one block. In the wild we have not seen any set-ups that remove a relay upon the receipt of a misleading block.

The goal of PEPC is in the name, Protocol Enforced Proposer Commitments. The idea here is to make it a costly expense for a proposer to commit to honoring some commitment around the inclusion of a block with potentially some set of features, adding vibrancy and tamper resistance to how the current block space market functions.

#### State of Proto PBS
Proto-pbs is defined by the introduction of three new pieces of software, mev-boost, relays, and block builders. mev-boost is a sidecar which enables validators to connect to a block production network, which is mediated by a role called the relay.