Originally introduced in the paper, Flashboys 2.0, Maximal(or Miner) Extractable value is the value that is captured by miners or validators from users in a network. While exotic forms of MEV exist, the most common form of MEV comes from reordering user transactions to maximize fees or frontrunning users while making a trade.

This blog is a primer/explainer for the paper, “Towards a Theory of Maximal Extractable Value I: Constant Function Market Makers”.

The Anatomy of a transaction

While the granular picture of a transaction from genesis to getting included in a block is perhaps a much longer article, We can take a simple look at it before we understand the nuances of how MEV works practically.

The users submit transactions which appear in the mempool, and there are various views (one way to think of a view is a permutation of the ordering or submission of transactions). MEV searchers can have a different view or design one to create a bundle (with some metric to optimize, almost always for profit). Sometimes the user could directly submit the transaction to the searcher and this is also termed “Order flow” in common parlance. The view/bundle is submitted to the validator for inclusion and this accepted bundle/a bunch of accepted bundles together create the block.

The frontrunning attack in practice is quite simple, after seeing a users trade for buy an asset X, a transaction is submitted before for X which pushes up the cost in case of buying after which the user’s transaction gets executed at this updated value which results in worse price execution and another transaction is submitted which sells the asset, the difference in this frontrunning i.e buying before a transaction is submitted and selling after is usually the profit (deducting gas costs or bribes to the miner/validator for allowing these transactions). This is also known as a Sandwiching attack and is mostly done on Automated market makers. While multi-block MEV might exist or does exist in some forms, most MEV today is extracted in single blocks.

The paper tries to answer two critical questions about MEV that occurs in Constant Function market makers (DEXes that we use belong to this broader generalization of the concept):

• In a Single CFMM with two assets, how much does reordering user trades affect the excess price impact caused by sandwich impacts?

• In the case of a network of CFMMs trading multiple assets, how much does the presence of sandwich attackers on the network affect the routing of trades?

The paper overall, the first in many, analyzes game theoretic properties of MEV ultimately establishing the following:

• In the case of reordering MEV, the maximum price impact caused by reordering of sandwich attacks in the sequence of trades is on the order of O(log n) where n is the number of user trades.

• In the case of routing MEV, the existence of MEV both degrades and counterintuitively improves the quality of routing.

• The paper also shows that if the impact of a sandwich attack is localized, then the price of anarchy is constant. [Similar to the tragedy of commons which talks about selfish behaviour by people in public goods systems, the price of anarchy is a game theoretic formalism that measures how much the efficiency of a system degrades by the selfish behaviour of its agents/users]. In simpler words, sandwich attacks do not greatly impact routing quality in networks of CFMMs.

• The paper analyzes MEV through a theoretical lens and discusses the economic properties of systems with MEV. The focus of this paper is mostly on user-made transactions with a particular type of Automated market maker i.e. Constant function market makers.

One of the fundamental reasons for being able to extract MEV by a miner is their ability to see all transactions publicly before committing to validate a block. In the paper, “Differential privacy in CFMMs”, Angeris et al connect MEV profits in AMMs with a loss of user privacy. In studies that were done in differential and federated machine learning, it was found that a model’s utility to its users generally goes down as user privacy is increased. This can be attributed to the fact that most privatization of data includes adding noise to inputs and models trained on this data suffer from data quality loss. The maximum loss to a user from lack of privacy is also a major factor in the calculation of maximum profit through MEV. This paper also studies a tradeoff between privacy and utility for users of CFMMs.

Deriving from the works of “Differential privacy in CFMMs” and “Improved Price oracles: CFMMs”, the following things can be observed:

• In the Differential privacy paper, the authors show the trade-off between the cost of privacy and the level of privacy. When a trade is split into two smaller trades combined with shuffling the order of transactions this leads to better privacy for users while worsening their price impact.

