Mevitations on Moloch - a review of MEV taxonomies

MEV Taxonomy

What is a taxonomy? A taxonomy is a system or scheme for classifying things. A taxonomy is generally hierarchical, starting with broad categories and breaking them down into specific ones. The purpose of a taxonomy is to provide a structured way to review and interpret information.

Why is a discussion on Taxonomies relevant?

The discussion is relevant because people who are building both infrastructure and applications in this space can’t agree on common ways to define what MEV is and how best to go about dealing with it. Users don’t have a good mental model for how to think about MEV. In the literature, there are few attempts that bridge formalism with memes or colloquial understandings of MEV.

• What is MEV?
• Supply Chain MEV
• Modular MEV
• Sovereign MEV
• Information Theoretic MEV
• Encrypted Mempool and Metadata MEV
• Game Theory 3EV
• The Edge of MEV

Preface

This "research" is compiled for the purpose of examining the different schools of MEV thought through the prysm of relevant MEV taxonomies. The research reviews several taxonomies all putting forth rigorous attempts to explain MEV in a coherent way.

Caveats

Note that for definitions, we will refer the reader to this MEV Wiki provided by the good folks at Flashbots. For new terms like Solvers which are not defined by the Wiktionary, we will either provide a definition or links to such.

This research note is not formal in the sense that we are formally defining terminology from the MEV lexicon. Instead we are dealing with high level abstractions that can help researchers, users, and designers of systems to think about MEV more intentionally with a shared set of points of reference.

The author is not an expert in any of the domains mentioned in this note, simply a motivated observer. Furthermore, don't take my word for it, I would encourage the reader to check the references and verify that the information provided herein is valid or "true" on their own volition.

The note is not comprehensive. I am intentionally leaving out or not including other Taxonomies that were either omitted by error, less interesting, or beyond my comprehension.

This should be viewed as a working draft and as such I expect many revisions to be made before publication. Please provide feedback as you are inspired to do so.

What is MEV?

What is MEV? It's like porn, you know it when you see it.

~@tarunchitra

Maximal (formerly Miner) Extractable Value (MEV) is the value that can be extracted from a blockchain by any agent without special permissions.

~@fuii_

Some common pitfalls on the definition of the word MEV in the community. We give up on the clarity of the notion and over-formalize it such that we lose some memes. It is no longer a meme term, and we are getting lost in the detail in the real value of defining MEV.

~@sxysun1

The most common or colloquial definition looks something like this.

A notion called MEV, or miner-extractable value, measures the extent to which miners can capture value from users through strategic placement and/or ordering of transactions. Miners have the power to dictate the inclusion and ordering of mempool transaction in blocks. (Thus MEV is a superset of the front-running/arbitrage profits capturable by ordinary users or bots, because miners have strictly more power.)

This definition is pulled from the Clockwork Finance: Automated Analysis of Economic Security in Smart Contracts by Babel, Daian, Kelkar & Juels.

One common misconception which arises is mistaking Extractable value for extrcated value. In a sense MEV is always hypothetical. The value extractd is typically a lower bound of what can in theory be extracted. In general, as the chart above suggest, it's possible that the upward bound of extraction is infinite.

There has been much effort put into formalizing MEV. For example this excert from On the formalization of MEV by Alejo Salles provides a good deal of insight;

MEV is the value that can be permissionlessly extracted by block proposers by reordering, censoring, or inserting transactions.

Perhaps the definition that comes closest to formalizing this is the one given in the recent Clockwork Finance paper via the following two expressions:

(1)
\[EV(p,B,s) = \max_{(B_1, \ldots, B_k) \in B} \{b(p,s_k) - b(p,s)\}\]

(2)
\[k−MEV(p,s)=EV(p,validBlocks_k(p,s),s)\]

Here, EV is the extractable value by player pp in state ss given a set of valid block sequences \(B, (B1,…,Bn)\) is one such sequence, and \(b(p,sk)\) is the balance of player \(p\) in the state resulting of applying blocks \((B1,…,Bk)\) to \(s\). \(k\)-MEV is the \(k\)-maximal extractable value by a player pp in state ss acting as block proposer, where \(validBlocks_k\) is the set of all valid block sequences of \(k\) blocks that \(p\) can create, and single-block MEV is just 1-MEV.

Indeed, our understanding of MEV has evolved since it was first coined in Flash Boys 2.0 and expanded on in Clockwork Finance.

However, that's not what this note is about. In this note, we will not attempt to formally define or explain MEV. Instead, we will review MEV through the prism of different schools of thought or Taxonomies. Concretely, we want to keep the memes at the center of focus.

Supply Chain MEV

The MEV supply chain taxonomy was put forth by @thegostep in the spring of 2022. The framing is helpful in distinguishing how transactions on Ethereum flow from user initiated preference to fully formed and finalized in a block. The framework highlights the various agents who play a role in the supply chain.

This taxonomy has been relevant or helpful for researchers and users to understand the various agents in the block production process in a simple yet very informative way. In particular, the supply chain abstraction is useful in illustrating how MEV sharing can flow between the different agents. Ideally, in this design value flows back to users and validators through various distribution mechanisms. Thus far validators have benefited the most. However, new mechanism such as Order Flow auctions like MEV-Blocker allow users to get paid for MEV they generate.

However, its not all daisies and dandelions. MEV is a centralizing force. And left unchecked without the appropriate division of Labor of the supply chain agents we can wind up in a world dominated by one vertically integrated agent. This agent would be the MEV Thanos.

In this section, first we will review the motivation for the original MEV supply chain, touched on briefly here, for Ethereum and then provide definitions for the agents who comprise it. Thereafter we will follow with a "new" proposal from Mekatek for framing an intent-centric supply chain.

Motivation

MEV creates an incentive for block producers to vertically integrate with trading firms to boost their returns. Unchecked, this is a centralizing force in Ethereum. One solution is a technique called Proposer Builder Separation (PBS) in which validators, proposers, can outsource block building to specialized parties called builders.

Today the Ethereum protocol runs an instance of PBS called MEV-Boost, an open source middleware, built by Flashbots, run by validators to access a competitive block-building market.

With MEV-Boost, validators can access blocks from a marketplace of builders. Builders produce blocks containing transactions and a fee for the block proposer. Separating the role of proposers from block builders promotes greater competition, decentralization, and censorship-resistance for Ethereum. Today, ~80% of Ethereum blocks (500 Epochs) were built with MEV-Boost.

Agents of the supply chain

User - has a preference and wants to express the preference. Users are the individuals transacting on the network both at the institutional and retail levels. Sophisticated users can enjoy front-running (no one can place an order ahead of user transactions having seen it in advance) free execution by using services like Flashbots Protect for sending transactions. In addition, users can receive front running protection when trading by using services like COW swap. It is the user’s order flow which creates MEV opportunities. By default, users often send their transactions to the public memory pool leaking value to any motivated agent.

Wallet - Wallets are the medium with which users interact on chain. Wallets can give users the ability to send transactions over a private relay which will send their transactions to a private memory pool to be included in a block. In the future it is expected that wallets will receive payment for order flow from searchers and in turn provide better order execution and/or gas refunds to users.

Searcher - Searchers scour the public memory pool for arbitrage opportunities. A searcher will look for an opportunity to insert a transaction(s) of their own to capture value from changes in the global state. The searcher will then create a ‘bundle’ of transactions that they send using a private relay either via a service like Flashbots, Blockroute, Ethermine, et al. In some cases, searchers directly send transactions to miners. Searchers will be selective who they send transactions to in order to shield long-tail opportunities from attention or to customize their ordering preferences.

Typically, Searchers specialize in one form of MEV over another. As arbitrage opportunities have become crowded, profitable searchers have shifted their focus to long-tail opportunities. Though many searchers operate independently, there are MEV collectives like Project Blanc where Searchers work together to capture MEV while taking a large slice of the opportunities.

Searchers are experts at optimizing for gas savings, the game known as gas golfing. Some will shuffle through contract addresses to get one with as many leading 0s as possible.[32] The EVM gas fee schedule charges less for 0 bytes in a transaction’s input data. Skilled searches can optimize their contracts for more gas efficiencies by writing their contracts in the lower-level assembly language, Yul, which gets you closer to the Ethereum Virtual Machine (EVM) Byte Code (non-human readable opposite of source code).

In the past, Searchers were known to use self-destructs or gas tokens to pay for transactions.4 The tokens could have been purchased when gas prices were cheaper. Searchers leave no stones unturned in looking for ways to optimize for gas savings allowing them to bid more during auctions.

Builder - Historically, in proof of work Ethereum, the role of the builder was played by mining pool operators. Today these agents are specialized entities that aggregate searcher bundles with transactions from the public mempool in order to construct a candidate block for proposer's to choose from. The Builder is incentivized to include searcher bundles at the top of their blocks based on a fee they receive from the searcher. Builders may also operate as searchers performing a hybrid function as this can give them a competitive edge in building a more profitable block.

The Relay - The role of the relay is critical in the supply chain as it coordinates the communication and commitments between builders and proposers. Relays aggregate blocks from multiple builders in order for the Proposer to select the block with the highest fees. The consensus layer client of a validator proposes the most profitable block received from the relay to the Ethereum network for attestation and block inclusion. The relay is a centralized and trusted actor similar to the builder. Some relay like Bloxroute and the Love boat are vertically integrated with builders.

