Why DEX Prices Slip: Understanding Slippage, AMM Mechanics, and Sandwich Attacks

DEX Prices Are Dynamic, Not Fixed

In automated‑market‑maker (AMM) DEXes such as Uniswap, the price of a token pair is derived from the constant‑product invariant x * y = k. The pool holds reserves x (e.g., USDC) and y (e.g., ETH). After a swap the invariant must still hold, so any change in one reserve forces a compensating change in the other, causing the price to slide.

AMM Pool Model

When a trader adds Δx USDC and removes Δy ETH, the new reserves satisfy (x+Δx) * (y‑Δy) = k. Solving for Δy gives the marginal price dy/dx = -y/x. Larger trade sizes produce a larger deviation between the quoted price (based on current reserves) and the execution price – this deviation is called slippage.

Slippage and Slippage Tolerance

Slippage : the percentage difference between the quoted price and the actual execution price after a trade.

Slippage tolerance : a user‑defined bound (commonly 0.5 %–1 %) that the DEX UI enforces. If the execution price would exceed the quoted price by more than this percentage, the transaction is automatically reverted.

If a transaction reverts, only the gas used is lost; the input tokens are returned to the user.

How a Sandwich Attack Exploits Slippage Tolerance

Front‑run : An MEV bot monitors the mempool, sees a large pending trade, and calculates the maximum buy amount that raises the pool price to just below the victim’s slippage limit. It submits a higher‑gas transaction that executes before the victim’s trade.

Victim transaction : The victim’s swap now executes at a higher price, but still within the allowed tolerance, so it succeeds.

Back‑run : The bot sells the ETH it bought in step 1 after the victim’s trade, capturing the price difference as profit.

The bot uses the constant‑product formula to predict the pool state after the victim’s swap and to ensure both its own swaps stay inside the victim’s tolerance window.

Implications

The purchase price is bounded only by the user‑defined slippage tolerance, not by a fixed lock. MEV actors exploit this inherent property of AMM design rather than a software bug. Community mitigations such as Flashbots, MEV‑Boost, and private transaction relays aim to reduce the impact on ordinary users.