The one-sentence version
After you broadcast a swap transaction on Ethereum, it waits in a public mempool to be included in a block, where everyone can see it. Specialized bots see that you are about to make a large purchase of a certain token, so they buy it right before you (pushing the price up), then sell it immediately after your transaction executes at a higher price, pocketing the difference. This is called a sandwich attack, which is the most common type of MEV (Maximal Extractable Value). User-level defenses include: setting reasonable slippage tolerance and sending transactions to private mempools so they are not exposed in the public mempool.
This article has three layers:
- Layer 1: The Intuition: Being cut in line while queuing
- Layer 2: Real-World Use: The scale of MEV, Flashbots, and Private RPCs
- Layer 3: Mathematics and Engineering details of sandwich attacks, slippage settings, and other types of MEV
Layer 1: The Intuition
1.1 Being cut in line while queuing
Imagine you are at an auction and raise your hand to say, "I want to buy this item for no more than 100 USD." Your voice is loud, and everyone hears you.
A shrewd person jumps in and buys it for 90 USD first, then immediately turns around and sells it to you for 99 USD. You still execute within your "no more than 100 USD" limit and don't notice anything unusual, but you ended up paying 9 USD more than necessary.
On the blockchain:
- "Raising your hand to bid" = Your transaction is waiting in the public mempool;
- "Buying ahead of you" = A bot pays a higher gas fee to have its transaction placed before yours;
- "Selling it back to you" = Your transaction executes at a worse price, and the bot immediately sells to realize a profit.
Your transaction is sandwiched between two bot transactions, hence the name "sandwich."
1.2 Who determines the ordering
The order of transactions in a block is determined by the block producer (after the Ethereum Merge, these are validators via specialized block builders), who naturally prioritizes transaction combinations that bring them the most profit. MEV is "the extra money earned by arranging transaction order, inserting, or removing transactions."
Layer 2: Real-World Use
- Scale: Statistics from on-chain analysis platforms show that the cumulative MEV extracted on Ethereum has reached the billions of dollars, a significant portion of which comes from ordinary users being sandwiched.
- Flashbots (since 2020): A research and infrastructure organization that introduced channels to send MEV transactions without passing through the public mempool directly to block builders, as well as the later MEV-Boost (which separates "block building" from "block proposing").
- Private RPC / Anti-sandwich RPC: Services like Flashbots Protect and MEV Blocker. Once a user replaces their wallet's RPC with their address, transactions are sent directly to builders without being exposed in the public mempool, significantly reducing the chance of being sandwiched; some services even return the "rebates" paid by bots for your transaction back to you.
- Wallet and DEX responses: Some wallets use anti-sandwich RPCs by default; some transaction aggregators adopt the "intent" model, where specialized solvers match orders off-chain and then submit them to the chain all at once.
Layer 3: Principles and Engineering
3.1 The mathematics of a sandwich
Constant Product Pool: 100 ETH and 200,000 USDC (Price 2000)
Without an attack: You use 20,000 USDC to buy ETH and receive You set a 10% slippage tolerance, meaning you must receive at least approximately 8.18 ETH.
Sandwich:
- The bot first buys with 10,000 USDC, receiving approximately 4.762 ETH, pushing the price to 2205;
- Your transaction executes, receiving only approximately 8.282 ETH, which is still above the 8.18 lower limit, so the transaction succeeds;
- The bot sells 4.762 ETH, receiving approximately 11,941 USDC.
You received approximately 0.81 ETH less (about 8.9%), and the bot earned approximately 1941 USDC (excluding gas and pool fees). (Verified with Python.)
Key observation: The amount a bot can extract is capped by your allowed slippage. The wider the slippage setting, the harder you get sandwiched.
3.2 The slippage setting dilemma
| Slippage Setting | Result |
|---|---|
| Too wide (e.g., 10%) | Large room for being sandwiched |
| Too narrow (e.g., 0.1%) | Normal price volatility will cause the transaction to fail, wasting gas fees |
| Reasonable | Estimated based on pool liquidity and transaction size; split large transactions or use aggregators |
3.3 Other common MEV
| Type | Description | For ordinary users |
|---|---|---|
| Arbitrage | Moving funds when prices between two exchanges are inconsistent to bring prices back to parity | Generally harmless, even beneficial |
| Liquidation | Front-running the liquidation of under-collateralized positions in lending protocols | Part of protocol design |
| Front-running | Copying a profitable transaction you discovered and executing it before you | Harmful, e.g., a white-hat rescue transaction being stolen by a bot |
| Sandwich | See above | Harmful |
| JIT Liquidity | Adding liquidity instantly before your large transaction to earn fees and then withdrawing | Minimal impact |
3.4 Implications for products
- Provide a "private send" option when sending transactions, or use anti-sandwich RPCs by default;
- The confirmation page should clearly display the minimum amount you will receive (calculated by slippage), rather than just the "estimated amount you will receive";
- Compare actual execution volume with expectations after the transaction is on-chain; if the deviation is too large, warn the user they may have been sandwiched (see "Verification after signing");
- For large swaps, it is recommended to split the transaction or use an aggregator that supports intent matching.
Summary
| Layer | Key points |
|---|---|
| Intuition | Bidding is heard by others, who buy ahead of you and sell back at a higher price |
| Essence | Public mempool + Block producer determines transaction order = MEV |
| Mathematics | The upper limit of being sandwiched is your slippage tolerance |
| Defense | Reasonable slippage; Private mempools / Anti-sandwich RPCs; Intent matching |