What is a sandwich attack, and how does it differ from what people typically think of as slippage?
A sandwich attack refers to an attacker exploiting the characteristic that on-chain transaction information is publicly visible — upon detecting a large trade about to execute, the attacker front-runs by inserting a same-direction transaction of their own before it, and once the victim's trade pushes the price up (or down), immediately follows with a second, opposite-direction transaction to lock in profit. Because the victim's transaction ends up sandwiched right in the middle of the attacker's two transactions, resembling a sandwich's filling, this is where the name comes from.
The key difference from what's typically thought of as slippage lies in 'whether there's deliberate human manipulation involved': normal slippage is a natural mathematical result of an AMM's pricing mechanism — even with no attacker present at all, a trade of any size would inherently produce some degree of slippage due to the shift in the pool's ratio; a sandwich attack, by contrast, is an attacker deliberately exploiting the price impact your trade would cause, actively inserting transactions to amplify their own profit, making the actual slippage magnitude you bear far more severe than pure natural slippage. A sandwich attack could be described as 'an attack actively launched by exploiting the slippage mechanism,' rather than slippage itself.
Why does a sandwich attack happen, and what's the technical foundation that lets attackers execute it continuously?
A sandwich attack's existence stems from two native structural characteristics of blockchains: first, before a transaction gets formally packaged into a block, it usually briefly sits in the public mempool (waiting area), and anyone can theoretically see the content of these unconfirmed transactions; second, a block producer holds considerable discretion over 'what order these visible transactions get placed into a block' — as long as someone's willing to pay a higher priority fee, in theory they can get their transaction confirmed ahead of someone else's. Combining these two characteristics means an attacker just needs to continuously monitor the mempool — once they spot a profitable large trade, they can pay a sufficiently high priority fee to ensure their two transactions land respectively before and after the victim's.
This entire attack process heavily relies on automated programs to execute, since the process of detecting a transaction, calculating the profit opportunity, submitting transactions, and ensuring the correct order all usually needs to complete within an extremely short window (even before being packaged into the same block) — manual operation can barely keep up with this speed, which is also why sandwich attacks in practice are almost entirely executed by dedicated MEV bots.
How does a sandwich attack actually get executed, and what does one complete attack flow look like?
A typical sandwich attack flow involves several steps:
This entire flow carries almost no directional risk for the attacker — since the buy and sell actions complete within an extremely short window, the attacker bears very little price volatility risk, with the main cost being just trading fees and priority fees.
What's the practical impact of a sandwich attack on everyday users, and how can they lower their chance of being attacked?
For users, a sandwich attack's direct impact is an actual execution price worse than expected — this extra loss comes entirely from the attacker's deliberate operation, not natural market fluctuation. A few concrete ways to lower the chance of being attacked: tighten your slippage tolerance setting, since the profit space an attacker can extract is directly bounded by your set slippage tolerance range — the tighter the tolerance, the smaller the price gap an attacker can operate within, potentially small enough that, after subtracting the attacker's own gas cost, it's no longer profitable at all; use a transaction routing service with MEV protection, which typically routes through a private transaction pool, keeping your transaction out of the public mempool before it's formally packaged, so the attacker can't see your trade intent at all and has no way to launch the attack; split a large trade into several smaller ones executed in batches, reducing any single trade's price impact magnitude, making each one's potential profit less attractive to an attacker.
If you want to confirm whether a past trade of yours ever suffered a sandwich attack, you can use a blockchain explorer to look at the block that trade is in, examining the other transactions immediately before and after yours — if you see one trade in the same direction as yours occurring right before, and another in the opposite direction right after, both from the same address, that's the classic sandwich attack pattern.
In March 2025, a trader executed a stablecoin swap worth roughly $220,764 in Uniswap V3's USDC-USDT pool. An MEV bot detected the trade within seconds, temporarily withdrew the pool's USDC liquidity to force the trade through at an extremely unfavorable price, then restored the liquidity immediately afterward. The attack cost the trader roughly $215,500 — a loss of almost 98%. This incident sparked widespread discussion because the affected pair was a theoretically low-volatility stablecoin pool, yet the loss ratio was still nearly total.
As a security risk term, there's no positive trade-off to speak of — a sandwich attack represents pure loss for the victim. The only discussable trade-off: a blockchain's publicly transparent transaction information and market-biddable ordering power are simultaneously a decentralized system's advantages and the root cause enabling sandwich attacks to exist — an inevitable byproduct of the entire architecture's design, not a variable a user can unilaterally change. What a user can do mainly involves tightening slippage tolerance and using MEV-protected routing to lower their chance of being targeted.