Maximal Extractable Value
Ahmad Kida
Block Scholes Ltd.
Email: andrew.melville@blockscholes.com
Introduction
Maximal Extractable Value (MEV) was first discussed in a Reddit post that precedes the launch of the Ethereum Network. The term refers to revenue that can be generated by any permissionless actor in the ecosystem such as blockbuilders (miners or proposers), nodes, or users by taking actions such as the reordering, inclusion, or exclusion of transactions within a block in order to capture value that is emitted onchain using onchain actions. MEV occurs on smart-contract-enabled blockchains such as Ethereum and Solana through the interaction of the Defi ecosystems built on top of them. Whilst other offchain opportunities for value extraction exist for block builders, we do not include them in our discussion of MEV.
This definition implies that these actors must influence the ordering of transactions on the blockchain. By including transactions before other users, actors can extract revenue that is emitted by transactions in the mempool. They exert this control by either building blocks themselves, or incentivising block builders to prioritise their transactions. Blockchains and mempools such as Bitcoin’s and Ethereum’s are public ledgers whose contents are publicly available. This transparency enables any actor within the ecosystem to pay block builders and have their transactions included before the target transaction.
Figure 1 Diagram showing Block Builders prioritising blockspace for transactions in the mempool with higher gas fees (paid in ETH) in order to maximise their profit. Transactions with lower gas fees will be included in a later block on the chain, but will not be able to specify their position within that block.
Blocks within Blockchains can carry only a limited number of transactions, a choice that has numerous implications. Block builders search the mempool for transactions to include inside their blocks and, because they are driven by profit, will choose to prioritise transactions with higher gas fees attached to them. Users in the ecosystem leverage this feature and express their preference to have their transactions prioritised by the block builders by attaching a higher gas fee to the transaction. As there are no strict transaction ordering requirements, block builders are free to choose the transactions to include and which order to include them in their blocks. The lack of ordering requirements, coupled with the limited amount of blockspace allows MEV opportunities to readily present themselves in blocks.
Block builders can auction off their blockspace to entities, called searchers, who specialise in capturing this MEV. These specialised entities submit bundles of transactions to block builders to be included in blocks in the exact order that they specify. These searchers deploy specialised algorithms and bots to parse blockchain data for MEV opportunities, such as liquidating other users’ loans or exploiting arbitrage opportunities between Decentralised Exchanges (DEXs). Alongside their own bundle of transactions, the searchers submit a bid to the block builder to have their bundles included first.
Timeliness is of utmost importance to a searcher’s success. Many MEV extraction techniques rely on including transactions before other users. At the same time, searchers also have to compete with other searchers looking to capitalise on the same opportunities. As such, searchers can bid very high gas prices on their bundles to have them included onchain. These are formally known as Priority Gas Auctions (PGA), a term coined by the Flash Boys 2.0 paper which was the first to extensively review the MEV problem. PGAs create unfavourable environments for end users; having to compete with the high gas prices bid by searchers to have their regular transactions included.
Types of MEV
When builders are elected to produce a block they have full autonomy in controlling the next state of the network, provided that their block does not violate the rules of the protocol. Different types of MEV can align or misalign the incentives of the block builder with those of the protocol. We will explore the different types of MEV extraction techniques, some of which can be good or bad for users and the network itself.
Good MEV refers to the type of MEV that has a net positive impact on the health of a blockchain ecosystem. Though some users directly involved in this type of MEV may be negatively affected (as will be discussed below), the impact it has on the health of the ecosystem outweighs these negatives. Bad MEV referees to MEV have a net negative effect on both users and the ecosystem. These types of MEV aim to directly extract value from the hands of users and might, in some cases, disrupt the functionality of the protocol.
“GOOD” MEV
DEX Arbitrage
Decentralised exchanges facilitate the onchain peer-to-pool trading of token pairs. In an efficient market, we expect all exchanges to quote the same price for a given asset pair. Token exchange rates are not determined by an order book model (as is the case with centralised exchanges) but are instead based on the ratio of tokens inside of liquidity pools in DEXs that use Constant Function Market Maker (CFMM) algorithms. The details of this mechanism are covered by a previous Block Scholes report that is available on request. Many such DEXs exist and may, at times, quote different prices for a given token pair. The design of the DEX ecosystem creates an opportunity for arbitrageurs to extract some value by providing a service to the market.
On Ethereum, Smart Contracts can encode multiple transactions into one transaction that is executed atomically. This means that all its constituent elements are executed in an “all-in or nothing” fashion. If any of its constituent transactions fails, then the entirety of the transaction gets reverted. This feature allows arbitrageurs to use smart contracts to deploy trades across multiple exchanges in a single atomic transaction. By trading across multiple exchanges in one atomic transaction, arbitrageurs are able to conduct trades in the smallest unit of time allowing for deterministic returns.
An example of this type of arbitrage transaction can be seen here, where an arbitrageur deployed such a smart contract utilising atomic transactions and obtained approximately 45 ETH by taking advantage of the price disparities of the ETH/DAI pair on UniSwap and SushiSwap.
To capitalise on the opportunity, the arbitrageur did the following:
1. Took a flash-loan (a loan that must be repaid in the same transaction and requires no collateral) of 1000 ETH on Aave.
2. Swapped this 1000 ETH for 1,293,896 DAI on UniSwap (the exchange quoting a higher ETHDAI price). By depositing ETH and removing DAI from the liquidity pool, the ratio of ETH to DAI in the liquidity pools also increased thereby decreasing the ETHDAI exchange rate on Uniswap.
3. Exchanged 1,293,896 DAI for about 1045 ETH on SushiSwap. On this exchange, they withdrew ETH and deposited DAI which has the effect of increasing the ETHDAI exchange rate for the SushiSwap pool.
4. Repaid the loan of 1000 ETH back to Aave, which resulted in the arbitrageur securing a profit of 45 ETH (before accounting for transaction fees).
By executing these steps in one atomic transaction, the arbitrager was able to change the ratio of ETHDAI tokens in the respective liquidity pools across each exchange in a direction that brought their prices closer together. In doing so they obtain a risk-free return for their actions. This type of MEV produces an efficient market for users to trade tokens in and is most profitable when a user is a miner/proposer.
“BAD” MEV
Sandwich Trading
Sandwich trading occurs when an MEV searcher sees a large trade on a Decentralised Exchange inside of the mempool. When the size of the trade is large in comparison to the size of the pool, it results in a dramatic price change between the two assets the user is trading. This presents an opportunity for a searcher to take advantage of their advanced knowledge of that price change. Consider an example with an ETH/DAI pool. If a user submits a transaction to buy a large amount of ETH from this pool, they deposit a large amount of DAI which will have the effect of reducing the amount of ETH in the pool and increasing the amount of DAI.
For a searcher to capitalise on this large trade they see going to a decentralised exchange in the mempool, they submit a bundle with the following transaction sequence:
1. The first transaction will remove ETH from the liquidity pool and deposit DAI. This action has the effect of increasing the ETH/DAI exchange before the original user makes their trade.
2. The second transaction in the searcher’s bundle will be the user’s large trade which deposits a large amount of ETH into the liquidity pool, further increasing the ETHDAI exchange rate. The user is forced to buy ETH from the Liquidity Pool at a higher exchange rate than if the searcher had not placed their transaction.
3. The searcher thereafter includes a second transaction of their own directly after the user’s transaction which deposits ETH into the pool and redeems DAI from it, selling ETH at a higher exchange rate than at which they bought it, with the difference in prices being accredited to the large trade made by the original user.
Users who wish to make large trades on Dex’s are likely to be sandwich attacked by MEV bots and will therefore get unfavourable exchange rates when executing their trade. This is a direct result of the first leg of the searcher’s trade which initially increased the exchange rate of the token pain the user wished to trade.
Searcher Incentives & Strategies
In Ethereum, block producers are granted rewards denominated in ETH for producing valid blocks and appending them to the canonical chain. Following the deprecation of block rewards after the Ethereum network transitioned from PoW to PoS, there is a larger incentive for validators to participate in MEV extraction. These validators leverage their privileged positions as block builders to boost the total revenues they receive by participating as a searcher themselves or working with searchers to extract MEV. Searchers outcompete one another by being faster at detecting MEV-emitting transactions and by being able to bid higher gas to have their bundles included first. Below, we discuss some tactics that searchers employ to allow them to be more competitive.
LOW-LATENCY INFRASTRUCTURE
One such technique that searchers use to gain a competitive edge against other searchers is to have a low-latency monitoring infrastructure. A view of the network state and mempool that is updated more frequently than other searchers allows them to detect MEV opportunities before other searchers do. This allows them to extract MEV at a more frequent rate than their competitors. Searchers can also optimise their smart contracts for speed by writing them in lower-level languages like Rust that are closer to the low-level assembly code that the Ethereum Virtual Machine (EVM) operates on. Smart contracts written in high-level programming languages like solidity (a popular smart contract scripting language) are always translated into assembly code to be processed by the EVM. Searchers can choose to write smart contracts in assembly code itself, though the level of technical expertise required may substantially outweigh the increase in processing speed that it gives the searcher.
GAS OPTIMISATION
Searchers compete amongst themselves by bidding high gas prices to have their bundles included in blocks. Increasing the amount of gas they can bid therefore gives them a competitive advantage over other searchers. In submitting their bundles, the searcher’s transaction incurs some overhead gas costs associated with on-chain data storage. Searchers can benefit by reducing these overhead costs which allow them to bid higher gas prices. One such example is discussed below.
Larger, and more complex smart contracts require more computation and therefore more gas to be deployed on-chain. It is therefore in a searcher’s best interest to optimise their smart contracts to achieve the same functionality while decreasing the gas costs incurred in its deployment. In addition to this, searchers can use addresses that start with multiple 0’s, an example address of which can be seen here. These types of addresses use less storage space on the blockchain and so have fewer gas costs associated with them when making transactions.
MEV in the future
The continued widespread adoption and use of applications built on smart-contract-enabled blockchains will only increase the amount of value emitted on-chain. Searchers will continue to capitalise on this and will exacerbate it in unfavourable examples such as sandwich trading. MEV can be seen as an inherent feature of smart contract-enabled blockchains, and so both protocol and network developers must take this into account when designing their systems. In subsequent reports, we will further explore the protocol-level effects of MEV as well as protocol-level and non-protocol-level mitigation techniques.
