No sandwiches allowed — how to prevent MEV attacks on AMMs
This is a follow on post of my initial post on how Carbon (and the big virtual fees inherent in a Carbon’y position) make sandwich style MEV attacks impossible, and Mark’s subsequent posts that quantified this, and looked at what those formulas imply. This post is more of a lab notes style post that works with some of the formulas in Mark’s latest article and discusses them further.
Background
The key formulas that we are working with here are
from article 1, and
from article 2.
Before we go further into those equations, I want to take a moment to define the symbols used as this will greatly aid the understanding of the formulas
- Q is the profit an attacker makes with a sandwich attack that is based on the other parameters below, and
- Δxₐ is the size of the front-running trade that leads to this particular value of Q. The trade parameters are
- Δxᵤ which represents the size of the user trade in token terms,
- x which represents the size of the pool in the same units as the Δx (virtual size in case of levered pools, but this analysis ignores the stuck-at-the-boundary implications of levered liquidity), and most importantly
- δ represents the percentage fee of the pool (in decimal terms, eg 10bp = 0.001)
The key equation we will be looking at here is the second equation above. It is obtained from the first one by first deriving with respect to Δxₐ, and then requiring that the derivative of Q with respect to Δxₐ vanishes at Δxₐ=0. This condition ensures that Δxₐ=0 is optimal for the potential sandwich attacker, in other words, there is no arbitrage profit.
Simplifying the formula
We see that the formula above, as written, consist of three terms, the first two of which are trivial because they yield solutions that are not financially interesting. One of those terms shows that an empty pool (x=0) does not allow for sandwich attacks, and the other solution is at an unreasonably big value of Δxᵤ and can therefore be discarded. We are therefore left with the operation part of the equation which is as follows
To paraphrase what Mark discusses in his article, the above condition should not be an equality but an inequality because of course attackers will never engage in loss making transactions. Therefore
- δ is really inf δ as any fee >δ will also prevent sandwiching
- Δxᵤ is really sup Δxᵤ as any trade <Δxᵤ will also prevent sandwiching, and
- x is really inf x as any pool liquidity >x will also prevent sandwiching
Mark has in his article solved the above equation for δ, Δxᵤ and x, yielding the following formulas
For us the first of the three formulas above is the most interesting one — it indicates how big the fee has to be for a given trade so that sandwich attacks no longer make sense. I slightly rewrote it into the new notation, indicating that the no-sandwich-possible conditions holds for this fee level δ and above
This formula looks disappointingly complex — but fortunately it has a nice asymptotics for big values of r=x/Δxᵤ (aka small trades):
In the chart below the red line is the actual curve, the blue line is the power law asymptotics 1/r, and the green line is the (massively) improved asymptotics 2/2r+3
(see here for the underlying desmos calculator)
Whilst r=x/Δxᵤ works better for the formulas, financially the more intuitive quantity is the liquidity-normalised trade size 1/r = Δxᵤ/x. It is important to keep in mind that this is also the percentage slippage, ie the amount by which a trade of size Δx adversely pushes the price of a pool of size x.
Therefore we find the following, important result:
Minimum fee levels so trades cannot be attacked
Small trades (1% of pool size or less) can not be attacked by sandwich attacks if the fee level is bigger than the slippage (which is also the liquidity-normalised trade size), ie δ>Δxᵤ/x. For slightly bigger trades — up to about 10% slippage — the approximation δ>2/(2r+3) works well, and beyond that the full formula [2] above should be used.
Maximum trade size that can’t be attacked
Similarly we can look at the maximum viable trade size as a function of the fee level that cannot be sandwich attacked. We start with equation [3] from article 2 above but we divide both sides by x and by δ. We recall that Δxᵤ/x is the (liquidity-normalised) trade size, and therefore the new LHS of the equation Δxᵤ/xδ is the normalised trade size (also: slippage) divided by fees.
We have charted the RHS of the above equation below
(see this chart on desmos)
The way to interpret the above chart is as follows: for a given level of fees (here 0.2 = 20% fees), what is the maximum normalised trade size as a percentage of fees? For small for small values this number is unity, ie for small fees the maximum non-sandwichable normalised trade size equals the fees level. If fees are bigger then the possible trade size increases disproportionally. Eg at 20% fees the trade size can be 20%*1.4=28% of pool size before it is sandwichable.
We should note however that this increase in trade sizes only happens for rather large fee levels. Below a slightly more reasonably view on this graph with fee levels up to 5% where the improvement is linear at about 5% for every 3% of fees and therefore below 10% at a 5% fee level, ie not particularly meaningful when compared to a base value of 100% (and definitely not at fees < 1%).
—