• In the CFMM paper, It is demonstrated that splitting trades and executing them on a CFMM leads to worse utility i.e. worse price execution (the user pays a higher price for the same quantity of an asset.

These results let us conclude that CFMMs trade off privacy for utility.

Sandwich Attacks

As mentioned before, Frontrunning trades involve placing an order before a user’s order which results in a worse execution and then selling to book a small profit. These trades are also called Sandwich Attacks.

Usually in Centralized exchanges when users place an order they mention a price at which they want their order to be executed and these are called limit orders. While in highly volatile environments it might not be possible to fill the entire order at a price which results in slippage.

Decentralized exchanges don’t have “limit orders” and the limit price is expressed in the form of a slippage limit. The way to think about it is, If I were buying a token $X at 100$ and I express my slippage limit as 0.5%, the worst price I’m willing to settle at is 100.5$. While 100.5$ is not terrible, Decentralized exchanges have worse slippage compared to Limit order books (that run on centralized exchanges), more often than not slippage limits are around 2-5% depending on how much liquidity is available for a token. An easy notion to build is low liquidity markets have more volatility and in turn more slippage for the same size of order when compared to a highly liquid market. Why is this relevant?

When an adversary (miner/MEV searcher) looks at a user’s trade with the slippage order, they can now submit a trade which pushes the price of the token to the worst possible execution price for the user. If a user wishes $X at 100$ and places a slippage of 5%, the worst possible price the user would settle for is 105$, an adversary seeing this can buy the token $X pushing the price to the highest slippage limit at which the user buys the token and the adversary sells his token back thus booking a profit.

Uniswap

Before establishing Sandwiching for generic CFMMs, we establish it for Uniswap.

In the paper, “An Analysis of Uniswap Markets”, Angeris et al established that a trade in Uniswap is valid if

Also written as,

where the equation is an expression for a pool between two tokens A, B, R_a is the reserves of token A, and R_b is the reserves of the token, ∆ is the user trade size of token B and ∆′ is the amount of A tokens he gets, and 1 - γ is the fee parameter. A quick note that it’s called a constant product market maker because if the fee parameter is zero i.e. if γ is 1 then the product of reserves should always result in R_a * R_b i.e. it should be constant.

The price of A in terms of B is simply given by R_a / R_b, while this is the price quote by Uniswap, for a trade size of ∆ it slightly changes to (this is also called the marginal price of trade ∆)

Ultimately, the amount of output token a user receives using the marginal price is

Now we would like to incorporate slippage into this, As described earlier the slippage limit η can be between 0 and 1. It is the amount of the price impact a user is willing to tolerate. A slippage limit is essentially important because, in the case of multiple trades being submitted at a price, it might so happen that there is some price impact for a few trades. Taking the example of two trades Δ1 and Δ2, a miner might execute one trade before the other so they might not get the exact price that was displayed to them, but by expressing a slippage limit a user declares that they are not ready/will not accept less than (1 - η) times the amount.

The minor cannot execute a trade Δ1 after Δ2 unless

where η is the slippage limit.

When a slippage limit is too large, the above equation becomes a strict inequality and allows for an adversary/attacker i.e. MEV searcher to construct a trade Δsand which

So essentially our “attacker” fills the slack in the equality constraint, worsens execution for the user and books a profit. An easy intuitive way of thinking about it is the attacker is taking advantage of the margin. The trades (Δsand, (Δ, η), Δsand’) constitute a sandwich attack i.e. the order before the user order to pump the price, the user order executed with his slippage limit and the subsequent sale of the token by the sandwich attacker to book the profit.

Quickly going over the case for Uniswap,

Note we only take the positive root when solving the quadratic equation because it also satisfies an intuitive idea that when the slippage is 0 i.e. η = 0, Δsand = 0.

Solving the equation for Δsand and plugging in other values actually give you the exact quantity of Δsand that you can extract.

Constant Function Market Makers

While Uniswap is a part of CFMMs where the function is a constant product, we would like to generalize these results to all kinds of functions in CFMMs.

Recall from Improved Price Oracles: Constant Function Market Makers, the definition of a trading function (an explainer can be found below).

Similar to how we defined it for Uniswap, A CFMM contract only accepts a trade if,

Where Ψ is the trading function whose domain is from: R^2 * R^2 → R.

The marginal price for a trade size of Δ for a CFMM is:

here δ_3 and δ_4 are the partial derivatives wrt to the ith argument. g is known as the price impact function as it represents the final price (marginal price) of a trade.

There are two CFMM properties that we care about α-stable and β-liquid, they are satisfied if

• A CFMM is α-stable if

• A CFMM is β-liquid if

Basically, α-stable means whenever a non-negative trade size of Δ does not change the market price by more than αΔ, it places a linear upper bound on the maximum price impact that a bounded trade can have. Similarly, β-liquid means that there is some price slippage when a token is sold but is linearly bounded from below by at least βΔ.

One important property of g i.e. the price impact function is the ability to calculate

where Δ’ is also can be defined as G(Δ) which is the forward exchange function, this is the amount of output token received for an input size of Δ.

We can also define two-sided bounds for for g(Δ) - g(0), as follows

Exactly similar to the Uniswap case, we found that when the slippage is set too high, then Δsand satisfies, this holds generally true for CFMMs as well:

We derived a case for the exact Δsand for the Uniswap case, we can also find the Δsand’ i.e. the amount of token that the miner needs to sell to stay risk neutral by solving

Where G(Δ), as we noted earlier, is the forward exchange function i.ie the amount of output token received for an input size of Δ. Both Δsand and Δsand’ are in units of input token, and finally, we arrive at an equation to calculate the profit:

The PNL equation here is for net profit and loss.

A note for a study: It would be interesting to do a study of :

1] What potential profits could have been possible if every sandwich attack in the past few years had been sandwich-optimal? Of course, these calculations have to include fees which are missing from our equation.

