A trader submits a swap on a decentralized exchange, sets slippage tolerance to 1%, and watches the trade execute at a price noticeably worse than expected. No news event caused it. No exchange outage. The price simply moved against them in the seconds between submitting and confirming - and it moved because someone made it move, on purpose, using their own transaction as the trigger.

This is what a sandwich attack looks like from the inside. It's not a hack, not a bug, and not theft in the traditional sense. It's a mechanical exploitation of how public blockchains order transactions, and it happens constantly, quietly, across nearly every DEX trade above a certain size.

Key Takeaways

  • MEV sandwich attacks exploit the gap between when you sign a transaction and when it's actually confirmed on-chain
  • Slippage tolerance settings define the maximum extractable value a bot can take from your trade
  • Public mempools let anyone see pending transactions before they execute, turning order flow into a target
  • The cost isn't random - it scales directly with trade size, pool liquidity, and slippage tolerance

The Common Misunderstanding

Most traders think of slippage as a natural cost of trading in shallow markets - the price moves a little because the order book or liquidity pool doesn't have infinite depth. That part is true. But most traders assume this slippage is passive: a byproduct of their own trade size interacting with available liquidity.

What's missed is that slippage tolerance isn't just a buffer against normal price movement. On a public blockchain, it's a visible, exploitable number. When a trader sets a 1% slippage tolerance, they're broadcasting exactly how much worse their execution price can get before the transaction reverts. That number is not private. It sits in the public mempool for anyone - or any bot - to read before the trade confirms.

The intuitive explanation is: "the market moved against me." The more accurate one is: "someone read my pending trade and moved the market against me, within the exact bounds I told them I'd tolerate."

One observation a week on liquidity, flow, and structure. 4 minutes. No price calls.

Subscribe →

What Actually Happens

Maximal extractable value, or MEV, refers to profit that can be extracted by choosing which transactions get included in a block and in what order. On most EVM-compatible chains, pending transactions sit in a public mempool before a validator finalizes them. This visibility is what makes sandwich attacks possible.

The mechanics work like this:

  1. A trader submits a swap - buying a token on a decentralized exchange.
  2. A bot monitoring the mempool sees the pending transaction and calculates how much the trade will move the pool's price.
  3. The bot submits its own buy order with a higher gas fee, ensuring it's processed first.
  4. This front-run buy pushes the price up before the original trade executes.
  5. The original trade now executes at a worse price - still within its slippage tolerance, so it doesn't revert.
  6. The bot immediately sells, back-running the original trade, capturing the price difference it engineered.

The trader's transaction is "sandwiched" between the bot's buy and sell. Nothing about this requires hacking, insider access, or breaking any protocol rule. It's transaction ordering, exploited by design, because the mempool is public and slippage tolerance defines the exact ceiling of what can be extracted.

This is fundamentally different from the kind of slippage described in what slippage really costs, where price impact comes from the trade's own size relative to pool depth. A sandwich attack adds an artificial, engineered price movement on top of that natural slippage - value transferred directly from the trader to the bot operator.

Example from Crypto Markets

Consider a trader swapping ETH for a mid-cap altcoin on a decentralized exchange, with a pool holding moderate liquidity. They set 1% slippage tolerance - a reasonable-looking number for a token that isn't paper-thin.

A bot detects the pending swap in the mempool. Based on the trade size and the pool's liquidity curve, it calculates that pushing the price up by just under 1% before the trade executes will maximize extraction without triggering a revert. It front-runs with a buy order at a higher gas price, the original trade executes at the worse price, and the bot immediately sells back into the pool, capturing the spread.

The trader sees their swap confirm successfully. No error, no warning. The only signal is a fill price slightly worse than the quote they saw before submitting - easy to write off as "normal market movement," even though it was neither normal nor unavoidable. Multiply this across thousands of trades a day, and MEV extraction becomes a persistent, measurable tax on DeFi activity, distinct from - and additive to - the liquidity-driven slippage that would exist anyway.

What Traders Can Learn

The core insight isn't about avoiding DeFi trading - it's about understanding that pending transactions on a public blockchain are not private intentions. They are visible order flow, and visible order flow gets front-run, in both traditional and decentralized markets. The difference on-chain is transparency: anyone can watch the mempool, calculate the exploit, and act on it programmatically.

Slippage tolerance is often treated as a safety setting - a way to prevent a trade from executing too far from the current price. In practice, it also defines the size of the extraction window available to anyone watching. Tighter tolerance reduces that window at the cost of more failed transactions. This is the same structural tradeoff traders navigate in collateral ratios and protocol solvency - every parameter that protects against one risk creates exposure somewhere else.

Trade size also matters more than most traders assume. Smaller trades in deep pools are rarely worth sandwiching - the gas cost of the attack can exceed the extractable value. Larger trades in shallower pools are the primary targets, which is why the same trade can be MEV-exposed on one pool and effectively ignored on another.

FAQ

Can MEV sandwich attacks happen on centralized exchanges?

No. Centralized exchanges match orders internally and don't broadcast pending trades to a public mempool before execution, which removes the visibility that makes sandwich attacks possible. MEV is specific to public blockchains where transaction ordering happens in the open.

Does lowering slippage tolerance stop sandwich attacks?

It reduces the maximum value extractable per attack, since the bot can only push the price as far as the tolerance allows before the trade reverts. It doesn't eliminate the risk entirely, and setting tolerance too low increases the chance the trade fails outright during normal volatility.

Are MEV bots illegal?

In most jurisdictions, no clear regulation classifies MEV extraction as illegal, since it operates within the public rules of blockchain transaction ordering rather than exploiting a security flaw. This is an active and unsettled area of crypto market structure discussion.

How do private transaction relays help against MEV?

Private relays submit transactions directly to block builders instead of the public mempool, meaning bots never see the pending trade before it's included in a block. This removes the visibility window that sandwich attacks depend on, though it requires using a relay service rather than the default public mempool path.

Related Concepts

Conclusion

MEV sandwich attacks aren't an edge case or a rare exploit - they're a structural consequence of public transaction ordering combined with visible slippage tolerance. Every pending trade on a public mempool is, in effect, an announcement of intent, and that visibility has a price. Understanding this doesn't require abandoning DeFi trading, but it does require recognizing that on-chain, your transaction is visible before it's final.