DeFi

Why Your Swap Filled Worse Than the Quote: MEV, Sandwiches and Slippage

By NorwegianSpark Editorial — written with AI assistance and reviewed by the NorwegianSpark SA editorial team | Last updated: 2026-08-19

A cluster of pale blue blocks joined by glowing lines

This article contains affiliate links. We may earn a commission at no extra cost to you. Full disclosure

Not financial advice. Crypto assets carry risk and on-chain transactions are irreversible. Do your own research.

You set up a swap. The interface quotes a rate. You confirm, wait, and the transaction succeeds — at a noticeably worse price than the quote.

The instinct is to blame the interface. The interface was telling the truth when it quoted. What happened in between is that your trade sat in public, visible to anyone watching, before it executed.

The mempool is a public queue

On most chains, a transaction is not executed the instant you sign it. It is broadcast to a pool of pending transactions — the mempool — where it waits for a validator to include it in a block.

While it waits, it is public. Anyone can read it: what you are swapping, how much, and the slippage tolerance you set.

That visibility is the whole problem. A pending trade is an announcement of a price move that has not happened yet, and there is money in acting on it first.

MEV, and the specific form that costs you

The general name for value extracted by controlling what goes into a block and in what order is maximal extractable value. Some of it is harmless or even useful — arbitrage between venues tightens prices. One form is directly at your expense.

Ethereum.org's developer documentation describes it plainly (ethereum.org MEV docs). In a sandwich, a searcher watches the mempool for large trades on a decentralised exchange. Seeing one, they calculate the price effect it will have, "execute an optimal buy order immediately before the large trade, buying cheaply, then execute a sell order immediately after the large trade, selling it for the higher price caused by the large order".

Your trade is the filling. Their buy pushes the price up before you trade; you buy at that worse price; their sell takes the difference. The chain worked exactly as designed, and the value moved from you to them.

The same documentation describes the related, more general behaviour: a frontrunner monitoring the mempool can take somebody else's profitable pending transaction, "submit the modified transaction with the replaced address and a higher gas price", and take the opportunity for themselves.

Where the slippage setting fits

The slippage tolerance in a swap interface is the maximum adverse price move you will accept before the transaction reverts instead of executing.

It is a genuine trade-off, and both ends of it are bad in different ways.

Slippage toleranceWhat happens
Too tightThe trade reverts in normal volatility. You still pay a fee for a failed transaction
Too looseYou have published exactly how much you are willing to lose, and a sandwich can take all of it

That second row is the part people miss. A high slippage tolerance is not just accepting a worse price if the market moves. It is a public statement of the maximum a searcher can extract while still having your transaction succeed — and a rational searcher will take close to that maximum.

Setting 20% tolerance on an illiquid token to make the trade "go through" is not solving a problem. It is authorising the loss.

What actually reduces the exposure

- Trade in liquid pools. The price effect of your trade is what makes it worth sandwiching. In a deep pool a normal-sized trade barely moves the price, so there is little to extract. In a thin one, the same trade is an opportunity.

  • Break large trades up. Several smaller trades move the price less individually, though each pays a fee.

  • Use a private submission route where your wallet offers one. Flashbots, described in the same ethereum.org documentation, exists so transactions can be submitted to validators "without revealing them to the public mempool", which "prevents transactions from being frontrun". Several wallets and interfaces now offer a private or protected RPC as a setting. This is the single most effective measure available to an ordinary user.

  • Set slippage deliberately, low, and per trade. Not once, globally, at whatever makes failures stop.

  • Watch the fee environment. Sandwiching is only profitable above the searcher's costs, so it concentrates on larger trades — and your own fee choices interact with it. See gas fees explained.

    Why the fee you pay is part of the same system

    There is a detail in the ethereum.org documentation that explains a lot about how blockspace is actually priced. For highly competitive opportunities such as arbitrage between decentralised exchanges, searchers "may have to pay 90% or even more of their total MEV revenue in gas fees to the validator", because the only way to guarantee their transaction runs is to submit it with the highest gas price.

    In other words, most of the extracted value ends up with whoever orders the block, not with the searcher. That is worth knowing because it explains why this behaviour is stable rather than temporary: it is not a few bad actors, it is a competitive market for transaction ordering, and it is not going away because someone disapproves.

    Frequently Asked Questions

    Is a sandwich attack theft?

    Not in any legal sense. Every transaction involved is an ordinary, valid trade submitted by someone entitled to submit it. The loss to you is real, and the mechanism is the public mempool and block ordering working as designed rather than anyone breaking a rule.

    Does this happen on every chain?

    The specifics depend on how a chain handles pending transactions and who orders blocks, so the exposure varies. The underlying condition — a visible queue plus discretion over ordering — is common across public chains, so the general risk should be assumed rather than dismissed.

    Will a lower slippage setting stop it?

    It caps it. A sandwich can only take what your tolerance permits before the transaction reverts, so a tight setting bounds the loss. It also makes failed transactions more likely in a volatile moment, which costs fees, so the setting is a genuine trade-off rather than a free fix.

    Are centralised exchanges affected?

    Not by this mechanism, because there is no public mempool and no on-chain ordering — the exchange matches internally. That removes MEV and replaces it with counterparty risk in the exchange itself, which is a different problem covered in what happens if a crypto exchange collapses.

    The takeaway

    Your swap did not fill badly because the interface lied. It filled badly because it was visible before it happened, and the difference between the quote and the fill went to whoever was watching.

    Deep pools, deliberate slippage settings and a private submission route remove most of it. Understanding that a pending transaction is a public announcement removes the surprise.

    Sources: the Ethereum developer documentation on MEV (ethereum.org), read 19 August 2026.

  • Content on AICryptoCoin is for informational purposes only and does not constitute financial advice. Always do your own research and consult a qualified financial advisor before making investment decisions.