Sandwich Attacks in Crypto and Slippage Protection

A sandwich attack in crypto wraps your swap between two of the attacker's own trades, so you buy at a worse price and they pocket the difference.

At the time of recording (2023), the address known as jaredfromsubway.eth had extracted tens of millions of dollars this way from thousands of users across Ethereum.

This guide covers how sandwich attacks work, how slippage protection defends against them, and a real finding. It also gives a framework for finding these bugs and dissects a live sandwich.

A Special Case of Front-Running

Sandwich attacks are a special case of front-running, one where front-running a transaction is particularly profitable for the attacker.

If front-running is new to you, start with front-running in smart contracts. To see why sandwiches pay so well, start with an AMM price curve.

How Swaps Move the Price

Picture an x * y = k curve, the constant product model from Uniswap V2. Our constant product AMM guide covers it in depth.

Token0 is on the x-axis and token1 is on the y-axis. Each point on the curve is a pair of pool reserves.

Far to the right, the pool holds a huge supply of token0 and little token1. Far up and to the left, it holds lots of token1 and little token0.

An abundant token is cheap and a scarce one is precious. So the further up and to the left the point sits, the higher the price of token0.

Now swap 100 token1 for token0. You add token1 to the pool, so the y value rises, and you take token0 out, so the x value falls.

The point moves up and to the left. The price of token0 just went up, and your own swap moved it.

The Mechanics of a Sandwich Attack

Say you want to buy token0 at the current price, P0. Your swap sits in the mempool, waiting to be included in a block.

An attacker sees it and swaps the same direction first, moving the price up to P1.

When your swap executes, you buy at P1 instead of P0. You put in more token1 for the same token0, and your swap pushes the price higher still, to P2.

The attacker bought at P0. They sell immediately at the higher price, bringing it back down to around where it started.

That difference is close to risk-free profit, taken straight from your execution.

That is the crux: a swap moves the price. Get in directly before someone's swap, let them push the price further, then sell into it.

Slippage Protection

Users protect themselves with a slippage limit. Before sending a swap, you note the current price, P0, and set how much worse a price you will accept.

Allow 1%, for example, and the swap only goes through at up to 1.01 times P0.

If someone front-runs you and pushes the price past that limit, your swap reverts instead of executing at a terrible price.

You still need some margin. With none, any tiny swap ahead of yours would make your transaction fail.

A Real Finding: Hard-Coded Slippage

A high severity finding from a Guardian contest, submitted by a solo researcher, shows what this looks like in practice.

When swapping through a router, the user is responsible for giving the minimum amount of tokens they will accept. That is how slippage tolerance protects against sudden market moves.

In this protocol, the minimum was hard-coded to one, which allows 99%-plus slippage on large amounts.

An attacker can push the price as far as they like and the swap still executes. Users could lose most of their dividend funds when the pool was unbalanced.

The swap logic, simplified, looked like this:

function swapTokensForEth(uint256 tokenAmount) internal {
    address[] memory path = new address[](2);
    path[0] = address(token);
    path[1] = router.WETH();
    token.approve(address(router), tokenAmount);
    router.swapExactTokensForETH(
        tokenAmount,
        1, // amountOutMin: one wei, so no slippage protection
        path,
        address(this),
        block.timestamp
    );
}

A minimum output of one wei of ether is, for all intents and purposes, zero. The swap accepts nearly any output, so nearly all of its value can be extracted.

The recommendation was to take slippage tolerance as a parameter instead of hard-coding it.

A Framework for Finding Sandwich Bugs

1. Find the swaps. Does the code you are building or auditing swap on Uniswap V3 or any other AMM? Then think about slippage protection.
2. Inspect every swap call. Check the minimum output amount, or whatever slippage setting it uses. It should be configurable and reasonable.
3. Check the tolerance. Anything above about 100 basis points is probably too much leeway. It depends on the amount swapped, so the right limit is protocol specific.
4. Check the AMM itself. When auditing an AMM, make sure it exposes appropriate slippage controls to users.
5. Fill the gaps. Where slippage controls are missing or not sophisticated enough, implement them.

A Live Sandwich: jaredfromsubway.eth

Open jaredfromsubway.eth on Etherscan and transactions pour in constantly. At the time of recording, a whole page had filled up within three minutes.

Take two of the bot's transactions with the same timestamp, one on each side of a victim's swap. Both trade two small-cap tokens against WETH.

The Front Slice

In the first transaction, the bot sold about 633 billion units of one token for about 0.49 WETH.

It also sold about 85.596 million units of the second token for about 1.229 WETH. Then the victim's swap executed in between, moving prices further.

The Back Slice

In the second transaction, the bot put in about 0.47 WETH and got back about 634 billion of the first token, more than it sold.

It put in about 1.22 WETH and got back about 85.603 million of the second token, again more than it sold.

The victim here was selling, so the bot sold first and bought back after: the mirror image of the example above.

It did not even need all its WETH to buy back. It ended with more of both tokens and more WETH than it started with.

That value came from the victim in the middle, and from however loose their slippage setting was.

The Takeaway

Always set your slippage when you swap. When you build or audit, make sure every swap path lets users do the same.

Front-running a value change is a broader pattern. See DeFi reward accounting vulnerabilities for sandwiched reward compounds, and oracle manipulation attacks for swaps that move protocol prices.

How Guardian Helps

Guardian's smart contract audits put senior researchers on protocol logic and integrations, including every swap path, with exploit-driven review and proof-of-concept depth.

See smart contract audits or Vanguard.

Frequently Asked Questions

What is a sandwich attack in crypto?

A front-running attack on an AMM swap. The attacker trades just before your swap to move the price. Your swap fills at the worse price and moves it further, and the attacker trades back right after.

How does slippage protection stop sandwich attacks?

You set the worst price, or minimum output, you will accept, such as 1% from the current price. If a front-runner pushes the price past that limit, your swap reverts instead of executing.

What slippage tolerance is too high?

Anything above about 100 basis points is probably too much leeway, though the right limit depends on the amount swapped and the protocol. A hard-coded minimum output of one wei means no protection at all.

How do auditors find sandwich vulnerabilities?

Find every swap on an AMM, inspect its minimum output or slippage setting, and confirm it is configurable and reasonable. When auditing an AMM itself, confirm it exposes slippage controls to users.

Sources

• Owen Thurm (YouTube): Sandwich Attacks | Web3 Exploits 101 (September 2023)