~ / content / mev-sandwiches-front-running.html
Advanced Published 2026-04-28 Β· 11 min read Β· DEX mechanics

MEV, Sandwiches, and Front-Running for Mortals

MEV stands for Maximal Extractable Value β€” the profit a block producer can make by reordering, including, or excluding transactions in their block. To you, that boils down to one thing: a bot can see your pending swap and trade in front of it. Here is when that matters and how to stop it.

The mempool is not private

When you sign a swap, your wallet broadcasts the signed transaction to a public mempool β€” a holding area where pending transactions wait to be picked into a block. On Ethereum, BSC, Base, and most EVM chains, the default mempool is fully public. Anyone running a node, including a bot watching for profitable patterns, can see every pending transaction including yours.

That visibility is the foundation of MEV. A searcher (the bot) reads your transaction, simulates it, and asks: "if I place a transaction before this one, can I profit?" If yes, they pay the validator a tip to order their transaction first. The validator gets paid, the searcher gets paid, you absorb the cost.

Anatomy of a sandwich

The classic MEV attack on retail is the sandwich. It works only when you're swapping in a pool where your trade size is large enough to move price meaningfully β€” usually 0.5%+ of pool depth. Three transactions, all in the same block:

1. FRONT-RUN bot buys ahead pushes price up size: matched to your slippage cap 2. YOUR SWAP executes at inflated price up to your max slippage tolerance 3. BACK-RUN bot sells pockets spread profit = your excess slippage all three transactions in the same block
A sandwich attack. Profit = your slippage tolerance minus gas.

The bot's profit is bounded by your slippage tolerance. If you set 0.5% on a major pair, the bot can extract at most 0.5% from your trade. If you set 5% on a memecoin entry, the bot can extract up to 5%. This is why slippage tolerance is not free β€” it caps your worst-case execution but it also caps the bot's best-case extraction. Setting it lower hurts the bot first.

When you are actually a target

Not every retail swap gets sandwiched. Bots have minimum-viable-profit thresholds; a $200 swap on a major pair is rarely worth the gas. Here is when you should expect to be sandwiched:

Trade contextSandwich risk
$50–$500 on Ethereum mainnet major pairLow β€” profit doesn't beat gas
$500–$5,000 on a thin-liquidity altcoinHigh β€” you are the ideal target
$1,000+ on Base / Arbitrum / OptimismMedium β€” cheap gas raises the bot's hit rate
Any size on a brand-new pool (under 24h old)High β€” sniper bots are camped on every new pool
Solana trades through JupiterLow–medium β€” Jito bundles + Jupiter routing limit exposure
BSC trades on PancakeSwapHigh β€” the chain's mempool is heavily watched

You can confirm after the fact. EigenPhi and libMEV let you paste a transaction hash and see whether it was sandwiched, by whom, and for how much. Look at any failed-to-deliver swap from the last week and check.

Mitigations that actually work

1. Use a private RPC / private mempool

The single biggest mitigation. Submit your transaction directly to a block builder bypassing the public mempool. Searchers literally cannot see it until it's already on-chain.

# MetaMask custom network β€” Flashbots Protect
Network name: Ethereum (Flashbots)
RPC URL:      https://rpc.flashbots.net
Chain ID:     1
Symbol:       ETH

2. Set realistic slippage tolerance

Cap the bot's profit by capping your tolerance. On a major pair, anything above 0.5% is leaving money on the table. See the slippage math piece for the full ladder.

3. Split big trades across time and pools

A single $20k buy is a sandwich magnet. Four $5k buys spaced 2 minutes apart, routed through different pools, are individually below most bots' threshold and collectively land at a better average price. Aggregators do route-splitting automatically; time-splitting requires a TWAP / DCA mode (Jupiter has it built in; on EVM use 1inch Fusion+ or CoW Swap).

4. Use intent-based / batch-auction DEXs where available

CoW Swap, UniswapX, and 1inch Fusion don't broadcast a swap to the public mempool. They post your intent to a sealed auction, where solvers bid to fill it. The execution happens atomically with no front-runnable order. Pure-intent DEXs are functionally MEV-resistant by design.

5. Know which chains are exposed

L2s with centralized sequencers (Base, Arbitrum, Optimism, zkSync) currently have private mempools by default β€” sandwiches require collusion with the sequencer, which Coinbase / Offchain Labs / OP Labs publicly commit not to do. That changes when sequencers decentralize. Solana's leader-rotation model + Jito bundles produce a different threat surface; vanilla front-running is rare but bundle-stuffing exists.

Failed-transaction MEV β€” the silent tax

Even if you aren't sandwiched, you can pay MEV through transaction failure. A bot front-runs your buy with a buy of its own, eating the price impact you would have caused. Your transaction reverts because the price moved beyond your slippage tolerance. You pay gas for nothing; the bot exits with the price-impact profit minus a small back-run.

This pattern is most common on hot new launches. On a token that just deployed, half the failed transactions you see in the explorer are not "low slippage" β€” they're MEV-induced reverts. Mitigation is the same: private RPC + realistic tolerance.

Reading the explorer If your tx failed with "INSUFFICIENT_OUTPUT_AMOUNT" / "Slippage exceeded" / Solana 0x1771, check the block. If a known MEV bot landed a buy + sell of the same token in the same block, you were not unlucky β€” you were a target. Switch to a private RPC and try again.

The honest summary

MEV isn't going away. The blockchain you are trading on has a finite block space, and that block space is contested by professional searchers with hundred-millisecond infrastructure. As retail you are not racing them β€” you are opting out of the race by routing through systems that don't expose your trade to them.

If you do nothing else, configure Flashbots Protect on EVM and trade through Jupiter with bundles on Solana. That single change captures most of the practical mitigation. The rest is sizing discipline.

Not financial advice. MEV mitigation tooling changes rapidly. RPC endpoints can be deprecated, sequencers can change policy, new attack vectors emerge. Verify the current state of your chain's MEV landscape before sizing significant trades.