2] What is the general way sandwich bots calculate token size to be sold or bought does it vary or is it adjacent to the equations provided above?

Bounds on Sandwich attack profitability

To bound sandwich attacks, we first need to reason about the expected size of a sandwich attack Δsand_i given a sequence of trades Δ1, Δ2, …. Δn.

While a complete treatment of all the results might not be possible, we will quickly go over a few definitions and subsequent results from the paper.

A function G(Δ) is (μ, κ) smooth if there exists M>0, such that Δ ∈ [0, M] then there exists μ, κ > 0 such that

μ, κ are different from the stability and liquidity constants we described for the function g earlier.

This definition helps us claim,

This bound simply says that the size of a sandwich attack is linear in the slippage limit. The slippage limit has to be larger than the curvature ratio.

In addition to G(Δ) being (μ, κ) smooth if g(Δ) is β-liquid,

This also helps us analyze constant sum market makers, in “Constant Function Market Makers: Multi-Asset Trades via Convex Optimization”, Angeris et al show that β = 0, therefore plugging into this equation we find that since there is no price impact when one executes a sequence of trades, there is no sandwich profit possible in constant sum market makers.

Ultimately, this series of claims allows us to bound the total trade size and the profit from a sandwich attack by

Simply put, given liquidity and slippage conditions are met, profit and price impact are linear in γ.

Reordering MEV

In the case of reordering MEV for sandwich attacks, we assume the following

• A block size of h that can process n trades

• A sequence of trades T_n = { (Δ1, η1), (Δ2, η2), …. (Δn, ηn)) where 3n < h so that there are enough slots to sandwich attack the trades.

• η1, η2, …. ηn are the slippage limits for the trades which are lower bounded by a single η

We ultimately seek to understand the quantity called as the cost of feudalism, given by

A small digression into what feudalism is and how to intuitively think about this, feudalism was originally a system in which people were given land and protection by people of higher rank, and worked and fought for them in return. In the context of blockchains, we might think of miners offering tx inclusion in the block as the service while the cost is paid in the form of MEV.

We are establishing the cost of feudalism as the ratio that compares the profit captured from sandwiching for the worst affected user to the average user. It characterizes the maximum amount that any individual user’s price execution might be affected by reorderings. We want to upper bound the numerator so we know what the worst case can be and lower bound the numerator so we know what is a cost that at least needs to be paid.

• Trades are roughly mean reverting.

• CoF(Tn) can be bounded as a function of the curvature constants μ, κ, α, β, the slippage limit η and the trade drifts u_i.

  • u_i is defined as the partial trade drift for the ith order, which is defined as

where ξ_j is defined as

and we know that the Δsand_i and Δsand’_i terms satisfy (from the previous section)

• If a set of trades is strongly local, i.e. sandwich trade locality means that it is never more profitable to sandwich bundles of transactions versus sandwiching them individually, then the following hold:

Basically says that the maximum profit captured from sandwiching the worst affected user is O(logn) while the average affected user’s PNL is constant (?).

Plugging these results back into our equation for the Cost of feudalism we get that,

The cost of feudalism is O(log n) i.e. the cost of feudalism just goes up linearly even if the number of trades goes up exponentially.

Routing MEV

Routing MEV for sandwich attacks intuitively means the value that a miner/sandwich attacker can extract from a user’s trade over a network of CFMMs. In the paper, Optimal Routing for Constant Function Market Makers, Angeris et al demonstrate that in a universe of n tokens where also exists a set of CFMMs on pairs of tokens, the routing problem is generally convex (without tx fees). Therefore we can suppose that MEV searchers can optimally route transactions through a network of CFMMs.

To study the impact of sandwich attacks on a network of CFMMs, we define Equilibrium routing. This states that a user’s trade routed over a network from a source token to a destination token over all paths is equal.

CFMM Pigou Example

How does optimal routing change when there is a sandwich attack on the network?

Assuming that there is no sandwich attacker of the G1(Δ) path, then it would be intuitive to us that all things remaining equal we would split the trade through each path so that the price you receive for the token is equalized.

Assuming that α is the fraction of Δ that trades on G1, then the equilibrium is satisfied by α* which satisfies

When both G1 and G2 have the same reserves R1 = R2 for token A and R1’ = R2’ for token B then the equilibrium α* settles at 1/2. The equilibrium can also be calculated by the maximizer of the following function

Where G is the forward exchange function. In routing games, F is called the potential function because the optimality condition

gives us the equilibrium condition which is exactly what we found earlier

In the presence of a Sandwich attacker on G1, the user also submits a slippage limit η, and as we know this quantifies the minimum output that a user wants from a CFMM. Therefore η defines the sandwich attack Δsand as