Validator - Validators play the role of block proposer. They receive full block templates from builders via relays. Validators capture a feeReceipt paid by the builder as a bid to have their block selected over the competition. The validator was designed to be "dumb" as to not have to run complicated MEV search algorithms for packing the optimal block. A rational validator will either choose to build a block locally to contribute to censorship resistance, or choose the highest fee paying block from a relay. The relay connection is at the discretion of the Validator. Not all builders send all block bids to all relays. Once the Proposer receives the bid they only need to select which block has the highest bid.

Modular MEV

A Modular world

We are moving towards a multichain and modular world where you have shared data layers which provide a high amount of bandwidth like Celestia or Ethereum along with a number of execution layers, rollups.

Horizontal MEV - cross-domain

In this multichain world, a lot of the concern is around horizontal MEV. MEV that comes from arbitrage or other opportunities within two execution layers or different domains. This is an important problem, but it's not our focus.

Vertical MEV for Modular Blockchain Stack

There exists an MEV relationship between the rollup and the data layer, but this is a vertical relationship instead of a horizontal relationship.

Now you might say there shouldn’t be any relationship between the two because execution layer trades are being done on one layer that might create an arbitrage opportunity on the other, you can atomically execute transactions on each. However, if you have an execution layer and a data layer, the DA layer itself doesn’t have any arbitrage opportunities because it doesn’t execute anything.

Why should there be a relationship between the two, the execution layer and the DA layer. It's not cross-domain MEV in the same way that the horizontal MEV described above is, it's very different.

First law of cryptoynamics: MEV cannot be added or removed, it can only be moved from one layer to another. (Observation when dealing with vertical MEV specifically, not cross-domain MEV)

Components of a blockchain

Let's begin from first principles and describe the components of a blockchain, which also apply to rollups. Rollups are just blockchains, after all.

(1) Leader selection algorithm

• who is permitted to progress the chain by extending its tip (permitted to produce new blocks)

(2) Sybil resistance mechanism (needed in any kind of decentralized/permissionless blockchain)

• need some mechanism to prevent someone from spamming a bunch of candidate leaders, e.g. PoW, PoS, etc.

(3) Block validity function - rules around the validity of the execution of a block independently of who got to produce it

• State transition function

(4) Fork Choice Rule - allows the nodes to distinguish between two otherwise valid chains that have the correct leader that has sufficient Sybil resistance amounts and the blocks are all valid. You need some way of distinguishing between these two otherwise completely valid chains

• how to choose between two otherwise valid chains

We will focus on Leader selection algortihm and the fork choice rule. Block validity, yes the specifics determine what MEV may be extractable (eg. bitcoin may have less extractable MEV than a Turing-complete blockchain like Ethereum). Leader selection and the fork choice rule come into play.

Leader Selection Algorithm

• Theorum 1

  • In a decentrlaized blockchain it is required that the leader cannot halt the chain alone (statistically)
    • in POW if one person gets really lucky they can produce every block forever.
    • one party acting alone has the ability to destroy the chain, which is isomorphic from having control over it
  • Sketch of proof: if one party acting alone can permanently halt the chain, “The power to destroy a thing is the absolute control over it”

• Corollary 1

  • If an actor is given access to the Sybil resistance mechanism, anyone can become the leader for at least one block in finit time (statistically)
    • as long as this is true the system is permissionless

• General algorithm: if the leader does not act within some finite time bound, another entity becomes the leader.

  • Why is this component important?

• Leader can capture MEV (directly or indirectly) for their blocks

  • e.g. arbitrage, front-running, back-running, sandwich attacks

• It is Difficult to manipulate most leader selection algorithms directly without some global network partitions, etc.

  • the leader is tied to a Sybil resistance mechanism like POW. You can’t just show up and say I am the leader, you have to do much work. In POS you have pre-assigned leaders which can’t be manipulated in any meaningful or cheap way.

• Manipulation of the fork choice rule could lead to e.g. time bandit attacks

  • which works in tandem with leader selection algorithm. Once you have reorged the chain you are also the leader of those blocks, so then you can engage in front-running within a sequence of blocks or a single block
  • these may not be much of an issue in an L1 context, but they may be more of a concern in the modular context.

Considerations for Leader Selection Algorithm

• Want:

  • Decentralization of sequencers (token?)
    • one sequencer = censorship concerns, regulatory concerns, monopoly on MEV, convenient way to introduce a token (stake weighted round-robin)
  • Strong liveness guarantees
    • you don’t want it so a single sequencer going down means the rollup goes down forever
  • Minimize trust assumptions
    • you don’t want to have trust that a single party is operating correctly for the chain to operate correctly
  • Minimize waste of data layer’s block space
    • waste can happen if there is some sort of contention where 2 transactions show up and one of them becomes useless and wastes the DA layer's block space

• Don’t want: MEV to bleed down to the data layer

  • depending on the leader selection algorithm, you can have MEV bleeding down into the base layer
  • you don't want that because now you have a situation where if you have a bunch of MEV bleeding down to the DA layer instead of being isolated to rollups this introduces a centralization pressure on the validators of the data layer to extract that MEV. We prefer MEV to be isolated to the individual execution layers where the MEV is generated

• Can’t guarantee - Rollups won’t necessarily care about the best interest of the data layer! Not incentive aligned, necessarily. They may just do something bad for the data layer

When it comes to building an execution layer on top of a data layer, you need a mechanism to produce new blocks. You need a leader selection algorithm, but you would also like to leverage the data layer for security. If you don’t leverage it for security, then you are kind of losing half of what you get out of the modular blockchain. You can get the ordering and availability. If you only use it for availability, you have these synchronization issues between one blockchain's consensus and another’s consensus. You would like ultimately all consensus to be done on the base data layer. Use some mechanims for merged consensus rather than some completely independent consensus protocols, then you have synchronization issues.

Reviewing leader selection algorithms.

First Come First Serve

A bunch of people post blobs to a namespace saying this blob is for this rollup. The first person who post the Celestia blob to the namespace is decided to be the leader ex post facto.

• Intuition: leader is ex post facto selected as first/earlier blob posted to data layer
  • i.e. leader is decided by an auction on the base layer
  • Auctions can be manipulated (Trust the auctioneer)
• Issues- introduces a PGA to be the leader, bleeding the auction to capture MEV to the data layer
  • Waste: all other transactions are a waste of block spasce

Tendermint-style Leader Rotation

You take just the leader selection protocol, not the whole quorum and voting and rounds and p2p. Then, based only on the state within the rollup.

• Intuition: randomly select leader using only state on the rollup. Fork choice rule can be trivial since rollup us fork-free.
  • the fork choice rule is trivial because Tendermint is fork free
• Issues - Liveness is hard. As an L1, Tendermint on L1 can increment rounds very quuickly. As a rollup, might have to wait for data layer blocks in order to say this leader for this slot didn’t post this slot therefore we will increment the round and rotate the leader permissionlessly.

Highest-priority First

• Proposal requires a protocol change to Celestia or the DA layer
• Intuition: Celestia block producers can malleate a “priority” field that orders blobs
 - this serves to order the blobs
• Issues - Isomorphic to first come first serve, except the auction which is done off chain instead of on chain; PGA is done out of band opaquely.

Based Rollups: Based or Cringe?

• Intuition: Minimal Viable Merged Consensus (Adler 2019) + MEV-Boost or some PBS thing. MEV-Boost introduces an additional trust assumption
• Issues - Does not mitigate use of auction to select leader, so MEV still bleeds down.

Sovereign MEV - Protocol Owned Builder

What is Sovereign MEV? Sovereign MEV is the vertical integration of a protocol into its own block building process.

Imagine if consensus and the entire block building process could be aware of MEV and the application which creates it?

Sovereign MEV exists when your application can be very opinionated about how its blocks are built. This allows you to build truly better applications. Generally, this area of research is underexplored. However, one of the best reasons to build your own blockchain is that it allows you to control your own MEV which is not possible on a generalized platform where applications share state space.

Flow of Discussion

1. Motivation - opinionated MEV Recapture
2. Setting - Tendermint blockchains / cosmos sdk
3. Tool chain - ABCI ++
4. Solution - Protocol Owned Builder (x/builder) -
   • V1 and beyond
   • Into cross-chain?

Motivation - Sovereign MEV

1. Direct MEV to arbitrary stakeholders
   • Not the proposer
   • Instead: LPs, community pool, token burn
2. No centralized, off-chain block-builders (including Skip!)
   • Batteries-included
3. Revenue-maximizing (except for harmful MEV)
   • No sandwiches for sale
4. Censorship-resistant
   • Proposer cannot enter into off-chain agreements to censor certain bids + include others
5. MEV-stealing proof

App-chains have given us this list of extreme demands for how they want MEV markets to operate on their domain. First, they want to be able to control who profits off of MEV. In many existing MEV systems, like on Solana or Ethereum, the ultimate beneficiary is the validator set or the proposer of a block. The chains we work with, they want MEV to go elsewhere; they want it to go to LPs, community pool, they want to burn it, they want to give it to SC devs. They have these really strong stories these reasons they are unique that they have built every inch of their stack around, and they want MEV to reflect those reasons.

The second thing they want is no centralized off-chain block builders. They don’t want any one party to be able to build an entire block by itself, and that includes Skip. Our first product was basically a centralized block builder that we shipped as a service to 5-10 different Cosmos chains, which required them to trust us and run a bunch of additional infrastructure.

