July 14, 2023

Arbitrage loss and how to fix it


Especially since @thiccy’s markout analysis on Uniswap LPs, AMMs have been under fire for getting picked apart by arbitrage and in the end being unprofitable for LPs.

Uniswap's own Dune query now shows ~250mio in losses, for just their ETH/USDC LPs, and ~30mio net loss after accounting for fees earned.

Tim Roughgarden et al.’s paper Automated Market Making and Loss-Versus-Rebalancing did a great job a modelling one of the ways AMM pools lose value to arbitrage: Loss-versus-Rebalancing (“LVR”). Check this thread by Ankit, for an easy-to-understand example on how LVR works.

I kind of assumed that LVR more or less sums up the value that AMM LPs lose to arbitrage. And that if we fix LVR then we fix arbitrage loss.

Turns out I was wrong. Actually arbitrage loss is much bigger than LVR, and there are at least 2 more ways AMM LPs make lose to arbitrageurs.

This article shows what these additionally types of arbitrage loss look like and how we could fix them in AMMs.

Let’s have a look where things are broken.

The three sources of arbitrage loss

Arbitrageurs steal from AMM LPs in three ways:

  • Stale prices: AMMs selling to arbitrageurs at outdated prices (LVR).
  • Backrunning: AMMs loosing price-impact-gains they just earned from a trade.
  • DEX-DEX gains: AMMs stealing price-impact-gains form other AMMs, and then loosing them to arbitrageurs.

Let’s start with a short recap of the loss that’s known best: Stale prices loss, i.e. LVR.

Arbitrage loss from stale prices

1. Pool aligned with market. 2. Market moves on. 3. Arb bot buys at stale price.

In the case, where the market prices for token are determined by another exchange (e.g. on Binance), CFMMS always lag behind. Since CFMMs only change their price, when someone makes a trade, their price tends to become more and more “stale”, until someone trades it back to market price.

Since arbitrageurs want to make a profit, they only execute this trade when their profit  is bigger than the fees they need to pay the CFMMs – and therefore these rebalancings are usually a net loss for LPs.

There's a phenomenal paper on loss from stale prices if you want to dive deeper: “Automated Market Making and Loss-Versus-Rebalancing”.

The next arbitrage loss is a bit more surprising.

Arbitrage loss from backruns

Value first flows from the trader to the LPs in the form of price-impact gains. And then to the arb bot.

Backruns are no news – but how they are commonly understood hides the fact that the profit does not come from a retail trade, but actually out of the pockets of the LPs. 

More precisely what happens is that the trader gives profits to the LPs – and then the arb bot takes it away from the LPs. And this is an important distinction, since it first belongs to the LPs, and a better designed AMM could protect these gains.

This is how it works:

1. A retail trade move the pool above market. 2. An arb bot pushes the pool back close to market.
  1. Someone buys on the AMM pool an pushes the price up, above market price.
  2. An arb bot then right-away trades in the other direction and makes a profit.

Let’s take a closer look at step 1, where the LPs temporarily make a good profit.

LPs sell assets above market price as price-impact increases.

Due to how CFMMs work, as trader executes their trade, they are paying an increasingly higher price – more and more above market price. Meaning that from the perspective of the LPs they are selling to the trader above market rate. So the LPs, in addition to DEX fees, also make a profit by selling above market price. The bigger the trade, and the steeper the CFMM curve, the higher this profit (the profit actually grows quadratically with trade size).

Let’s call this profit, that the LPs make from selling above market rate to the traders, price-impact gains. Because the LPs profit from the fact that trades on CFMMs incur a price impact.

Do LPs get to keep this profit? Some of it, but much of it is lost again to arbitrageurs.

How AMMs lose price-impact-gains to arbitrage

If a trader moved the pool price far enough above the market – then arb bots again will arbitrage the difference.

However, not all is lost, because this converts some profits into pool fees: The arb bots don’t steal all the price impact gains, because they also have to pay the pool fees. This way, some of the price impact gains the LPs made from the trader are converted into pool fees. But a big chunk is lost to the arb bot.

However, the journey of the price impact gain doesn’t end here.

Arb bots don’t move prices fully back in line with the market

Arbs don’t move pools fully back in-line with the market.

You might have noticed there was gap left in the first image. And that’s because arb bots only arbitrage to the point where their marginal profit becomes 0: I.e. the point where the price gap is equal to the sum of fees the bot needs to pay (gas + pool fees + cost of rebalancing and some cost of capital).

The rest of the gap is closed in a more interesting way: By smart routers who help the next traders find the best price.

Smart routers convert the remaining price-impact gains to fees

Being closer to the market price, the pool is now no longer interesting for arbitrageurs.

However, the pool is still highly interesting for solvers, since, in one direction, the pool offers the best price on the market, compare to all other pools.

So, the next time a user trades in this direction, solvers will route this trade through our pool, and thereby move the pool closer to market, until the pool is exactly back in line with the market. And these trades also pay fees to the LPs converting more of their price-impact-gains into fees.