The F(α) with the presence of the

and the equilibrium is

Essentially, what this means is when the slippage limit is set to 0, the equilibrium stays at 1/2 because the sandwich attacker cannot capture any profit but as the slippage limit grows, the equilibrium starts shifting to α* < 1/2. This means that the trader chooses to take a smaller fraction of their total trade on G1.

The CFMM Braess Example

Before understanding the MEV example, a simple intuition for this can be built by looking at the Braess paradox that actually exists in game theory.

Suppose that there are 5000 drivers that want to go from the start to the end. In the initial setup, no path from A→B exists, only A or only B are the possible paths. So a driver could take start → A → end or a driver could take start → B → end. When a driver takes A the time from start to A is the number of drivers on a/100 and then from A to end is 45 minutes i.e. a/100 + 45. When a driver takes B the time from start to B is 45 minutes and the time taken from B to end is the number of drivers on b/100 i.e. 45 + b/100. As there are 5000 drivers, the fact that a+b = 5000 can be used to find out the equilibrium which is a = b = 2500. Therefore each route would take 2500/100 + 45 which is 70 minutes.

Let’s assume that a path from A→B exists which has 0 time i.e. it is instant transportation, the first driver that does it would probably experience about 2500/100 + 2501/100 time to go from start → A → B → end, which is about ~50 minutes thus saving the driver about 20 minutes. As more and more drivers take this path, assuming this number reaches 3000, the time taken for this path rises to 3000 / 100 + 5000/100 which is about 80 minutes, and the people who stuck to the start → B → end path are experiencing 45 + 5000/100 which is about 95 minutes. These people also start taking the start → A → B → end path and now since everyone is taking it, it takes about 5000/100 + 5000/100 = 100 minutes which is much worse than the 70 minutes that people were taking earlier.

The Braess paradox is a classic game theory paradox which states that in congestion games adding resources may decrease the performance rather than improve them.

Now coming to our MEV example, as stated early on in the article the constant POA (Price of anarchy) can be interpreted as stating that sandwiches do not degrade routing quality. The paper constructs an inverse Braess paradox in which the presence of sandwich attackers in fact improves the network flow but the profit that the sandwich attacker can extract from the network is still bounded. The paradox proceeds in three steps.

1] Set Δ = 1, in the absence of a trading pair between C→D, the equilibrium would settle to splitting the trade half between A → C → B and A → D → B, If we denote α* to be the fraction of Δ, then the net output for α* = 1/2 would be

2] Assume a pair from C → D is added, this additional resource as seen in the original Braess paradox problem, shifts the equilibrium such that the net output the user receives over all three paths reduces vs when no such path existed.

The equilibrium function becomes

and the solution for the equation for the new equilibrium is given by

and the equilibrium shifts from (α1*, α2*) = (0.5, 0.5) to (α1*, α2*, α3*) = (0.29, 0.41, 0.29) for the given diagram since the function for C→D is given by the marginal price function for Uniswap.

3] Now assume a sandwich attacker is added on the CFMM trading assets between C and D, the user specifies a slippage limit η, so over the path A→ C→ D→ the sandwich attacker computes the optimal sandwich (as we did in the case for Uniswap):

The equilibrium now settles to

In a simulation with a sandwich attacker between C to D it is found that the net output increases until η increases at which point, the equilibrium returns to (α1*, α2*, α3*) = (0.5, 0.5, 0). Unlike the Pigou example, this demonstrates that sandwich attacker profit does not strictly increase with the slippage limit because rational users simply avoid the link the sandwich attacker is on, hence this is an inverse Braess paradox because instead of all users using the middle link, the existence of the sandwich attacker makes them avoid it.

Price of Anarchy

The paper then goes on to formally prove this over the presence of sandwich attacks on a network of CFMMs. Constructing a graph G = (V, E) where each vertex denotes a token (similar to the inverse Braess graph) and the edge represents a CFMM trading between A and B. Each edge E is also associated with a price function g and corresponding forward exchange function G that executes a trade.

Informally, it’s proven that

Conclusion

The paper is a formal description of understanding and expressing generic sandwich attacks against arbitrary CFMMs. The paper proves and computes bounds that depend on curvature and liquidity for sandwich attack profitability. It also establishes results in the reordering and routing MEV settings.

While the results have already been mentioned in the beginning, the paper also has practical impacts because it allows for a more formal framework for MEV searchers to benchmark and check their performance against the most optimal performance possible (can never achieve that because of the presence of fees). It also helps wallet designers to pick slippage limits i.e. suggest slippage limits to users while using DEXes so that their price execution is okay and not the worst possible.

Future work involves, extending this work to more complex forms of MEV including cross-chain MEV and MEV related to liquidations.