App-chains and rollups wants something that allows them to start recapturing MEV right away. Batteries included. They don’t want someone to have to spin up these complex off-chain block building systems if there are a few searchers on their chain who are sophisticated enough and familiar with their protocol who can extract MEV. The app-chains just want the system to work from the start. The second thing is they want to make a lot of money. They don’t want to make money in bad ways, there are broad notions of what constitutes toxic MEV around front-running or sandwiching, generally requiring users to pay their worst price possible.

App-chains do not want this, they want to provide a good experience to their retail users who draw other kinds of users to their platforms. They also want these things to be censorship resistant. They don't want the proposer to be able to enter into off-chain agreements with other parties who may pay them directly, and undermine w/e kind of revenue split they desire as a protocol. Furthermore, they don’t want anyone to be able to censor bids in an auction.

Lastly, they want this protocol to be resistant to MEV stealing. In addition to maximizing revenue, they don't want validators to be able to copy searchers strategies. Many requirements to fulfill and hard to get all of these properties, but we work on systems that work up the stack and try to get these app-chains what they want as soon as possible.

Setting - Cosmos Ecosystem

1. Consensus - Tendermint (Comet BFT)
2. Framework/VM - Cosmos sdk (Blockchain in a box)
3. Sovereign App chains - Chains optimized to do one thing well

• DEX chains (Osmosis)
• DeFi Hubs (Injective)
• NFT Marketplaces (Stargaze)

Generalize to any chain with permissioned, round-robin proposer set and fast finality.

The setting is the cosmos ecosystem. It is this ecosystem of many different blockchains which all have the same underlying technologies. They use Tendermint for consensus, they use the Cosmos SDK to build these applications and function as the VM with various customizations. Each of these chains is built to do one thing and do it well. They are optimized top to bottom to be purpose built. So that means sometimes they are DEX chains or DeFi chains etc. Any application you can think of, people are trying to build blockchains to emulate them. We want to work on technologies and ideas that we think can generalize nicely to any kind of chain which has a permissioned round-robin proposer set and fast finality. Tendermint is the best consensus algorithm for this today.

Secret weapon - ABCI ++ (2.0)

Note: ABCI 2.0 is the correct terminology but I prefer plus-plus, as in Mev-Boost ++

ABCI 2.0, succeeding ABCI++, introduces three novel methods - ExtendVote, VerifyVoteExtension, and FinalizeBlock. These allow greater control, insight, and customization of consensus process, making new use-cases achievable.

ABCI is the application blockchain interface. ABCI+ (1.0) is the interface between Tendermint and the cosmos sdk and the application. This is critical to understanding why app-chains can give developers better tools for integrating consensus into the block building process. Tendermint is responsible for consensus and the application manages state. Tendermint is really dumb and doesn’t know what the application is, it doesn’t know what the application cares about or what the application wants. It just comes to consensus on a set of transactions and once we have come to consensus, Tendermint gives the application those transactions one at a time. There is not much opportunity for the application to express any kind of block builder preference.

Thanks to the work of Informal and leadership of the Osmosis team, there is a new version of this interface coming out which allows much more sophistication. That allows the application to be very opinionated about what blocks are valid and what blocks are not based on the transactions they contain, based on the ordering of those transactions, based on any rule you can come up with in this framework.

Tendermint’s mempool PrepareProposal has a bunch of transactions, and it gives them to the application, and it says is this okay? Can I put these into a candidate block and send them around the network? The application has the opportunity to return different transactions, new transactions, or re-order them and apply any kind of arbitrary rules it wants to and give them back.

In ProcessProposal once the proposal has been gossiped around to different validators, each validator has the opportunity to ask the application, is this okay? Did this validator create this block according to the rules you wanted them to? Does this meet your criteria? If you are a DEX, for example, you can say, does this block actually have global clearing prices for all assets? If not we can reject it as part of consensus, we can tie liveness to the quality of our block building process if we want to.

During the voting phase of consensus, the validator set also has the opportunity to attach additional data (extend vote, verify vote) to their votes on a block. What that means then is that when there is a quorum, and the proposing validator for the next block is making a block, we can guarantee the availability of that data. We can guarantee that when the proposer is making the next block, they access to 2/3 +1 stake weight of data.

V1 - Mempool Auction

• Native “bundle-type” meta transaction
• Native top of block tx

What we try to do here then is just build a general system that can be plugged into any cosmos sdk chain off the bat and in the future any other sdk chains that allows them to capture MEV right away. The first version of this uses PrepareProposal phase, where we make the mempool function like an auction. We add a native bundle type transaction, so searchers can specify a bid they want to pay for top of block and a bundle of transactions they want to include. Then during the block building process the validator finds the highest bundle in their mempool, pulls it out and puts it at the top of their block. In the ProcessProposal phase, we make sure there is only one top of block transaction there.

Benefits

• Decentralized and just works out of the box - no one needs to run any new infrastructure. You have immediate MEV recapture on any chain which runs this.

Drawbacks

• Not censorship-resistant - the proposer can freely just censor bids if they want to we have no guarantees about them not doing that, we don’t know what is in their mempool
• Cannot direct revenue away from proposer - they can just enter into an out-of-band agreement with someone.
• Not MEV-stealing proof

POB 1.0 is out and live and will be integrated with Bera Chain and Osmosis. This will be a replacement for skip centralized block building in these ecosystems. The nice thing about this you might be thinking in Ethereum all these validators will go back to stealing MEV. Cosmos validators have a nice social contract with the chains they operate on, and we have done a lot of analysis including over the period of time when Terra was very active looking for evidence during those extremely lucrative times was there any misbehavior? We have found very little. We are not super worried about this being an intermediate solution. It's something that gets these chains started, and we want to make it better.

V2 - Consensus-Enforced Auction

We are moving this auction we run into consensus to give it censorship resistant properties using vote extensions. When I’m voting on a block now as a validator, I’m going to look in my mempool and see these auction transactions, and I’m going to pick the one that has the max bid and include this in my vote extension.

What that means is that when the proposing validator is building their block, now in the proposal we can include each of those transactions and bundles and bids that came from the quorum of validators that we know had to give this validator these votes because we have gotten finalization on the previous block.

Then in ProcessProposal we can guarantee hey the validator actually ran the auction correctly. We can’t guarantee with 100% of input bids, but we can guarantee with respect to 2/3 + 1 we know this auction is revenue maximizing. We can’t guarantee censorship resistance of a higher portion of these without affecting the liveness of the chains, but that’s something the chains can configure.

Benefits

• Decentralized and just works out of the box
• Can direct revenue anywhere
• Censorship-resistant

CR: If a Validator tries to enter into some off-chain agreement that says they are willing to take a lower bid under the table that pays them more directly, now we can catch that in consensus and prevent that block from ending up on the chain or punish the validator after the fact. Right now, it ties directly into liveness. So if the validator tries to do this we skip the validator and move onto the next proposer, it is an invalid proposal.

Drawbacks

• Not MEV-stealing proof - The validator could alternatively look at w/e bundle pays them the most and just copy those transactions. They have to bid higher, so the chain gets higher revenue, but the searchers are having a bad experience and this could potentially become a centralizing force.
• Higher Latency - It's also higher latency because the bids need to be available during the voting phase of the previous block as a searcher you are committing to your bid for longer periods of time, which if you are trying to do CEX-DEX arbitrage is not enjoyable.

V3 - Encrypted Bundles Auction

What do we do? For now, we ignore the latency problem. We just encrypt the bids, and we have the chain run the DKG as a part of consensus as well. When we are doing vote extensions we have visible bids, so each validator can still pick the highest one out of their mempool, but now they don’t know what the transaction is. They don’t know what the searcher’s bundle is, so they can’t do anything except pick the highest bundle and leave it there.

During the voting phase on the block, each validator also contributes their decryption key shard for the key at that height. Once we have 2/3 + 1 we can decrypt the top transaction in the proposal and run the proposal as normal.

Benefits

• Decentralized and just works out of the box
• Can direct revenue anywhere
• Censorship-resistant
• Mev-stealing proof

Drawbacks

• Higher latency
• Run DKG in consensus (pain)
• High bandwidth
• Not revenue maximizing - because we couldn’t encrypt the actual bids, so we have a first price auction and people aren’t bidding honestly.

The mempool auction is done, the consensus auction will be done in about a month and a half. The encrypted auction we are going to be working with the Osmosis team to implement Ferveo which will probably be available for Cosmos chains in 4–6 months. This is the reality for app-chain MEV which feels pretty good. It's not a full block building solution yet, but it is a really strong starting point, and I hope it demonstrates that there are a lot of interesting things you can do with MEV when you have better control over your application from the consensus perspective.

V4 - Sidechain for Commitments

Beyond this mostly in a design phase is we are looking to attach a very fast and very dumb side chain to each of these chains that the validator set runs which can run a very simple commit-reveal scheme for this auction. It can finalize at more than 2x the speed of any of these chains. It doesn’t even have to run the DKG. We can move the reveal step out of consensus and just move it onto the searchers being responsible for revealing their own bids. This is nice because we can be flexible with how we integrate it. It can be a commitment a proposer enters themselves or a commitment the validator set as a whole commits to and that we require as part of consensus, so there can be a liveness dependency or not. It's something the chain can then add additional commitments to that they might want their validator set to agree to. It's like every chain having its own little very fast beacon chain. What's nice about Tendermint and the cosmos sdk is that we can run this very easily as a side-car process.

