Crypto Newbie / Simulators / MEV Sandwich
MEV Sandwich Attack Simulator
Every time you swap on a public DEX (Uniswap, Sushiswap, Raydium), there's a chance a bot is front-running you. The mechanic is brutal: bot sees your pending tx, buys the same asset first to push the price up, lets your tx execute at the worse price, then dumps. You pay slippage; bot pockets the difference. This simulator runs the exact Uniswap V2 x·y=k math so you can see how much a sandwich costs at various swap sizes — and learn how to protect yourself.
DEX pool state
Spot price (USDC per ETH)
$3.50k
User's swap
USDC user expects (no bot)
$17.36k
Bot's front-run size
Attack flow
1. Bot front-runs (buys ETH)
Bot sees user's pending swap in the mempool. Front-runs by spending USDC to buy ETH FIRST — pushes ETH price up in the pool.
2. User's swap executes at worse price
User's swap now hits a pool where ETH is more expensive. They get LESS USDC than they expected — the slippage they pay is the bot's profit.
3. Bot back-runs (sells the ETH it bought)
Bot immediately sells the ETH it just bought, now at the elevated price from the user's swap. Pockets the difference.
Results
User (victim)
USDC user actually got: $17.86k
User's loss to slippage (USDC): $-497.55
User's slippage %: -2.87%
Bot (attacker)
ETH bot bought (front-run): 14.0428 ETH
USDC bot got from back-run: $49.21k
Bot gross profit: $-791.45
Bot NET loss (after gas): $-821.45
The mempool: where the attack lives
Ethereum, BSC, Polygon, Arbitrum, and most chains have a 'public mempool' — a global queue of pending transactions visible to anyone running a node. Your DEX swap sits there for ~1-12 seconds before being mined. Bots watch this queue 24/7 with sub-second polling. When they spot a profitable swap, they simulate it locally, calculate the optimal sandwich size, and submit their own bracketing transactions with enough gas to land in the same block, BEFORE and AFTER yours.
Why bots target larger swaps disproportionately
Sandwich profit scales roughly with swap_size^2 vs the pool's liquidity. A 0.1% swap moves the price by ~0.1% (minimal sandwich opportunity). A 5% swap moves the price by ~5% (huge sandwich window). The bot's optimal front-run size also scales with the user's size — so $50k swaps get hit much harder than $500 swaps. If you must trade large, use protected RPCs.
Protected RPCs and how they work
Flashbots Protect, MEV Blocker, BloXroute Protect: these forward your transaction to validators DIRECTLY via private channels, bypassing the public mempool entirely. The bot never sees your tx until it's mined. Some go further and run the tx through a private auction where searchers bid to include your tx but cannot front-run it. Trade-off: slightly slower confirmation (~2-5 sec added) and sometimes higher gas. For swaps > $1k it's almost always worth using.
Slippage tolerance — the user's first defence
Every DEX UI lets you set 'max slippage'. If the actual execution price is worse than this tolerance, the tx reverts (you keep your tokens, you pay only gas). Setting 0.1-0.5% is the standard defensive setting. Some UIs default to 5-10% — DON'T accept these defaults. A 5% slippage tolerance means sandwich bots can extract up to 5% from your trade with impunity. The lower you set tolerance, the harder it is to sandwich, but the more likely your tx fails entirely during high volatility.
Frequently asked questions
+Can sandwich attacks happen on every chain?
Any chain with public mempool + DEX trading is vulnerable. Ethereum + L2s, BSC, Polygon = yes. Solana has a different transaction model (no mempool) but still has MEV via 'priority fee' bidding wars, plus Jito's MEV market explicitly auctions block-space. The dynamic is identical even if the mechanism differs.
+Are sandwich attacks illegal?
No. They're against the SPIRIT of fair markets but legal everywhere because: (1) the bot is paying gas like any other user, (2) the protocol allows any tx ordering the validator chooses, (3) the user explicitly accepted slippage tolerance. Some argue MEV should be regulated; current legal consensus is 'caveat emptor — use protected RPCs if you don't want to be sandwiched'.
+What's the difference between sandwich and front-running attacks?
Front-running = bot copies your trade and submits first. You get the slightly-worse second execution. Sandwich = front-running + back-running combined. Bot front-runs to push price, lets you execute at the worse price, then closes the position to capture YOUR slippage. Sandwich is strictly worse for you because the bot's profit IS your loss; pure front-running can sometimes be neutral.
+Are aggregators (1inch, CowSwap) safer?
Mostly yes. 1inch splits your swap across multiple pools (smaller per-pool size = smaller sandwich opportunity). CowSwap goes further: it batches user swaps into private auctions where MEV searchers bid to fill but cannot sandwich. CowSwap claims ~50% MEV reduction in practice. Aggregators are good defence in depth, but use them ALONG WITH protected RPCs for serious trades.
+Why does the simulator show bot profit being negative sometimes?
Bot's front-run size has a sweet spot. Too small = price didn't move enough for the back-run to be profitable. Too big = bot's own slippage on the front-run eats the profit. The 'Find optimal' button computes the size that maximises profit. Bots in the real world solve this analytically in milliseconds and often have profit margins of just a few dollars per attack — they win by volume, not per-attack size.