How MEV changes the price you actually get on a swap
The quote your wallet shows isn't always the fill you get. Here's how MEV bots sandwich swaps and what to check before you trade.
You open your wallet, swap 5,000 USDC for ETH, see a quote, hit confirm. Two blocks later your transaction lands and you got noticeably less ETH than the quote promised. That gap is often MEV, not slippage in the normal sense.
What actually happens between the quote and the fill
Your swap sits in a public mempool or a private order flow channel for a few hundred milliseconds to a few seconds before a validator includes it. During that window, bots watch for large trades and can insert their own transactions before and after yours in the same block.
This is called a sandwich attack, and it works like this:
- Bot sees your 5,000 USDC to ETH swap pending
- Bot buys ETH first, pushing the pool price up
- Your swap executes at the now-worse price
- Bot immediately sells the ETH back, pocketing the difference
- You absorb the price impact of two trades instead of one
The bot doesn't touch your funds directly. It just trades around you, and the AMM's math does the rest.
How much does this actually cost you
On a $5,000 swap with 0.5% slippage tolerance, a sandwich can extract $15 to $40 depending on pool depth and how aggressive the bot is. On six-figure trades in thin pools, extraction has run into the thousands.
Flashbots' MEV-Explore data has tracked hundreds of millions of dollars in extracted value since 2020, with sandwich attacks making up a large share of swap-related MEV specifically.
The mechanism scales with three things:
- Trade size relative to pool liquidity, bigger trades move price more, leaving more room to extract
- Slippage tolerance you set, a wider tolerance gives the bot more room to work with
- Pool depth, thin pools on newer tokens get sandwiched harder than ETH/USDC on Uniswap
Why doesn't the protocol just stop this
AMMs execute trades based on whatever the pool price is at the moment of execution, not the moment you clicked confirm. That's the whole design. There's no built-in way for a pool to know your transaction was "supposed" to trade at yesterday's price.
Block builders and validators also have no obligation to protect you. Under proposer-builder separation, the highest-paying bundle of transactions wins the block, and a sandwich bundle can pay more in priority fees than a bot loses to gas, because the sandwich profit funds the fee.
Private RPCs and MEV-protected routes exist precisely because the public path has no protection layer.
What should you check before you swap
A few concrete things change your exposure meaningfully:
- Set slippage tolerance tight, 0.1 to 0.3% on liquid pairs, not the default 0.5-1% many wallets ship with
- Use a private transaction route, MEV Blocker, Flashbots Protect RPC, or your wallet's built-in private send option, so your swap skips the public mempool entirely
- Check pool depth before a large trade, if your swap is more than 1-2% of pool liquidity, split it into smaller trades or use an aggregator that routes across pools
- Compare your quoted price to the actual fill after the transaction confirms, on Etherscan the swap event log shows exact amounts in and out
- On CEX-adjacent trades, ask whether the DEX aggregator you're using already has MEV protection baked in, most major ones do now by default
None of this eliminates the general price impact of trading against an AMM curve. It removes the extra tax that comes specifically from someone else trading around your pending transaction. The difference between the two shows up directly in what lands in your wallet.