This is where we are going. We can actually run a second price auction and get honest bidding. We have a lot of nice properties for MEV. The drawbacks are though, this requires deep integration into consensus, and you only have a single chains perspective now if each chain is running a commitment chain for MEV.

Benefits

• Decentralized and just works out of the box
• Can direct revenue anywhere
• Censorhsip-resistant
• MEV-stealing proof
• Honest bidding

Drawbacks

• Consensus integration
• Single-chain POV

Future Work

• Enable proposer level commitment to side chain (opt in on a per-validator basis)
• Link side chains together for multichain commitments
• Grow from top of block bids + transactions to supporting blocks where required

Where we’d like to go is to see this type of commitment surface area for chains to enter into as part of consensus per-validator basis. To potentially link together these different side chains where you can have a single chain where agents can make credible commitments to each other using commit-reveal schemes.

The other thing we’d like to do, though it's not necessary for app-chains and rollups today, is to grow from this being a system that is mostly facilitating top of block bids and single bundles per block to something that can support whole blocks when it's required. Right now, the vast majority of MEV on app-chains is just captured with a single bundle. There is very little that slips through. You can imagine in the future when these systems get more complex and there is more revenue moving through them, that will change. I hope this gives some alternative perspective to the flexibility you have around MEV when you can take more control of your stack.

When you have control of consensus, you can do things like order transactions for our DEX firstly, so we minimize MEV and then do anything else. There is a big design space here that you can access around just building MEV-aware blockchains, as opposed to trying to attach MEV awareness to protocols after the fact.

Information Theoretic Taxonomy

Research Question: Which kinds of MEV are possible, and which kinds can be mitigated, in principle, from an information-theoretic perspective? Developing a general taxonomy. If you want to develop a taxonomy that is general, you have to reason about it on the basis of information theory. What are the agents when are they making decisions, what are the different events where different agents have different information. If you derive a kind of structure in that framework, you can be pretty confident that it's not dependent on some specific properties of some particular system.

A very simple information theoretic taxonomy of MEV

• State of the blockchain advances in local time
• State of the world advances in real time
• Two classes of actors:
  • Transaction authors (users)
  • Transaction orderers/groupers (proposers, builders, sequencers, etc.)

We have two information systems. One of those systems is the ledger (blockchain) that advances in this quantized time stamp, could be a DAG as well. Then we have the World, which is everything else. The world includes other things like things happening in nature which may inform hedge fund trading decisions. Those are also part of the world in a general sense.

The world advances in “real” time. Then broadly we have two classes of actors. Transaction authors who are crafting a tx which may do something they care about related to the blockchain state. They may take that state as input or prior state as input, or may depend on the state at the time the tx is executed.

Then there are transaction orderers or groupers, these might be split into different roles. However, someone still has to make ordering decisions, or you do everything in batches and there is no order in the batches but still order across the blocks. Variously these orderers or groupers are called proposers, now in a system like Tendermint the block proposer chooses the ordering of transactions. In the Flashbots style architecture these roles are more split like in the PBS architecture. Different roles may or may not be performed by a real world entity.

Two events in question - Event of transaction authorship

• Author has access to blockchain state at time b_t
• Author has access to world state at time w_t

There is a difference here in events. The first event is transaction authorship, where the author of the transaction has access to the states at which they can read at that time. So they have access to the blockchain state, this particular block they can currently see, maybe they are using a light client, so they can see which blocks have been finalized. They also have access to the world state at w/e the current time in the world is.

Second Event - Event of tx ordering and block creation

• Orderer has access to more information about blockchain state
• Perhaps updated blockchain state b_t+k
• Set of possible transactions to include
• Orderer has access to more information about world state
• i.e. the cross-domain MEV problem
• MEV is the information asymmetry between these two actors/events

The second event is this event of tx ordering and block creation, which may be split into different sub events. Whoever is doing the ordering if there is ordering, even just choosing which block to put a tx in a batch system, has access to more information about blockchain state. Maybe some blocks have passed since the tx has been authored, that is some information they have. But they definitely have a set of possible transactions to include and possible orders for those transactions.

The orderer also has access to more information about the world state because time has passed. This is kind of the cross-domain MEV problem writ-large. Then you can think of MEV as the information asymmetry between those choices. Between the user who is choosing to author the transaction the first time and the decision maker or multiple possible decision makers who are deciding to order transactions and put them into blocks at the second time.

If you try to diagram this in extremely simple fashion, where arrows are information flow. SO someone in blue is choosing to author a tx. They have information about the world at time \(t = i\), and they have information about block 1 on the ledger. That transaction along with others and more information about the state of the world is available to the blob of either singular or many entities who are sequencing transactions and creating blocks. Some blocks may or may not have passed on the ledger in this particular diagram. You could also tie transactions to specific blocks, and maybe there is just more transactions and more information about the world.

Information Asymmetry

• Can we reduce the information asymmetry about the blockchain state?
• Yes, with cryptography (ordering decisions made without information about tx contents)
• Can we reduce the information asymmetry about the world state?
• No. Only by reducing latency from event (1) to event (2)
• We can also craft algorithms to combine transactions within a quantized time period (batching)

From this taxonomy we can characterize what are the different aspects of MEV that we could aim to reduce and how could we go about doing it. One question that might arise is can we reduce the information asymmetry about the blockchain state? There are ways we could reduce this by requiring ordering decisions to be made without information about tx contents. Our approach falls into this category, with Threshold decryption.

Can we reduce the information asymmetry about the world state? Much harder to answer. The answer is no because time has passed. If there is more information about the world accessible to the person who is making the ordering decision simply because time has past, we can’t encrypt the world unless we pull the world into our encryption scheme. We can’t do anything else, except we can try to reduce the latency. The real latency of this does matter in terms of number of seconds if the kind of MEV we are worried about is changes in the world state.

Using cryptography to reduce asymmetry (a)

• Proof-of-stake with BFT finality
• Threshold key (e.g. same shares as PoS validator set)
• Order of operations
• All transactions are encrypted to the threshold key
• Proposer commits to ordering
• Block finalized
• Transactions are threshold decrypted then executed

How do we use cryptography to reduce this first asymmetry (a)?

There is one component of a threshold decryption setup and another component of the settlement setup and the settlement component is pretty orthogonal, what we just care here about is the ordering component. But we happen to have this vertically integrated system. The system we've built is a DKG and threshold decryption system setup to work with Tendermint. Tendermint has BFT consensus, it is usually used in combination with a PoS system with regular finality 2/3 thresholds. We generate in our system (Ferveo) a threshold key which has the same share distribution as PoS which allows us to do this guaranteed decryption, which is very important. If you use TE and encrypt all or some of your transactions but don’t necessarily have the ability to decrypt them, then someone can withhold data. If somehow there is a misalignment between how you finalize the order and how you decrypt the transactions where it is possible to finalize an order but then not decrypt some of the transactions, you don’t want that. For that reason, we integrate these systems very tightly.

In the Tendermint architecture votes are broadcast around, and we include in those votes the decryption shares such that when you have 2/3 voted which is a commitment to a block you also have 2/3 decryption shares which is exactly what you need to decrypt the transactions. Either you atomically finalize a block and can decrypt the transactions or not. This is like poor man’s witness encryption because we don’t have Witness Encryption yet, but we can fake something similar to the model. Except that, of course, 2/3 of the validators could collude and decrypt the information out of band.

A basic flow order to explain from a user's perspective. When you author a tx in this system, you write w/e your tx is and encrypt to the threshold key. The proposer only sees the encrypted tx they have to commit to an ordering of encrypted txs. That block is finalized with that order finalized. Then txs are threshold decrypted and executed. This is not a scheme for transaction privacy. You could separately make parts of transactions private in another way, and you could re-encrypt them in this scheme. This scheme does not provide any LT privacy, only temporary privacy.

• Change in information asymmetry
• Proposer knows no more about blockchain state than tx author (except gas limits)

This helps with the first information asymmetry and now the proposer isn’t able to search this computational space of which transactions can be combined in which ways and make the state insert their own transactions, they don't know anything more about it than the tx author, except gas limits.

The problem: block computation limits

• Transaction gas limits leak information
• Can choose granularity, tradeoff between packing efficiency/info asymmetry
• ZKPs do not help directly
• Only way to avoid: all transactions have identical (encrypted) sizes and execution costs
• (still much better than status quo)

There is one slight problem here. We have limits on what we can pack into blocks. Those limits may be based on different resources. They can be based simply on gas, they can be multidimensional (md1559), either way as long as you have limits on what you can pack into a block then you need to give the person who is putting things in a block information about what those limits are otherwise they will not be able to ensure the block has less than w/e the limit is.

These limits leak information about the contents of transactions. If transactions are doing arbitrary programmable execution then if you identify a specific AMM transaction always costs 120,362 gas even if that transaction is TE, you have to put the limits in plain text. That gas amount will pretty clearly identify to someone what the transaction is doing. It's more statistical information to coordinate, and there is some potential MEV there. However, you can give up some accuracy in block packing to get better privacy and less MEV in a sense by quantizing gas.

