A sandwich attack is a form of maximal extractable value (MEV) in which a searcher places one transaction before a user’s pending decentralized-exchange swap and another after it. The first trade can move the pool price against the user; the user’s swap then executes at a worse rate within its permitted slippage; the final trade attempts to capture value from the resulting price movement. The name describes the ordering, not a guaranteed profit.
A three-transaction sequence
In a common example, a trader submits a buy through a public transaction pool. A searcher sees the pending order and buys the same asset first. That trade changes the pool’s reserves and price. The user’s order executes next, receiving fewer tokens than the earlier quote suggested, but still within the transaction’s minimum-output limit. The searcher then sells after the user’s trade and tries to keep the difference after pool fees, network fees, and competition.
Transaction ordering does not always work this way. The pending transaction may be private, a block builder may use a different ordering, the user’s order may revert, or the price may move before inclusion. A sandwich is confirmed only by examining the transaction sequence and trade amounts; a disappointing quote alone does not prove one occurred.
Why slippage and pool depth matter
An automated market maker prices a swap against the pool’s available reserves. A large trade relative to those reserves causes price impact. If the user permits a wide slippage tolerance, an order may still execute after an intervening trade moves the price. That can create room for a searcher to extract value. The searcher must still estimate the pool, fee, gas, and ordering conditions, and its trades can lose money if the market moves unexpectedly.
Trading volume over a full day is not the same as executable depth at the moment of a swap. A pool can report substantial volume while being shallow at the specific price range or time a user trades. Price impact, normal market movement, route choice, and MEV can all contribute to a difference between a quote and final output.
Reducing exposure
A tighter slippage limit reduces how far execution can move from the submitted quote, but it can also make a legitimate trade revert during volatility. Using a deeper pool may reduce price impact. Wallets or interfaces may offer private transaction routing or intent-based execution that reduces exposure to a public pending order, although availability, trust assumptions, and supported chains vary. No setting guarantees that every form of MEV disappears.
Before confirming a swap, review the route, expected output, minimum output, fees, and the effect of changing slippage. If the final result is unexpectedly poor, inspect the transaction trace and pool state before attributing the difference to a sandwich attack.
Social Media Sentiment
In a May 2026 r/ethereum thread, a trader asked why a mid-cap swap executed much worse than expected. Replies discussed pool depth, price impact, slippage, and a possible sandwich, but the post did not provide a transaction trace that could confirm the cause. The thread illustrates user concern and disagreement, not a measured rate of attacks. Read the referenced Reddit discussion.
Last updated: 2026-10
Related Terms
See Also
- What Is MEV — And Why Every Ethereum Transaction Is a Game
- How Do Crypto Bridges Work — And Why Are They Such a Hack Target?
- Why Smart Contract Audits Fail
- Explore crypto with ChangeNOW
Sources
- Ethereum.org — Maximal Extractable Value — Explains sandwich ordering, its effect on users, and the broader trade-offs of MEV.
- Uniswap Labs — What Is Maximal Extractable Value? — Explains how transaction ordering, front-running, sandwiching, and back-running can affect swap execution.
- Uniswap Blog — How to Secure Your Swaps from MEV Attacks — Describes private routing, intent-based execution, slippage settings, and their practical limits.