# No sandwiches allowed — how to prevent MEV attacks on AMMs

# No sandwiches allowed — how to prevent MEV attacks on AMMs

# No sandwiches allowed — how to prevent MEV attacks on AMMs

## Stefan Loesch

## Stefan Loesch

## Stefan Loesch

•

•

•

Aug 11, 2023

Aug 11, 2023

Aug 11, 2023

*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

Sandwich profit Q as a function of the other parameters

from article 1, and

Relationship between parameters when sandwich profit is zero

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

Operational part of the second equation above

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

Formulas from article 2

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

Fee levels that do not allow for a sandwich attack

This formula looks disappointingly complex — but fortunately it has a nice asymptotics for big values of r=x/Δ*x*ᵤ (aka small trades):

Asymptotic behaviour of the minimum resistant fee level for small trades (r=x/Δ*x)*

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*

Minimum no-sandwich fee as a function of r=x/Δ*x*

*(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

Maximum normalised trades size relative to fees as a function of fees

(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%).

Same graph but with fee levels only up to 5%

*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

Sandwich profit Q as a function of the other parameters

from article 1, and

Relationship between parameters when sandwich profit is zero

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

Operational part of the second equation above

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

Formulas from article 2

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

Fee levels that do not allow for a sandwich attack

This formula looks disappointingly complex — but fortunately it has a nice asymptotics for big values of r=x/Δ*x*ᵤ (aka small trades):

Asymptotic behaviour of the minimum resistant fee level for small trades (r=x/Δ*x)*

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*

Minimum no-sandwich fee as a function of r=x/Δ*x*

*(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

Maximum normalised trades size relative to fees as a function of fees

(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%).

Same graph but with fee levels only up to 5%

*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

Sandwich profit Q as a function of the other parameters

from article 1, and

Relationship between parameters when sandwich profit is zero

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

Operational part of the second equation above

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

Formulas from article 2

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

Fee levels that do not allow for a sandwich attack

This formula looks disappointingly complex — but fortunately it has a nice asymptotics for big values of r=x/Δ*x*ᵤ (aka small trades):

Asymptotic behaviour of the minimum resistant fee level for small trades (r=x/Δ*x)*

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*

Minimum no-sandwich fee as a function of r=x/Δ*x*

*(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

Maximum normalised trades size relative to fees as a function of fees

(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%).

Same graph but with fee levels only up to 5%

### Share on social

# Ready to start trading?

# Ready to start trading?

Create an automated trading strategy with WBTC, ETH, USDC, MATIC and all standard ERC-20 tokens*

Create an automated trading strategy with WBTC, ETH, USDC, MATIC and all standard ERC-20 tokens*

# Ready to start trading?

Create an automated trading strategy with WBTC, ETH, USDC, MATIC and all standard ERC-20 tokens*

## Alpha! Alpha!

Read all about it!

## Alpha! Alpha!

Read all about it!

## Alpha! Alpha!

Read all about it!

Subscribe for the latest updates on Carbon DeFi

Subscribe for the latest updates on Carbon DeFi

Subscribe for the latest updates on Carbon DeFi