In Ethereum or most system right now gas is moderately quantized in the sense we have 120,000 gas 120,001 gas. If you use an additional EVM opcode in a transaction, it will change the gas costs. But if we make gas less granular by rounding everything up to the nearest multiple of some constant we choose, we can round everything up to the nearest 100th then we are revealing less information about the contents of transactions and there is less opportunity for MEV.

ZKPs don't directly help with this problem. If you are doing private transactions where you are pinning to a previous state, then you are not leaking information in this way. But if you just use ZKPs to prove something about the gas consumption, you still have to reveal what the gas consumption is.

How do you avoid this? You give up the generality here. You have to make all transactions have identical encrypted sizes and execution costs. Even if you are just doing DA sequencing, and you're not executing transactions on chain if you are ordering them on chain, and they have different sizes, and you use this TD scheme it still reveals something when the orderer is picking which ones to include. Still, even with gas limits leaking some information, this seems like it's probably better than the status quo in terms of MEV.

What do we do about cross-domain MEV?

• Cross-domain is like information in the world (prior diagram)
• Quantize time (artificial latency) by shared clock
• Synchronize encryption-ordering-decrypttion
• What doesn’t this do: cross-domain messages
• Pre-encrypt if you know ahead of time
• Chain encrypt is you have state dependence (hard)

Cross domain MEV we are talking about different domains which are different ledgers. If we don’t coordinate anything between those domains, then it's just like the other domains are part of the world. If a lot of relevant information is happening in other domains, that would cause there to be MEV opportunities like price changes on other exchanges on other ledgers that will create a lot of MEV here based on the real-time which passes that can be exploited.

But if we coordinate between the domains, we have more opportunities. In particular, if we are using this kind of TD scheme we can coordinate on not necessarily what exactly who is doing the encryption or decryption, but we can coordinate when we do it. If we have this cross domain system of three ledgers. Let's say we have transactions being created, then we have some kind of shared deadline and some type of interval between a deadline and the shared decryption. So all the ledgers have to agree. One way of agreeing is using real world time-stamps and hope that those are measured correctly. You could send messages b/w the ledgers, but that is more complicated and introduces liveness assumptions. Maybe in practice a reasonable way to coordinate is just by using timestamps. Then, if you require that in order to be included, all the transactions must be created by this particular deadline. They are encrypted, all the ledgers commit to ordering them in a particular fashion, then after some slight interval they are all decrypted and executed. Then you get similar properties, at least in the sense of transactions on one ledger not immediately creating MEV opportunities on another ledger.

Conclusory Notes

• For the basic approach, we don’t need to agree on the specific encryption scheme or keyset or DA layer or execution layer- we just need to agree on the clock!
• Cross-domain message passing MEV is hard, but this is a concurrency problem, not a security problem (unless your bridge breaks)
• Rollups will have some architectural challenges

The nice thing about this approach is we don’t need to agree on the specific encryption scheme, or key set or DA layer or EL layer, we just need to agree on the fact that we are doing threshold decryption, and we need to agree on the clock.

What this does not solve is cross-domain message passing MEV; i.e. cross-chain DEXs might not work. Which is that if you are making state changes on one chain and those cause messages to be issued to another chain and those messages reveal information then you can threshold encrypt them all you want as soon as you decrypt the messages which will be sent to another chain that creates the MEV opportunity and there will be some competition to fill it in the next round.

One interesting corollary that at least I've come to is that this problem has nothing to do with security, unless your bridges fail. That's not really an MEV problem unless MEV is making it more profitable to bribe people who are running your bridges. But mostly this is a concurrency problem. And if you have a single chain with different rollups on a DA layer you have exactly the same problem with cross rollup messaging, and you will face the same design constraints.

Conclusory notes part II

• Nothing to be done about world-MEV, but physical change is slow
• In the limit case (no CEX), this is a non-problem
• In the non-compliant cross-domain case, real-world latency matters

It doesn’t seem like there is anything to be done about world-MEV. Luckily physical change is slow, if you are looking at processes occurring in nature and something from one second to the next changes in ways that radically changes the price of the asset, that may be concerning or create MEV opportunities, but it's not clear what those changes would be.

Another corollary is that real world latency matters, like the actual latency from when you submit the transaction to when the decision about ordering is made really matters. If there is more latency, there is more MEV.

Game Theory 3EV

{PlaceHolder for Picture}

There exist some common pitfalls on the definition of the word MEV in the community. We give up on the clarity of the notion and over-formalize it such that we lose some memes. It is no longer a meme term and we are getting lost in the detail of the real value of defining MEV. Enter a clear definition of MEV that points to the solution recipe set of how we should solve MEV. What is MEV? MEV is Al Kapone, Evil Deity and Louis XVI.

Mafia Extractable Value

Mafia Extractable value arises when one agent or a coalition of agents gains an asymmetric knowledge of another agents private information. The condition of asymmetric sophistication exists amongst agents.

• Examples include sandwhiching and generalized front-running. In traditional finance we see that people trading on the limit order books imbalance which is essentially a form of one agent gaining knowledge of another agent’s utility or intent. When you see more bid than ask on the book you take the best ask and you make the best bid.

Moloch Extractable Value

Moloch extractable value is the value that is surrendered to the Moloch ie. incoordination within your allocation mechanism for people’s preferences.

• One Example of this include the negative externalities caused by inexpressive mechanisms. Suppose you have a random ordering then people spam the network and that is the only way they can express their preferences in this very one-dimensional way, so you have a shrunk transaction quality trilema.
• In the traditional high frequency trading arms race example the cost that market makers spends on arms race to gain latency advantages was channeled as charging higher spreads to users. So the externality is transferred from sophisticated agents to unsophisticated agents.

Monarch Extractable Value

Louis XVI the Monarch 

Monarch extractable value arises from the fact that the coordinator, for example the sequencer or the validator has ultimate power over deciding what the ordering or allocation or specification on state is. By specification of state I specifically mean which property does the next state specify.

• Some examples of this include validators on Ethereum accrue value because they have the power of determining what content is in the block. Many other examples include tradefi such as co-location fees and cross-domain market makers for swaps.

Mafia, Moloch, Monarch - Definitions

We can see that MEV arises from three distinct properties, the Mafia, the Moloch and the Monarch. Suppose that \(M\) is the Monarch in our universe/game \(E\), and \(W\) is the social welfare function.

• Moloch EV = welfare that is achievable by the best possible mechanism for our game to allocate specification on state minus the welfare of the current Monarch.

  • Moloch EV =$ \(W(M*)-W(M)\), where \(M*\) is the best possible mechanism for \(E\) to allocate specification on state

• Monarch EV = the welfare of the current Monarch minus the welfare that already existed in the orginal game E without our current Monarch as the coordinator. This is tied closely to the idea of externalities.

  • \(MonarchEV =\) \(W(M)-W(-M)\), where \(-M\) is the game \(E\) without \(M\) as coordinator

• Monarch EV + Molach EV = the welfare of the best possible mechanism in our game minus the welfare of the original game. It equals the constant. Molach EV + Monarch EV is innate to the game E and does not depend on our choice of the mechanism \(M\).

  • \(Monarch EV + Moloch EV =\) \(W(M*) - W(-M)\), is innate to the game \(E\) and does not depend on \(M\), so it is a constant (fixing \(E\))

• MafiaEV is a bit harder to define. It depends on specific sophistication details or the power of agents that is existent in \(M\). How much ex post knowledge or last look can one agent have over other agents or their coalitions.

The three values have distinct sources, and those sources of value are non-overlapping. Thus we call them our new definition collectively 3EV (Mafia, Monarch, Molach) Extractable Value, sum type, perfection.

The Recipe - choose your mechanism wisely

The above definitions imply a solution recipe.

• Mafia EV + Moloch EV + Monarch EV = 100% MEV.
• Monarch EV + Moloch EV = a constant depending only on \(E\) the original game, but the percentage of Moloch vs Monarch depends on \(M\), our choice of the mechanism.
• Mafia EV = a constant depending on our choice of \(M\).

Since the sources are distinct, we can adjust the percentage of the three variants by transforming one form of MEV into another by designing a good mechanism \(M\). Ideally, we should have 0% Mafia EV, 0% Moloch EV, and 100% Monarch EV where the Monarch’s profits are distributed.

What this specifically means and why this is true is because Mafia EV relies on the existence of ex post knowledge and there is an asymmetry in sophistication amongst agents. Specifically, once you have this the sophistication tax on the other agents and as such hurts the long-term prosperity of the domain.

• We want 0% Moloch EV because any welfare that is attributed to the Moloch is forever lost and non-recoverable, nor is it redistributable.
• We want 100% Monarch with redistribution because if there is no redistribution to the Monarch then the 100% Monarch EV will erode the incentive for people to use your mechanism because you’re essentially reintroducing the value they would have paid to the Moloch by paying to the Monarch instead.

Users would be indifferent between paying to the Moloch in the original game and paying to the Monarch in the Meta game. This violates the individual rationality guarantees.

Caveats & Why we want Monarch EV

The welfare of the game without the mechanism depends on \(E\). \(W(-M)\) depends on the game \(E\).We assume that the mechanism M represents a domain or builder or some coalition of agents. Then we give an inter-domain coalition factor \(k\), where \(k = 1\) if \(M\) is monopolistic across all domains (including time as a domain, so \(k\) is discounted in the n-dimensional preference curve), and \(k = 0\) if \(M\) is powerless.

