Skip to main content

A Sandwich-Resistant AMM

· 6 min read

Introduction​

AMMs expose swappers to sandwich attacks. On blockchains with untrusted sequencers, swap transactions are vulnerable to frontrunning, giving the swapper worse execution while benefiting the sequencer.

Most approaches to mitigating sandwich attacks try to solve the issue at the infrastructure layer, relying on trusted third parties to provide pre-trade privacy guarantees. In this piece, we introduce the sandwich-resistant AMM, an application-layer solution to atomic sandwich attacks.

Background on Sandwich Attacks​

Sandwich attacks occur when a victim trader places an order on an AMM with a high slippage tolerance (say 99%). The trader sets high slippage tolerance not because they want to get filled at a price 99% worse than the current price, but because they want to execute a market order quickly. Supposing the victim transaction is a buy order, the sandwich bundle looks like:

  • An unprofitable frontrun transaction from the searcher that buys the coin, up until the point where the victim transaction gets the worst possible execution.
  • The victim transaction, which gets the worst possible execution, and pushes the price up further.
  • A profitable backrun transaction from the searcher that sells the coin, making up for the unprofitable frontrun and then some.

Memecoin traders are most susceptible to getting sandwich attacked because they tend to set higher slippage tolerance, while trading on low liquidity pools for high volatility coins. Sandwich attackers extract hundreds of thousands of dollars per day from Solana users today, with similar numbers for Ethereum.

Example​

Consider a victim transaction that buys 3 units of liquidity from a constant-product AMM. We will express prices in terms of log(price) rather than price, in order to make average price calculations simpler to follow. Numbers are not to scale and are meant to illustrate the high-level mechanics of a sandwich.

  1. Initially, the AMM offers liquidity at a mid-price of p*, with fee level f. The attacker buys 1 unit of liquidity, pushing the AMM's offer price to p* + 2f. The trade executes at an average price of p* + 1.5f. 1
  2. The victim transaction is executed, pushing the AMM's offer price to p* + 5f. The victim's transaction executes at an average price of p* + 3.5f. If the transaction hadn't been frontrun, it would have executed at an average price of p* + 2.5f. 2
  3. The attacker sells 1 unit of liquidity, moving the bid price from p* + 3f to p* + 2f. They execute at an average price of p* + 2.5f, for a profit. 3
  4. The final price shown by the AMM is p* + 3f. 4

Sandwich-Resistant AMM​

We propose the sandwich-resistant AMM (sr-AMM), an application-layer mitigation that makes sandwiches unprofitable. The sr-AMM extends constant-product AMMs by enforcing an invariant: no swaps get filled at a price better than the price at the beginning of the slot window. This is an extension of an idea introduced by Vitalik Buterin in 2018 and makes atomic sandwich attacks unprofitable.

Description​

The sr-AMM operates on slot windows (single leader rotation—4 slots on Solana, 1 on Ethereum). Within a slot window, swaps impact the pool asymmetrically for buys and sells. When a buy order is executed, the offer on the pool increases in accordance with the xy=k curve. However, the bid price remains constant, instead increasing the amount of liquidity on the bid. Subsequent sells eat into this liquidity, while decreasing the offer price according to xy=k.

At the beginning of each slot window, the state of the sr-AMM is reset to the equivalent xy=k state. By only resetting the bid and offer at the beginning of the slot window, we break the atomicity of the profitable backrun that defines sandwich attacks today.

Example​

Consider the same victim transaction, buying 3 units of liquidity from the sr-AMM. Again, we will express prices in terms of log(price) rather than price. If the same sandwich attack is attempted:

  1. Initially, the AMM offers liquidity at a mid-price of p*, with fee level f. The attacker buys 1 unit of liquidity, pushing the AMM's offer price to p* + 2f while increasing the size on the bid. The trade executes at an average price of p* + 1.5f. 5
  2. The victim transaction is executed, pushing the AMM's offer price to p* + 5f while increasing the size on the bid. The victim's transaction executes at an average price of p* + 3.5f. If the transaction hadn't been frontrun, it would have executed at an average price of p* + 2.5f. 6
  3. The attacker sells 1 unit of liquidity at a price of p* - f, for a loss. 7
  4. The offered price on the pool decreases, while the bid price remains the same with decreasing size. 8
  5. At the end of the slot window, the AMM state resets and the liquidity is normalized. The final mid-price is p* + 3f. 9

Considerations​

  • The sr-AMM retains the monovariant that k (in xy=k) is always increasing after a swap.
  • Compared to the constant product AMM, the sr-AMM strictly increases the net spread or “fee” swappers pay to the pool. The tradeoff between LP and swapper welfare can be navigated by adjusting the minimum spread offered by the pool.
  • This design still supports locked liquidity (with and without withdrawable fees), permissionless pool creation, permissionless liquidity provisioning and deprovisioning, and permissionless trading.
  • Sandwiching is still possible at the slot window boundary. If a leader controls consecutive slot windows, they can include the frontrun and target transaction at the end of the first slot window, then backrun at the beginning of the second slot window.
  • With atomic liquidity provisioning, an attacker can still sandwich high-slippage trades by providing JIT liquidity. This can potentially be mitigated by requiring a liquidity activation period, so liquidity provisioning can’t be bundled with a swap.

Conclusion​

In this piece, we outlined a construction for the sandwich-resistant AMM, an AMM that prevents atomic sandwich attacks at the application layer. We hope adoption of this design will help protect users who suffer from frontrunning attacks on AMMs.

To collaborate with us, please reach out to collaborators@umbraresearch.xyz.

Thanks to Achal Srinivasan for the illustrations, Benedict Brady for feedback on the mechanism, and Alex Nezlobin for the visualization style.