Skip to content
Financial Context Wiki

Sandwich attack

How a searcher places trades around a pending swap, worsens the user's execution, and extracts value from transaction ordering.

Updated

For educational purposes only; not security or investment advice. Slippage controls and private routing can reduce sandwich exposure but cannot guarantee execution quality, inclusion, finality, or recovery of losses.

Direct answer

A sandwich attack is a harmful form of maximal extractable value in which an attacker places one transaction immediately before a user’s swap and another immediately after it. The first trade moves the pool price against the user, the user’s swap executes at a worse rate, and the final trade unwinds the attacker’s position at the price created partly by the user.

The attack depends on advance visibility or privileged ordering of the user’s intent, enough price impact, and execution limits that still allow the swap to succeed. It is most commonly discussed for automated market maker swaps, but the broader risk is any predictable state change whose ordering lets another party extract value.

How it works

A user signs and broadcasts a swap. If its details reach a public transaction pool or another observable order-flow channel before inclusion, a searcher can decode the assets, size, route, minimum output, and deadline, then simulate possible transaction sequences.

For a buy in an AMM pool, the searcher buys first. That front-run changes the reserves and raises the user’s execution price. The user then receives fewer output tokens than the pre-trade quote, provided the result remains within the user’s minimum-output condition. The searcher sells after the user in a back-run, capturing part of the price movement.

Gross proceeds are not the same as profit. The attacker must cover both swap fees, gas or builder payments, failed attempts, and inventory risk. Competition, other trades, a reverted victim swap, or a changed block order can make the sequence unprofitable; a sandwich is not automatically atomic or guaranteed.

Slippage protection limits the worst accepted output rather than preventing ordering. A very loose tolerance can leave more room for adverse execution, while a very tight tolerance can cause a legitimate swap to revert during volatility. Applications and integrating contracts should enforce a current, user-approved minimum output and an appropriate deadline instead of using zero or a stale hardcoded value.

Private submission, protected order flow, batch auctions, intent-based execution, and order splitting may reduce exposure in some systems. Their protection depends on which intermediaries can see the order, builder coverage, fallback behavior, liquidity, fees, and implementation; labels such as “private” or “MEV protected” are not universal guarantees.

Example

A user submits a visible swap to buy Token B with Token A from an AMM pool. A searcher simulates that the order is large enough to move the pool price and that the user’s minimum output leaves room for the trade to execute after an adverse price move.

The searcher buys Token B first, the user’s swap then buys Token B at the worsened rate, and the searcher sells Token B immediately afterward. The user still receives at least the signed minimum but less than the earlier quote; the searcher keeps only what remains after swap fees, ordering payments, and execution costs.

Risks

For the user, the direct harm is worse execution and higher effective slippage. The swap may also revert after consuming gas where the chain and transaction design charge for failed execution. Thin liquidity, large visible orders, loose limits, volatile markets, and predictable routes can increase exposure, but no single threshold proves that an attack will occur.

Mitigations introduce tradeoffs. Smaller orders can pay more total fees or leak a repeated strategy; tight limits can increase reverts; private routes add trust, censorship, logging, and fallback questions; and protected interfaces may cover only selected chains or routes. Verify the signed minimum output, deadline, route, endpoint policy, receipt, and required finality rather than relying on a protection badge.

Common misconceptions

  • Every adverse price move is a sandwich attack. Ordinary price impact, market movement, routing changes, and arbitrage can also make execution differ from a quote; transaction ordering evidence is needed to attribute a sandwich.
  • The attacker simply steals tokens from the wallet. A typical sandwich changes pool state around an authorized swap; it does not require the attacker’s transaction to transfer assets directly from the user’s wallet.
  • Setting any slippage tolerance prevents the attack. The minimum output caps accepted deterioration, but a searcher may optimize the sandwich so the swap succeeds close to that boundary.
  • Private submission eliminates MEV. It can hide an order from the public pool, yet RPC operators, relays, builders, solvers, or a public fallback may still observe or influence it.
  • A successful receipt proves fair execution. Success proves that contract conditions passed, not that the user received the best available price or avoided harmful ordering.

Sources

Navigation

Search the wiki...