What this implies is that by forming a larger coalition means higher \(k\), which enables more credible extortion, with Monarch EV for your coalition of agents (\(M = k * Monarch EV\) if \(M\) and \(-M\)) forms a grand coalition.

This implies users can be also be the Monarch if they have a large enough \(k\), similar for validators, searchers, builders, etc. Essentially, the inter-domain coalition factor represents your collective bargaining power, which determines how M is setup within \(E\), who we enthrone as the king. There are some caveats to how much coalitions can you have? You can imagine this formalized as a cooperative game where the core of the game might not exist if we have too many inter-temporal (inter-domain) coalitions.

This reminds us of the original notion i.e. nonmonotonicity of coordination and incompleteness theorem of MEV. The game \(E\) cannot continue if there is not enough competition. You can increase the coordination, but it does not always increase the efficiency of the allocation in the reality. Even if you try to eliminate the inefficiencies caused by your extra coordination by using another credible commitment or coordination device in the meta game, then you're just transferring the Moloch EV in the original game to the Monarch in the wrapped game. This provides grounds for us to refute any previous ideas by Virgil Griffith and his Ethereum as game changing technology argument.

The specific values of \(k\) depends on how we setup the game. We can throne or dethrone different monarchs, ultimately, we want to choose M* that is most incentive aligned with long-term prosperity and is most capable of coordination. There is a trade-off.

Why do we want a Monarch? The reason for this Monarch abstraction is that the outcome (contrary to traditional mechanisms) is not common knowledge and depends on agents’ private information which other agents don’t have prior to MEV-time (block-building time). So it’s hard to analyze equilibrium (especially when there exists asymmetric sophistication amongst agents), thus we reduce guarantees to have bounds to incentivize compatibility and individual rationality.

Case Studies - FBA style FCFS

Definition of FCFS as in Themis - (fairness granularity) For granularity g, we consider that timestamps are bucketed into slots of interval g time each (e.g.,[0,g), [g, 2g) and so on). Events within a time bucket are asumed to happen at the same time.

Instead of reporting a strict ordering (by received-order time) of transactions, each individual node reports a partial ordering to the leader of the ordering consensus protocol. After aggregating each individual nodes’ preferences, the Monarch (leader) gets a weak ordering (by FCFS) with unordered batches in it (caused by condorcet paradoxes and the initial partial ordering). Now the Monarch tries to resolve the order of the unordered batch using auctions.

In reality over 65% of the Uniswap volume comes from arbitrage maybe stat, and among the other 35% its a handful of market makers. MEV activity constitutes a huge amount of Ethereum activity.

The burst period on Ethereum arises from public information reveal and takes around 1.2s, and 75% of the conflict of preferences in Ethereum ~ 4% of the time.

Vanilla FCFS compared with FBA-FCFS, will be bearing extra negative externalities (e.g., centralization, higher fees, worse UX, etc,.) from 12x more conflict of preferences. Bursts of conflict of preferences are significant, and just adding some partial ordering in FCFS mitigates most.
 Adding some partial ordering covering that 4% window you can mitigate most of the negative externalities on the domain. You can take value back from Molach.

If we compared 3EV of vanilla-FCFS with FBA-FCFS:

• Mafia EV - same 0% (assuming programmable privacy)
• Molach EV - the vanilla version has much more Moloch because no one can express their preferences in the short burst period, from incoordination and a naive ultra-simplified social choice function that does not coordinate burst period MEV (permissionless, price discovery, atomic).
  • Transforming the Mafia slowly into the Molach where the value is transfered to the users who have the same bad payoff.
• Monarch EV - much less by definition, also it throned the wrong king (AWS, Google Cloud), the Monarch is not incentive aligned and is more centralzing. In latency games you pay more to AWS or google cloud.

Transformation of 3EV

Concrete examples - does 3EV actually capture most of the existing MEV notions that we have?

• Molach to Monarch - For transfering we see that one form of this is the spread charged by market maker bridges from
• Monarch to Mafia - we see this in POW Ethereum; if the Miners were to go rogue and steal bundles. If They chose to gain an advantage to gain an asymetric information.
• Mafia to Molach - You go from a public mempool model to a vanilla FCFs. You eliminated the public mempool so you don’t have the information assymetry but instead you have uncoordination. You have a bad allocation of preferences which increases MolachEV.
• Molach to Mafia - If a malicious coordinator were to pocket all of the surplus welfare that Ethereum generates from optimizing ordering or surplus existing from coordination.
• Mafia to Monarch - Programmable privacy. In this case you can do bundle merging, block bbuilding or preference aggregation

DAO governance (non-monotonic decentralization) is a form of transforming the Monarch to Moloch. The DAO exists for coordination, but allowing a DAO token to be distirbuted under poor tokenomics, you are creating a ponzi which creates more Moloch. You could have transformed to a Monarch stage but through more decentralziqtion you have re-created the Moloch in the Meta game of the token game.

This reminds us of the previous example of non-monotonic relation between decentralization and coordination and efficiency in the mechanism.

Implications - Why is 3EV useful?

How to achieve 0%, 0%, and a distributed 100%

Mafia EV: we can solve using programmable privacy, which allows full expressivity and agents to control how their information is used along the path of determination of outcome by the Monarch, M. This Also relates to traditional mechanism design idea, the definition of how expressive a mechanism is. Concretely, this means you can devise a mechanism for discovering the unsophisticated user’s preferences and helping them communicate this preference to the coordinator or the mechanism.

Moloch EV: we can solve by increasing efficiency, eliminates the Price of Anarchy via refinement of society, i.e. specialization of labor. Slack vs., Eula. Contrary to the idea of Moloch, you have the idea of slack. Slack arises from coordination, where you allow someone to have enough moat where they can grind on the higher payoffs. This is only allowed if you have a highly coordinated specialization of labor in your society.

Monarch EV: value division should be divided in such a way such that maximizes welfare/futue returns. You probably shouldn’t focus on giving tiny kickbacks to existing 1x users, focus on onboarding the invisible 99x users, as Monarch EV grows superlinearly compared with the number of order flow that exists in your domain (dMEVdt). For example investments in to wallets, or retroPGF. This was the original idea of fair ordering as well. There are 99% of users who will come to your domain if your order transactions fairly.

Evolution

3EV was defined by a source of value. However, the Sink of those values is different, e.g., Mafia EV sinks to Monarch.

Sink of value is different, e.g., Mafia EV sinks to Monarch. For example, if there is a sandwich and two very competent atomic searchers then the value sinks to the Monarch, the validators.

Sink of value impacts the source of value

• By controlling sink allows controlling the source of value, via the magic of credible commitments
• Builder as a rollup (zk/op social sequencing)
• Expressivity of bidding language (incompleteness theorem), semantics lattice
• Decentralization of building (parameterized Themis)
• SGX, tokens, revelation principles, etc,.

But all of this conditions on a low enough inter-domain coalition factor, i.e., high enough completion (contestable). Once you have too much coalition or too much coordination then it becomes very hard to have a good mechanism.

Therefore, having more competition in the game by incentivizing more competition is right curve behavior. Optimizing the ordering by learning more about the preference micro structures and then grinding on the design of the mechanism is mid-curve. Contestability is an important tool. It can only be realized if we design the initial market in such a way that its not centralizing. In reality we should devise a mechanism where exclusive order flow wouldn’t exist.

Presuppositions and Utterances

The utterance of the sentence; “X is MEV”

Has a presupposition test; “There exists a game E and an allocation mechanism/ordering protocol M, and that within (M, E) using the 3EV definitions we can indeed see X is constituted by a type (or multiple types) of 3EV.”

The utterance of “X is MEV” has a presupposition of the existence condition of E and M and X being indeed in the set 3EV (E, M). Thus, if there does not exist such E and M (if there is absence of a Monarch), then the utterance is false. X is not MEV.

Example

Imagine Kim and Don playing a prisoner’s dilemma. Suppose there isn’t a coordinator.

Someone utters the sentence;

The value of Kim and Don is extracting absent a Monarch i.e., (1, 1) is not MEV by passing the presupposition test. If we take a Freigian view.

Language Games

Wittgenstein has this notion of a Language game where the context depends on social things.

“X is MEV”

The sentence might be true, as the context of the utterance is social and we might agree on some notion of the game.

If the sentence is provided without contect, then the sentence is nonsense and has no truth value.

Thus ultimately the test of MEV conditions on which philosophical interpretation of language you agree with, if you are Wittgenstein and believes the utterance is within the context where it is socially agreed that the Monarch is existent (which is often the case, as we can say physics is the Monarch), then that value is indeed MEV.

Let’s change the “Language Game”

Are you not tired of “Miner” or “Maximal?” (where the grammar isn’t even correct, we say maximal MEV all the time)

• We should just say MEV, and it conveniently represents a shorthand for sum type of {Mafia, Moloch, Monarch} Extractable value.
• MEV = [Mafia, Moloch, Monarch} Extractable Value
• MEV should not be called Maximal Extractable Value

By changing this language game we have several Benefits:

• This formulation gives you a Distinct value (source)
• Formalize (social process) in the sense that you don’t get lost in the details, it still keeps the meme and the formalization and the proof only serves as a social process to help people understand it
• Settles “bad” MEV Tradeoff (transform) space clear
• This Implies clear solution recipe
  • Research Monarch EV distribution!
  • Research programmable privacy for Mafia EV!