There is a crucial difference between solvers and arbitrageurs here: Solvers split the price-impact-gains between the trader (who is getting a better-than-market rate) and the LPs (in the form of fees). The arbitrageur extracts value from the market.

There’s one more, even less explored, way LPs lose to arbitrage.

LPs first take then lose price-impact gains from other DEXs

1. Another DEX pool makes price-impact gains. 2. You capture part of their gains through an arb-bot.

Let’s say another pool has a high price-impact trade from a user (image 1.) and holds price-impact gains. But as we’ve seen before, an arb bot backruns the pool to take the gains.

However, against what pool does the arb bot backrun? Perhaps against your pool – and thereby pushes your pool above market price too.

Backruns transfer price-impact gains to other pools

Your pool profits twice in this scenario: You get paid trade fees plus you also get some price-impact gains from the trade. And these profits both are sponsored by price-impact gains that the other pool is loosing to the arb bot. So you just took gains from another pool.

Which raises an interesting question on adversarial pool or hook design, that aims to for this to happen more often. 

Now, once your pool is above market, the same price reversion game starts again. Where you lose some of the price-impact gains you just made, and turn the rest into fees.

However, your pool is net ahead in this scenario. The user chose another DEX for their trade – but you ended up with some of their price-impact gains as fees.

Arbitrage loss > LVR

So arbitrage loss is more than just LVR. It’s at least LVR plus the lost price-impact gains.

Tim Roughgarden et al., didn’t overlook this of course. They shortly mention this in their LVR paper – calling the loss of price-impact gains “reversion arbitrage”. However, reversion arbitrage didn’t make it into the LVR model – and as a consequence it’s gotten much less attention than losses from stale prices.

But it’s not all lost, there are ways AMMs can capture these price-impact gains.

How AMMs can capture their price-impact gains

Increase fees after high price-impact trades in one direction

As we saw earlier, especially when pools make high price-impact gains – they then lose most of the gain quickly to arbitrageurs. And only get a small compensation for it in fees.

However, when a pools is holding a high price-impact gain it could charge a much higher fee, and and still be attractive for solvers.

In particular the pool could charge a fee up to the difference to the market price – and would still receive orderflow from the solvers.

After a trade with high price-impact the pool increases fees in the opposite direction.

But, solvers would only route a small amount of orderflow through the pool – precisely as much until `pool_price - fees = market`. Since the pool has a price impact, a small trade will push the price down enough to reach this point.

But this is to the advantage of the pool, because on this small trade it can internalize most of the price-impact gains (as high fees) and losses a much small fraction to the trader.

Next, the pool can reduce the fees slowly, to again attract orderflow that converts more of the price-impact gains into fees.

How to design asymmetric price-impact fees

You can achieve the above with two simple mechanisms:

Set fee equal and opposite to price-impact

How does a pool know how far above market it is? A good guess is to use the price-impact of the last trade. An afterSwap interaction could set fees to `current_fee + price_impact` (e.g. as a Univ4 hook).

Gradually heal fees

Fees heal gradually to turn price-impact gains fully into fee profits.

Let the fees gradually return back to the pools base fees over a period of blocks. This takes care of two things:

  1. Small cost: If price-impact overestimates the distance to the market, then the pool is only less attractive to Solvers for a short period.
  2. Full capture of price-impact gains: Gradual healing makes sure that as much as possible of the price impact gains are converted to fees. Several smaller trades with incrementally decreasing fees bring much more fees overall to the LPs than one big trade at a lower fee.

The lower the friction from gas costs, and the higher the trading volume the closer the pool can get this way to converting all of the price-impact gains into fee profit.

It also avoids arbitrage entirely, because Solvers will always route before arbitrageurs – since they don’t care about atomic profits, but just marginally better rates.

If you have access to a reliable Oracle you can fine-tune this approach even further.

Asymmetric fees with Oracles fix both rebalancing and reversion arbitrage

If the pool knows the market price, it can adjust it’s fees precisely to the distance to the oracle price. Adjusting fee to `fee = base_fee + distance_to_oracle_price`.

This way, you can avoid the small period where fees are too high and need to heal to a rate where the pool becomes attractive again.

However, you also get a massive second benefit: You will fix LVR, aka stale price, too, since you don’t only adapt fees when a trade on the pool moves the pool away from the market, but you will also adapt fees when the market moves away from the pool.

So with oracle adjusted asymmetric fees alone AMM pools can turn LVR and price-impact losses into LP profits, hence eliminating their negative effect on LPs.


Price-impact gains are an important fee driver for LPs. So far, much of them dissipate back into the market, going to either arbitrage bots or lucky retail traders.

Asymmetric fees could be a simple and effective way to turn most of these gains into fees, and drastically increase LP revenue. With a reliable oracle, you could even capture LVR with asymmetric fees – and solve most of the arbitrage loss of AMMs.

Keep Reading

Blockchain in the age of LLMs

LLMs will change how we interact with blockchains.
Read More

Intents and where to find them

What are intents? And where can you use them? A straightforward definition and a list of use cases.
Read More