Note: This article is authored and contributed by members of Douro Labs. This is the first in a series of articles that discusses MEV. This series will introduce a new formalism with which to understand MEV before covering existing methods to mitigate MEV. Later articles in the series will introduce improvements to protocol design that can help recapture MEV.
Blockchains often feature profitable and short-lived opportunities. Multiple parties may seek to monetize such an opportunity, in order to capture its value. MEV arises from the fact that most blockchains’ transactions are ordered by their miners (a.k.a. validators, sequencers, etc.), who can thereby control who is ordered preferentially to capture the opportunity.
The power that miners have over this ordering across basically all blockchain ecosystems has led to the dogma that MEV is inevitable and cannot be eliminated but rather only contained in terms of its harmful side effects.
However, MEV is not mysterious or inevitable. Rather, it is the direct consequence of divergences between on-chain state and external (off-chain) state. On-chain state refers to the state of protocols on the blockchain (e.g. the number of tokens in an AMM pool). Off-chain state refers to the state of the external world that is not natively on the blockchain (e.g. the trading activity of a symbol on Binance).
When protocol state and external state disagree, bringing them back into alignment can be profitable. When the price of a token moves up (down) on centralized exchanges (CEXs), traders can profit from buying low (selling high) on AMMs. Similarly, when token prices on CEXs change significantly, liquidators can profit off of the liquidation bonuses that lending protocols provide to incentivize liquidation. Because these actions have guaranteed profit, they are hotly contested by many searchers, leading them to be bid up at the priority gas auction (PGA) at the miner level.
The MEV in these cases originates from miners accruing value from incentives baked into protocol design to bring on-chain and external state into sync. It can thus be seen as a value transfer from protocols to miners. This is in spite of the fact that miners are inherently providing very little service to the protocols and the ecosystem to bring the states back in sync: they are not the players taking any risk to perform these important actions but rather the beneficiaries of the rudimentary transaction ordering flow baked into the design of most blockchains.
A Taxonomy of MEV
We can distinguish between two types of protocols: those that operate independent of external state, and those that are dependent on external state. To be more precise, there are protocols for which the action set is independent of external state, and protocols whose action set is constrained by external state:
- A vanilla constant-product AMM (e.g. Uniswap v2) operates independently of external state: whether a user is allowed to take an action on the AMM depends only on the state of the AMM, and not on external information like prices on centralized exchanges.
- A lending protocol relies on external state in the form of centralized exchange prices for determining users’ available actions: a user can only take actions that preserve over-collateralization. Lending protocols typically rely on oracles to ferry external state like CEX prices onto the blockchain.
(Note that in reality, no blockchain protocol is actually constrained by truly off-chain state. The protocols constrained by external state that we discuss are generally actually constrained by on-chain oracle state. However, oracle state is a special form of on-chain state that reflects external state, and the dynamics of oracle state changes therefore differ from those of other types of state changes. For these reasons, we make the distinction between protocols whose action set is independent of oracles and protocols whose action set is dependent on oracles.)
For each of these types of protocols, there are two ways that protocol state and external state can come to differ from an initial position of agreement. Either protocol state can deviate from external state due to an on-chain state change, or external state can change. Thus, there are four classes of deviations to consider in terms of how they create MEV:
- Protocols that are independent of oracles
- On-chain state changes
- External state changes
- Protocols that are dependent on oracles
- On-chain state changes
- External state changes
In cases 2A and 2B, an oracle serves to bridge the external state necessary to inform allowable protocol actions. In cases 1A and 1B, no oracle is needed. The differences among these cases are important. They dictate how MEV is currently captured and how it can be disintermediated and recaptured by different parties.
Below, we dive into each of the cases.
1A: Independent of Oracles, On-Chain State Change
In this case, the transactor who makes the on-chain state change generates a profit opportunity for searchers to match on-chain state back to external state. When the action of matching on-chain state back to external state is permissionless (i.e. anyone can perform that transaction), the competition to carry out that transaction leads searchers to bid up in the PGA, creating MEV that flows to the miners.
An example of this is a whale trader on an AMM pushing the implied price on the AMM significantly away from the prices on centralized exchanges, thereby generating an arbitrage trade opportunity.
Because the transactor of the initial on-chain state change generates the profit opportunity, they have some power to determine who transacts after them. For example, they could run an auction amongst searchers and bundle the highest bidder(s) with their state change in exchange for payment; this type of generalized order flow auction (OFA) is what MEV Share actualizes. Thus, the transactor of the initial on-chain state change has greater hierarchy to determine who carries out the profitable transaction than the miners and can in theory disintermediate the miners (i.e. validators, block builders, members of the block building and proposing stack) from monetization.
However, above even the creator of the opportunity in this hierarchy is the protocol. The protocol can gate who gets to act on certain opportunities by means of changes to protocol logic: for example, the protocol can dictate that under certain conditions of protocol state, only permissioned actors can transact. The generalized extension of this is an OFA run at the protocol level: under this model, the protocol would determine the ordering of some or all transactions interacting with it in a block. As the existence of MEV clearly indicates, whosoever dictates the ordering of transactions commands the lion’s share of the profit opportunity. In this case, the protocol would replace the miners in monetizing value created by any on-chain state changes away from external state.
Hence, there is a hierarchy of monetization: protocol, transactor, miner.
1B: Independent of Oracles, External State Change
In this case, the opportunity exists due to a deviation in external state that has yet to be reflected on-chain. Because there is no on-chain trigger required to create the opportunity, it exists free for any searcher/arbitrageur to claim anywhere within the block.
An example of this is the price of an asset moving on centralized exchanges, creating profit opportunities for traders able to complete the arbitrage between CEX and DEX.
The hierarchy mirrors that of 1A, except that there is no on-chain transactor that creates the profit opportunity. Miners currently claim the lion’s share of the profits. The protocol could reclaim some of this value in a similar fashion to that discussed in 1A, by dictating the ordering of some or all of the transactions that interact with it.
2A: Dependent on Oracles, On-Chain State Change
In this case, the protocol action space is constrained by external state that is bridged on-chain via an oracle. An opportunity could arise because a transaction causes on-chain state to drift away from external state.
Examples of this are harder to come by naturally than in the other cases, because on-chain state changes away from external state are usually constrained by the rules that govern the protocol action space. For example, lending protocols typically do not allow vault owners to bring their vaults’ collateralization ratios under the minimum required ratio. However, this class of MEV is in theory possible: one can imagine a situation in which a stale oracle state allows one to under-collateralize their vault, which can be liquidated after an oracle update is brought on chain. In this case, an oracle update is needed to capture profit. Thus, this situation resembles 2B—refer to the discussion there as to the hierarchy of profit capture.
Alternatively, an on-chain exploit could drain vaults of some tokens, thereby creating vaults under the minimum collateralization ratio. Here, an oracle update is not needed, and the profit opportunity exists for anyone to capture anywhere in the block. This is similar to 1A and follows the hierarchy discussed there.
2B: Dependent on Oracles, External State Change
In this case, external state changes, and an oracle update ferrying the information of that change is the trigger for a profit opportunity. When the subsequent profitable transaction is permissionless, searchers/arbitrageurs bid up in the PGA to be bundled with the oracle update, causing value to flow to the miners.
An example of this is the price of an asset moving on centralized exchanges and causing a vault on a lending protocol to become under-collateralized and eligible for liquidation. This creates profit opportunities for searchers able to liquidate the vault and complete an arbitrage on CEX or DEX.
The hierarchy here mirrors that of 1A, with the caveat that the trigger transaction is now an oracle update. Thus, whoever performs the oracle update is the initiator of the on-chain state change that enables the profit opportunity. The full hierarchy is thus: protocol, oracle updater, miner.
Coda
In this article, we dispel the notion that MEV is enigmatic and inevitable. Our categorization of MEV serves to reflect the different dynamics of MEV depending on how it is triggered. These dynamics suggest ways that MEV can be recaptured by different parties.
The next article in this series will discuss how existing protocol designs deal with MEV leakage.
Stay Updated with Pyth
Stay informed about Pyth network's development and upcoming events!