• Presupposition test (context clear)

In an post-MEV world where we solved those three cases of “bad MEV,” the unsophisticated users will receive a compensation equaling the difference between what they are getting now v.s. what they would have got if they were sophisticated users; the coordinator do maximal extraction by eliminating PoA fully and redistribute the profits according to the value every user brings to the coalition; and all users will be free from being preyed on asymmetric information.

Encrypted Mempools

Motivation

Why do we want encrypted mempools?

• Front-running protection
• Censorship resistance

If you can’t see the payload of the transaction and you can’t see the metadata, then you can’t meaningfully front-run a transaction (though you could state engage in optimistic spamming). In order to sandwich you need to know which pair is being traded, the size of the transaction, which pool the transaction is from, etc.

A related aspect is centralization. One of the bad things of MEV is that it is this centralization force. Why is their centralization? There is centralization because some sophisticated agents can have an edge in producing blocks and being part of an MEV supply chain. If we can remove sandwiches as an edge, we can reduce the surface area of sophisticated agents. We reduce the surface area of centralization as a result.

Positive MEV - arbitrage and liquidations, Things that the designers of applications want agents to execute because it leads to outcomes for the decentralized application like prices being arbitraged. Encryption removes the bad stuff and keeps the good stuff and helps with centralization.

The other thing to highlight is Censorship. Some entities in this MEV supply chain may say I won’t include any encrypted transactions, or at least I won’t include them unless you tell me they don’t touch certain addresses. For example, a block builder could specify they will only include an encrypted transaction if there is an accompanying SNARK saying that it's OFAC compliant.

One of the things we want to try and do is make encryption the default in such a way that if you want to have this very naive strategy of saying I will not include a certain type of transactions, then you need to not include all the encrypted transactions. If you do include an encrypted transaction, you don’t know whether it meets your constraints. Therefore, as a censoring building, you have a massive handicap. Then the only thing you can see in the clear and have an edge on is this arbitrage transactions, but now you are losing out on tips for transactions.

Encrypted Mempools

What is the simple framework of an encrypted mempool? You want to encrypt your transaction off-chain before it goes on chain. You want to have some sort of commitment to the inclusion to the ordering of that encrypted transaction before you decrypt. So you have encrypted, commit, decrypt, and execute. A natural question arises, does this add latency to the user experience? Not necessarily, you can do all these three steps in one slot behind the scenes.

One of the important things you need for an encrypted mempool is some sort of encryption scheme that guarantees that the cypher text will eventually be decrypted. Commit-reveal does not work. There are five different families of encryption that have been identified with this property.

• In-flight- Private end-to-end encryption, a centralized entity maintaining this private mempool.
• Enclave - TEEs where you are trusting the integrity of SGX
• Threshold - the most popular approach. Many implementations waiting on ABCI++
• Delay encryption - VDFs. Not yet ready because it requires a VDF ASIC.
• Witness encryption - a powerful primitive which allows you to have arbitrarily complex and flexible decryption predicates. Decrypt if something happens. It can be thought of as a generalization of other decryption mechanisms.

As a user, you can have perfect encryption and leak no information, but you can still be not blind to user outcomes. The encryption system itself can be aware of the transactions it's manipulating. It doesn’t have to randomly include these cypher texts or blindly include them on chain. It can actually look under the cover of the encryption in the way the user doesn’t leak information.

• Homomorphism - you are given cypher texts, and you can compute functions on these cypher texts. It's actually trivial to do homomorphisms in the trusted context. If you have an in-flight encrypted mempool like Flahbots protect, they get to decrypt privately the transactions, and they can run functions on the data.
• For SGX, you have the in-fight encryption between the user and the enclave, but then the enclave will have plain text access to the message. As you become more and more sophisticated with your encryption mechanism, the homomorphisms become more complicated.

The Edge of MEV

The edge of MEV is a metaphor in the sense that its the edge of the current MEV discourse and that there is an interesting graphical representation of the whole question related to switching costs.

Four Quadrants of MEV

• Supply-side price fixing
• Delegation of computation
• Information flow asymmetry
• Cross-domain synchronization

Cross-Domain synchronization

Cross domain stuff is hard because of heterogeneous security and heterogeneous clocks. These are hard problems. See above.

Information Flow asymmetry

Most of what went under the term MEV is in this class

• Users have less information (unsophisticated agents)at the time of intent creation than operators (validators, builders, searchers) have at the time of ordering decision-making
• Order flow auctions, encrypted mempools with batch matching, etc. all try to address this by changing the information flow or adding auction mechanisms
• Most of the current “bad MEV” that we don’t want falls into this class.

Information asymmetry between the user at the time of intent submission and the orderer (~ proposer) at the time of ordering - as the latter is always after the former, the orderer will probably have access to more information, which they could use to reorder, insert their own intents/txs, etc. (this is the majority of current Ethereum MEV, as I understand it).

This can be addressed by quantizing time at a granularity large enough to span the difference between these two times (plus possibly some slack), which can be accomplished by threshold decryption (encrypted mempool), time lock/witness encryption, etc. At the moment the most practical technique here is threshold decryption (we have an implementation of that with Ferveo), but probably we'll eventually want to move to witness encryption as it has better security properties.

Delegation of Computation

• User want to delegate “hard work” (e.g. of optimal trade routing) to a third party
• Meta-transactions, specified builder algorithms, fairness criterion, etc.
• Most of the current “good MEV” falls into this class

Users wanting to outsource computation (and being willing to pay for it). This is similar to the category of "good MEV", meta-transactions, this sort of thing - any case where users want someone else to do some computation for them. Also includes potentially splitting trades between multiple domains (domains here could be multiple DEXs on one chain, multiple DEXs on different chains, speaking broadly).

Here our concern is to make sure that the market for compute is fair - compute is fungible, and users should get the best price - while also trying to avoid accidentally creating proof-of-work-style races which aren't very efficient - but users clearly do want to outsource computation, so this is something we design for explicitly. In our organization of concepts, this also includes provable indexing, ETL, and the like.

Supply side price-fixing

This is very simple and maybe so simple that it's been neglected so far.

• Interdependent transactions (if we want them to touch shared state that can compose) must be ordered in one (logically central) location
• This location has some operator set
• That operator set chooses the price for inclusion

The interdependent location typically has an operator set, the fundamental reason why is bc we dont want to make a liveness assumption of the users, If you want them to be only one class of participant than the users need to be online, but typically people dont like being online all the time, but we generally avoid this.

So we want to delegate liveness which delegates custody, delegating the ability to sign to do something with our assets on our behalf, to some operator set. That operator set fundamentally just by the fact of delegating liveness that operator set chooses what to include, as they choose what to include they set a price. You can try to create norms around what prices they set, but they always have the ability to choose what intent or transaction is included. They will always be able to accept side payments or set prices in some other way.

What is Supply-Side Price fixing?

Price fixing has a long-standing background in colloquial economic discourse (”Price fixing” implies a cartel, this is intentional, operators in consensus are a cartel)

Operators set prices

Its very easy for operators to coordinate, we’ve built fancy BFT consensus mechanisms that literally make it easy for them to coordinate, they know the public keys and the voting powers. (Operators = validators and people who have custody of assets, supply side price fixing only has to do with whoever ultimately controls inclusion in the logically centralized ordering location)

”Price fixing” implies a cartel, this is intentional, operators in consensus are a cartel. True independent of supply/demand asymmetry (independent of all other types of MEV. Operators for a particular ordering location can set a price, they order things in a place, and they accept some type of payment for this);e.g., EIP 1559 is an algorithmic price-setting tool (a way operators coordinate to set a price), but operators still ultimately control.

Why Should You Care though?

Supply-Side

• We should expect operators to coordinate
• Operators set prices for inclusion
• Operators are rational (ish) (they want to maximize profit depending on what they think will happen, repeated games and one shot games).
• Operators have custody

Demand-Side

• There are reasons to expect users need or want to agree on where they order things, where they order particular type of transactions.
• This agreement on one logical ordering location for interdependent transactions is what makes atomic composition possible.
• Even if you have something like Heterogeneous Paxos, you still need a logical single location for ordering.

Rational Extraction

Suppose that users don’t coordinate, and they just send their transaction somewhere. Assume surplus from coordination. In a world where users don’t coordinate, Operators can charge just under the surplus before it becomes individually rational for users to leave (this is a coordination problem). I as a user, if I benefit for using the system, but if the operator charges me $5 to send a tx, even though it doesn’t cost that to run the computers, they know they can charge $5, and I still send tx, that's the individually rational equilibrium, users don’t coordinate.

If operators expect users to leave, they should charge users as much as possible. This changes the game theory into a one shot game, if I am the validator set of the Ethereum blockchain and see everyone is taking their assets to other ordering locations, If I think people will stop sending me txs then the rational action for me is to charge as much as the assets are worth for the users to exit. If I as a coordinated set of operators expect users to leave I should charge them as much as possible because this is the final round of the game. We don’t see this yet but we should expect to.

Another strike against the conceptual unity of “MEV”

• Supply-side price fixing is unrelated to information flow asymmetry
• TEEs, threshold encryption, OFA, etc, do not help (other than maybe make stuff harder for operators to measure).
• Operators can easily vary the fee to test how much they can extract

