MEV: Front-Running and Sandwich Attacks
Understand MEV, the role of searchers, builders and validators, how a sandwich attack works and concrete ways to protect yourself.
The essentials
What is MEV?
On Ethereum and most blockchains, a transaction isn't executed the moment you click "Confirm." It is first broadcast, then waits for a block producer to include it. Whoever builds the block decides three things: which transactions go in, which are left out, and in what order they execute.
The ethereum.org documentation defines MEV as the maximum value that can be extracted from block production, beyond the standard block reward and fees, thanks to this power of inclusion, exclusion and ordering. The term originally stood for "Miner Extractable Value" in the proof-of-work era; it is now "Maximal" because it is no longer miners but validators and specialized builders who profit from it.
Order matters enormously in decentralized finance (DeFi). On an AMM (Automated Market Maker, a DEX that sets prices with a formula based on reserves), every swap changes the price for the next transaction. Being placed just before or just after a large operation can therefore earn money.
The mempool, the starting point of front-running
Most transactions travel through the public mempool: a waiting room visible to all the network's nodes. Anyone can read your transaction there before it's confirmed: the token you're buying, the amount and, above all, the slippage you tolerate (the maximum price deviation you accept).
Front-running means watching a pending transaction and placing your own just ahead of it to profit. Back-running means placing yours right after. A sandwich attack combines both.
The players in the MEV chain
Searchers
Searchers are independent participants who run algorithms (bots) to detect profitable opportunities: price gaps, liquidatable positions, vulnerable swaps. They build transactions or "bundles" (groups of transactions to execute in a specific order) and pay for inclusion through fees or direct payments.
Builders
Builders assemble complete blocks from public transactions and the bundles received from searchers. Their goal is to produce the most profitable block possible, then bid to have it selected.
Relays and validators (proposers)
On Ethereum under proof of stake, a validator is randomly selected to propose each block. Rather than building it themselves, they can buy it on a marketplace. This is the principle of PBS (Proposer-Builder Separation): the validator proposes, the builder builds.
Today, this separation mostly goes through MEV-Boost, open-source software developed by Flashbots that validators run alongside their clients. Builders send their blocks to relays, which check them and pass the most profitable bid on to the validator. According to Flashbots' documentation, validators using MEV-Boost can increase their staking rewards by about 60% or more, which explains its adoption.
| Player | Role | What they earn |
|---|---|---|
| Searcher | Finds opportunities, creates bundles | The opportunity's profit, minus what they pay out |
| Builder | Assembles the most profitable block | The margin between the block's value and its bid |
| Validator | Proposes the selected block | The builder's bid and the block reward |
The consequence is important for users: competition between searchers pushes most of the extracted value toward builders and then validators. But this value does come from somewhere, and in the case of a sandwich, it comes from you.
The sandwich attack, step by step
The principle: a bot spots your purchase in the mempool, buys the same token just before you (pushing the price up), lets your transaction execute at a worse price, then sells right after.
A concrete example
Take a simplified ETH/USDC pool running on the constant-product formula (x × y = k), with no fees to keep the math readable:
- Reserves: 100 ETH and 300,000 USDC (starting price: 3,000 USDC per ETH).
- You want to buy ETH with 30,000 USDC, with a tolerated slippage of 10%.
Without an attack. The pool goes to 330,000 USDC, so to 30,000,000 / 330,000 ≈ 90.909 ETH. You receive about 9.091 ETH. With 10% slippage, your transaction accepts receiving a minimum of 8.182 ETH.
With a sandwich attack.
- Front-run: the bot buys with 15,000 USDC. The pool goes to 315,000 USDC and 95.238 ETH. The bot receives 4.762 ETH.
- Your transaction: your 30,000 USDC take the pool to 345,000 USDC and 86.957 ETH. You receive 8.281 ETH. That's above your minimum of 8.182 ETH, so the transaction goes through.
- Back-run: the bot sells its 4.762 ETH. The pool returns to 91.719 ETH, or about 327,087 USDC. The bot recovers about 17,913 USDC.
Result. The bot spent 15,000 USDC and recovers about 17,913, nearly 2,913 USDC of gross profit (before gas fees and payment to the builder). On your side, you received about 0.81 ETH less than expected, or about 2,430 USDC at the starting price.
If you had set a 3% slippage (minimum about 8.818 ETH), a 15,000 USDC front-run would have made your transaction fail. The bot would then have had to reduce the size of its purchase, and so its profit. That's the key lesson: the bot calibrates its attack to leave you exactly at the edge of your slippage tolerance. The wider it is, the more it can take.
In reality, pool fees, gas fees and competition between bots reduce these amounts, but the mechanism remains identical.
Arbitrage and liquidations: "benign" MEV
Not all MEV comes at a user's direct expense. Two forms are often considered useful to how DeFi works.
Arbitrage
When the same token doesn't have the same price on two DEXs, a searcher buys where it's cheaper and sells where it's more expensive, often in a single atomic transaction (everything executes or nothing does). ethereum.org describes it as the simplest and most competitive MEV opportunity. This arbitrage aligns prices across platforms. It's often done as a back-run, right after a large swap that unbalanced a pool, without changing the price you get.
Liquidations
On lending protocols, a borrower whose collateral no longer sufficiently covers their debt can be liquidated. Protocols rely on outside actors to trigger these liquidations, in exchange for a bonus. Searchers compete to be first. For the protocol, it's a safety mechanism; for the liquidated borrower, it's a loss, but one that follows from the protocol's rules and not from manipulation of their transaction.
A caveat: even "benign" MEV has side effects. Bidding wars between bots can congest the network, and the concentration of revenue among a few builders raises centralization and censorship questions.
How to protect yourself
1. Set tight slippage
This is the simplest protection. For a liquid pair (ETH/USDC, stablecoins against each other), a slippage of 0.5% or less is generally enough. For an illiquid token, wider slippage is sometimes necessary, but that is precisely where sandwich exposure is highest. Beware of interfaces that suggest a high "auto" slippage without showing it to you.
2. Use a private RPC
An RPC (Remote Procedure Call) is the access point through which your wallet sends the transaction to the network. A protected RPC sends your transaction directly to builders through a private channel, without going through the public mempool. For example, Flashbots Protect says it keeps transactions hidden from front-running and sandwich bots, charges no fees if the transaction fails, and returns part of the MEV generated as refunds. Several wallets offer this kind of option in their network settings. The topic is covered in detail in the guide on private mempools.
Limitation: you trust the RPC operator and the builders who receive your transaction not to exploit it.
3. Use batch auctions or intents
Some protocols change the execution model. CoW Protocol, for example, groups orders into batch auctions: orders for the same pair in the same batch are settled at a uniform price, which makes the order of transactions within the batch irrelevant. When two users trade in opposite directions, the protocol can match them directly ("coincidence of wants") without touching the pools. More broadly, intent-based systems, where you sign a desired outcome and solvers handle the execution, aim to limit exposure to the public mempool.
4. Split large orders
An order that is large relative to the pool's liquidity moves the price a lot and becomes a profitable target. Splitting it into several smaller orders, or using an aggregator that spreads the execution, reduces price impact and the incentive to attack.
Checklist before a swap
- Check the pool's liquidity and the displayed price impact.
- Manually set slippage to the lowest reasonable level.
- Consider a protected RPC or an interface with batch/intent execution.
- Avoid placing a large order on an illiquid token during high volatility.
- After execution, compare the amount received with the estimated amount on a block explorer.
Mistakes to avoid
- Leaving a high slippage "so it goes through": it's a direct invitation to sandwich bots.
- Believing a private RPC protects against everything: it reduces exposure to the public mempool, but doesn't fix a bad price or a manipulated pool.
- Confusing price impact with slippage: price impact is the change caused by your own order; slippage is the extra margin you tolerate. A sandwich exploits the latter.
- Ignoring neighboring transactions: on an explorer, two transactions from the same address bracketing yours in the same block are the typical sign of a sandwich.
- Thinking MEV exists only on Ethereum: any network where transaction ordering can be influenced is exposed, in varying forms.
This guide provides general information and does not constitute investment advice.
Key takeaways
- MEV is the value derived from controlling the inclusion and ordering of transactions in a block.
- On Ethereum, searchers, builders, relays and validators share this value through PBS and MEV-Boost.
- A sandwich attack brackets your swap and makes you buy at a higher price, up to the exact limit of your slippage.
- Arbitrage and liquidations are forms of MEV useful to the market, but not without side effects.
- Tight slippage, a protected RPC and batch or intent execution are the main protections.