Sandwich Attacks

Learning objectives

• Describe the front-run, victim and back-run structure.
• Understand how trade size, pool depth and slippage tolerance affect profitability.
• Evaluate evidence and mitigation without overclaiming.

How a sandwich works

In an AMM, a sufficiently large swap moves the pool’s marginal price. When a pending user transaction is visible before inclusion, an attacker can estimate the price movement and the user’s minimum-received or maximum-input constraint.

For a large buy, the attacker may buy first, pushing the pool price higher. The victim then executes at a worse price but still within its slippage tolerance. The attacker sells after the victim’s buy has pushed the pool further, attempting to capture the difference net of gas, fees and competition.

The attack depends on economics. Deep liquidity reduces price impact for a given order size. Tight slippage reduces how much adverse state change the user will accept. High gas and competition between searchers also reduce attacker profit. Thin pools and oversized swaps create more room.

Slippage tolerance should therefore be treated as a risk limit, not a convenience setting. Setting it far wider than expected market volatility and route impact can transfer unnecessary execution discretion to adversarial actors. Setting it too tight, however, can cause repeated reverts and wasted gas.

Detection should reconstruct the pool state and transaction order. The analyst looks for an attacker buy before the victim, a victim swap in the same direction, and an attacker unwind after it, often within the same block or bundle. Similar addresses, token amounts, profits and gas bidding can support attribution.

Ordinary arbitrage should not be mislabeled. A trader can independently buy before a user or arbitrage the post-trade pool price without deliberately manipulating the user’s execution. The sandwich label requires evidence that the surrounding trades were strategically constructed around the victim.

Mitigation includes routing to deeper pools, splitting size when economically sensible, explicit limit-style constraints, protected/private submission, batch auctions and intent-based execution. Each method has trade-offs. Private submission changes who sees the transaction; batch systems change price discovery; splitting can increase fees and signalling.

Worked example

Practical mitigation workflow

1. Estimate expected price impact before signing the swap.
2. Set slippage only wide enough for legitimate execution uncertainty.
3. Compare deeper routes, aggregators and protected execution.
4. For material trades, inspect surrounding transactions after execution.
5. Track realised execution against the pre-trade quote and route alternatives.

Common mistakes

• Using extremely loose slippage simply to avoid reverts.
• Calling every bad DEX fill a sandwich.
• Assuming private routing has no trust or inclusion trade-offs.
• Ignoring pool depth when executing large size.
• Looking only at token price rather than reconstructing transaction order and pool state.

Knowledge checkpoint

1. What are the three transactions in a classic sandwich?
2. Why does pool depth affect attacker economics?
3. How does slippage tolerance create room for extraction?
4. What evidence distinguishes a sandwich from ordinary arbitrage?

FAQs

Summary

Sandwich attacks exploit visible, market-moving intent. The practical defence is not mythology about “MEV bots”, but disciplined control of size, pool depth, slippage and order-flow exposure, followed by transaction-level analysis when outcomes are suspicious.