This category of MEV is unrelated as in you can do all the cryptography you want, you can do nice privacy preserving intent-centric architectures, OFAs, SUAVE, TEEs, it does not help with this problem. The only asterisks is that if users have heterogeneous security preferences such that they are willing to accept multiple ordering locations you can do some coordination amongst users in the counterparty discovery layer, in the intent layer but that only helps with better balancing transactions across a set of different logical ordering locations. This doesn’t help with a bridge withdrawal tax or basic price fixing.

You may think these systems may make it harder for operators to figure out what users are doing. However, operators can still test different fee levels and see what users are willing to pay. If users don’t coordinate, they will individually be willing to pay what using the system is worth to them.

Why don’t we see this right now?

One kind of danger in the applied MEV research discourse is that we want to be careful that we don’t build systems that we only see right now. Some of the problems won’t happen until things are widely adopted.

For example, Ethereum validators are nice, there are side social channels of interdependency. If we look at the real world outside of blockchain ecosystem, who extracts? The typical Silicon Valley business model has not only ended up exploited switching costs, it's often explicitly designed to maximize switching costs. They are analogous to operators in this scenario. We can expect in the long-run, if operators see that people are leaving, they are going to have simple algorithms to recognize those transactions and charge higher fees.

What is the Slow Game?

• Users coordinating to select logical ordering location

The coordination process amongst users to select logical ordering locations. However, it is users agree where they want to send inter-dependent intents and transactions which need to be ordered together.

• Agreeing on where to send interdepent transactions/intents
• Splitting non-interdependent flows b/w operators

(This includes splitting up non-interdependent flows between operators so you avoid high prices due to high demand exceeding supply for one particular location if you didn’t need interdependency.)

• Switching away from extractive operators by “force” (forking)

It also includes users need the ability to make a credible commitment that they will fork out extractive operators in a way that is sufficient to change the game theory.

You are Probably already playing the slow game.

The slow game is already happening, just socially rather than in a more algorithmic way.

• Using particular applications on particular chains (a kind of affinity for certain types of intents)
• Moving to rollups with lower fees (no exit tax price discrimination yet)
• Complaining that fees are too high and you will leave you are playing the slow game (making a threat not coordinated but a threat nonetheless)
  • No, really

Problems

• Messy, subject to propoganda
• Not very efficient
• High switching costs

The way it is currently played the slow game is messy and subject to propaganda, its not very efficient especially with all of these heterogeneous protocols or websites, there are high switching costs.

A Modest Protocol Proposal

An interesting avenue of research. When faced with a coordination problem what you want to ritualize, often a good solution is crafting both tech and culture for a protocol.

What do Operators Do ?

• Custody Assets
• We make a liveness assumption of them
• Most popular: Ethereum validator set

If we reduce this problem to its essence here all we are talking about in terms of operators is custody. Operators custody assets their signature is required, they can deny providing that signature, thats why they can extract in this way. Then we make a liveness assumption of them

What do we as Users want?

• Users want to delegate to operators…but we don’t want the operators to charge “too much”
• i.e., users want to set prices
• Users (as a group) want to negotiate with operators (as a group)
• Users can win because they make system valuable (i.e., operators want their tokens)

We as users want to delegate to operators. We don’t want to be online all the time, but we don’t want the operators to charge too much (hard to quantify). Furthermore, we want to set prices. If users coordinate, they have the ability to set prices because they bring value to the system because they choose to use it.

If we assume that most of these distributed systems are used as accounting techniques to track things going on in the external world. Users choose to create that correspondence between the external world and the accounting system by using it. Ultimately, they have the negotiating leverage. Operators want their tokens and users want to negotiate.

I think users could do this by periodically demonstrating the credible ability to coordinate and potentially agree or negotiate on prices to pay operators. In order to avoid this bridge exit tax problem, Users need to be able to make credible commitments that they will fork out any operators who attempt to extract value when they exit.

The Modest proposal

• We already have this great way to demonstrate ability to coordinate…
• What if users just run consensus?

The good news is we don’t have to invent anything super complicated to solve this.

What must slow game consensus do?

• Demonstrate ability to coordinate
• Signal to other users which operators will be used
• Credibly threaten to fork out operators who try to extract
• Set price guidelines for operators (potentially)

Slow game consensus is the opposite thing of what you think of when you think of fast blockchains. Mostly we work on making blockchains faster; optimizing transaction processing, validators data center co-locations, etc.

Slow game consensus does not care about this. All we need to do is periodically demonstrate the ability to coordinate signal to other users to make it easier to coordinate on which operators will be used and credibly threaten when necessary to fork out operators who try to extract too much. Perhaps setting price guidelines will make things more efficient?

The Slow game is… Slow

Consensus protocols typically have at least N^2 message latency, running consensus amongst millions or billions of users won’t happen in seconds, it will be days. We’ll need a bunch of cryptography techniques like BLS-signature aggregation. We probably don’t want a proposer just aggregate individual data. The slow game can be slow. It can be daily, monthly, less frequently. Users and operators typically are in a repeated game, operators want future revenue. So all users need to do is condition that future revenue on operators not setting prices too high. Then any operators who want to show up and claim that revenue, they can do so. If users set it too low, no operators will come. They can iterate on a negotiation until they get to a mutual agreeable level.

We don’t discuss the particular economics, but the concept of a Solver DAO or Builder DAO is very relevant to this. If you expect operators to coordinate as a class, and perhaps there is some composition subgroup coordination within there, that class and users as a class are going to end up negotiating.

In particular, we also think it's helpful to have the ability to run the slowgame on demand. Suppose that next week the Ethereum validator set decides, oh shit everyone is moving funds over bridges to rollups and they are never going to come back. ANd they decide to set all of your bridge withdrawal prices to the value of ~95% of your tokens. So if you want to withdrawal to a rollup they will say erc20.transfer you must give 95% to the validators, maybe socially distributed.

In order to deal with this we need the ability to run this slow game on demand or at least demonstrate that we can do so. Such that if validators try to do that you can run the slow game and agree to copy the state of this particular location and change the operators. Ex. You would copy the entire state of the EThereum blockchain (the accounting history you want to preserve) and set new location with different operators. You need to do this atomically (you need to run consensus amongst the users )because this is a coordination problme. You don’t want 2 forked Ethereum's competing with each other. You want to switch all of the state atomically to a new location.

Nothing New Under the Sun

• We’re already running consensus
• Just not with a protocol
• A protocol (tech + culture) makes the threat more credible

In some sense, this is nothing new. We are already doing consensus. People are already talking amongst themselves about where they want to send transactions. But we don’t have a protocol. A protocol would make the threat more credible and would provide a period test that we actually have sovereign networking infrastructure and the ability to fork out operators if they are too extractive. Luckily, this is not even that hard, we are just running consensus with a lot of people.

Network Topology

One way of thinking about things is that users are the disconnected dots or the large circle at the edge of the system. They interface with the system and the outside world. They ultimately control if they coordinate the constraints over what can happen inside the system. If users don’t coordinate the MEV gets sucked into the center. But if users coordinate the center is paid some amount which is negotiated but effectively fixed by the users and everything keeps going.

End-state Equilibrium

• Users set fixed margin for operators
• Users want to set enough for secure setups, maybe not “brutal” competition
• Also references based on locality, trust, etc.
• Users run slow game periodically to keep things credible
• Prices go down slightly over time as compute gets cheaper
• Everyone is happy (?)
• Needs more match

One question which needs more mathematical formalization is what does the end-state equilibrium of this system look like. There are a lot of dimensions of complexity and multi-variable preference optimization that we have completely glossed over and are not trivial including; locality, low latency, trust. In general, we should aim towards a system where users coordinate. And in their coordination they set with several rounds of negotiation a fixed margin for operators. Users here were assuming have multiple variables they care about. They might not want race to the bottom margin competitions. Users may want resilience of operator sets. If you put everyone in race to the bottom margin competition, to some extent you select against resilience.

Users may want to include more variables in how they select operators. But still, you would expect that prices will go down slowly over time as compute gets cheaper and prices get more standardized as the system becomes more streamlined. It seems to me that if you reach this equilibrium, everyone is roughly happy. Some operators are paid a constant cost (a multiple of networking, bandwidth, and hardware costs) users still have control over the system and no more than some finite amount of MEV is extracted by the operator class. But if we don’t have a credible coordination game, even if we solve all the other MEV problems, it's a big deal. Especially once operators realize to some extent people are paying them because their assets are custodied not because they explicitly trust the Ethereum validator set. As protocols standardize, the market for operators becomes more competitive.

Conclusion and Take aways

MEV is more than information asymetry, ordrflow, compute delegation, or even cross-domain concerns (a fundamental part of MEV is just about delegation of custody. There is potential for extraction if users dont coordinate. We havn’t seen this part of MEV yet in the world but we probably will. Its a very dangerous kind because you don’t see it until a system becomes embedded. Once a system is extremely embedded, thats where the extraction happens. If the switching costs are too high and users don’t coordinate we see this with the real world, google has physical fiber lines, if your adversary winds up controlling the physical network infra you are SOL. You want to design against this before it happens by accident.

• Users decide what is valuable, but to prevent the operators to whom they delegate agency from extracting that value, they must coordinate, and coordination requires consensus (social or otherwise)
• ”Slow game” consensus deosn’t need to be fast, it just needs to be credible. A credible commitment changes the equillibrium.