You submit a swap. You pay the gas. The transaction confirms.
Then you check the execution price and it is worse than what you saw when you hit the button. Not by a rounding error. By a meaningful amount. You lost money between the moment you signed and the moment the chain settled.
This is not a glitch. It is a feature of how public blockchains work, and someone profited from the difference.
Understanding exactly how that happens is the first step to stopping it.
The Mempool Is Public
When you submit a transaction on Ethereum, it does not go directly into a block. It goes into the mempool, a waiting area where pending transactions sit until a validator includes them in the next block.
The mempool is public. Anyone can read it. Anyone with a node can see every pending transaction, including the token being swapped, the amount, the target pool, and the maximum slippage tolerance the sender set.
This is not a privacy flaw that will eventually get patched. It is structural. Public blockchains require public transaction data to maintain verifiability. The transparency that makes the system trustless is the same transparency that makes front-running possible.
Sophisticated actors run software that monitors this mempool continuously, identifies profitable transactions, and responds faster than the original sender can do anything about it.
The Sandwich Attack: Step by Step
The most common form of DEX front-running is the sandwich attack. The name describes the structure precisely. Your transaction gets placed between two transactions from the attacker.
Here is how it works in sequence:
Your transaction appears in the mempool. You are buying 10 ETH worth of some token on a liquidity pool. Your slippage tolerance is set to 1%, which tells the protocol you are willing to accept a price up to 1% worse than the quoted rate.
The bot detects your transaction. It calculates that your trade is large enough to move the pool price. It also notes your slippage tolerance, which tells the bot the maximum price it can push the asset to before your transaction reverts.
The bot submits a buy transaction with a higher gas fee than yours. This pushes it ahead of your transaction in the queue. The bot buys the same token you are about to buy, moving the price up.
Your transaction executes into the now-higher price. You get fewer tokens than the original quote showed because the bot's front-run trade already consumed the cheaper liquidity. Your trade goes through because it is still within your 1% slippage tolerance.
The bot immediately sells the tokens it just bought at the inflated price your trade created. The sandwich is complete.
The bot entered and exited a position in the same block. It took no directional risk. It extracted the value that should have been yours.
Why Your Slippage Tolerance Is the Bot's Budget
This is the piece most traders do not fully grasp until they see the math.
When you set a slippage tolerance of 2%, you are not asking to receive no worse than 2% below the quoted price. You are telling every bot watching the mempool that they have a 2% budget to work with before your transaction reverts.
A higher slippage tolerance means more room for a bot to push the price before your trade fails. It is the single biggest variable under your control in how profitable you are as a sandwich target.
A tight slippage tolerance does not eliminate sandwich attacks. It shrinks the margin the attacker has to work with and makes your transaction less attractive relative to other targets in the queue. Small trades with tight slippage are frequently skipped in favor of larger trades with looser tolerances.
The tension is real. If you set slippage too tight, your transaction reverts in volatile markets because the price moved legitimately before your block was confirmed. You waste gas and get no fill. If you set slippage too loose, you become a profitable sandwich target.
The right number depends on the liquidity depth of the pool you are using, the current market volatility, and the size of your trade relative to the pool. There is no universal answer. Pools with deep liquidity allow tighter slippage for the same trade size. Pools with thin liquidity require more tolerance even for small trades.
MEV: The Broader System Your Swap Is Operating Inside
Sandwich attacks are one specific tactic within a broader category called Maximal Extractable Value, or MEV.
MEV refers to all the value that can be extracted from the transaction ordering process. Validators and block proposers have the power to include, exclude, and reorder transactions within a block. That power has value, and entire ecosystems have been built to capture it.
MEV extraction includes sandwich attacks, but also arbitrage between DEX pools, liquidation racing on lending protocols, and more complex multi-step strategies that are harder to categorize.
The total MEV extracted on Ethereum has exceeded billions of dollars over the life of the network. It is not a marginal phenomenon. It is a parallel economy operating on top of the one most users interact with.
Flashbots, the research organization that built some of the earliest MEV infrastructure, estimated that before their intervention, competition between MEV bots was causing severe network congestion as bots spammed duplicate transactions to improve their odds of being included first. The gas wars were degrading the network for everyone.
Their solution, MEV-Boost and the broader block auction infrastructure it created, did not eliminate MEV. It organized it. Validators now auction off block space in a more structured way. Whether this is better or worse for ordinary users is genuinely contested.
Private Mempools and Transaction Privacy
The cleanest defense against front-running is removing your transaction from the public mempool entirely.
Private mempools, sometimes called private relays or protected RPC endpoints, route your transaction directly to block builders without making it visible to the general mempool. Bots watching the public mempool cannot see what they cannot read.
Several services offer this:
Flashbots Protect is a free RPC endpoint you can add to your wallet. Transactions routed through it go directly to Flashbots block builders. They do not appear in the public mempool before inclusion. If the transaction fails for any reason, you do not pay gas.
MEV Blocker, built by CoW Protocol and others, routes transactions to a network of searchers who compete to give you MEV rebates rather than extract from you. The model flips the incentive: searchers win by returning value to you, not by taking it.
Using these services requires a small configuration change in your wallet. You add a custom RPC endpoint. The user experience of trading does not change. The exposure to front-running drops substantially.
The tradeoff is that private relays may have slightly longer inclusion times during low-activity periods, and you are trusting the relay operator to behave as described. Neither concern is typically significant for ordinary retail trading.
Intent-Based Trading and What It Changes
A newer architecture is gaining ground in DeFi that sidesteps the front-running problem at a more fundamental level.
In a standard DEX trade, you specify the exact route: which pool, which tokens, which amounts, in which order. You submit the transaction. What you intended and what gets executed are the same instruction. This precision is what makes the transaction predictable and therefore exploitable.
Intent-based trading works differently. You specify what you want: I want to sell X of token A and receive at least Y of token B. You do not specify how. A network of solvers competes to find the best way to fulfill your intent, often off-chain, with only the final settlement landing on-chain.
CoW Protocol pioneered this model. Their batch auction system collects multiple user intents together and matches them where possible, allowing users on opposite sides of a trade to swap directly without touching an AMM pool. When direct matching is not possible, the remaining flow goes to external liquidity sources. Crucially, all trades in a batch settle at the same uniform clearing price, which structurally eliminates sandwich attacks within the batch. There is no meaningful way to front-run a trade that has not been routed yet.
Across Protocol, 1inch Fusion, and similar systems use variations of this solver model. The space is moving quickly and the user experience is becoming increasingly similar to a standard swap interface.
Gas Fees and Priority: What the Bot Has That You Do Not
Understanding the gas mechanics behind front-running explains why defending against it with gas alone is impractical for retail traders.
When a bot identifies a target transaction in the mempool, it submits its own transaction with a higher priority fee. Validators include higher-fee transactions first, so the bot's transaction lands in the block before yours. This is not cheating. It is the system working exactly as designed.
You could theoretically outbid the bot. Submit your transaction with an even higher priority fee. The bot detects this and raises its fee again. The bidding war escalates until one party gives up or the economics of the trade no longer justify the gas cost.
Professional MEV bots can execute this bidding logic in milliseconds. They are specifically optimized for this competition. A human trader cannot compete in real time, and even if you could, you would be spending more on gas to win a trade than you saved by not being front-run.
The only gas-based defense that works is making your transaction expensive to front-run relative to its profit potential. Tight slippage does this. Small trade sizes do this. Trading pairs where your specific trade does not generate enough spread for a bot to profit do this. These are passive defenses, not active countermeasures.
DEX Design and the Liquidity Structure Problem
Not all DEXs are equally vulnerable to sandwich attacks. The vulnerability is partly a function of how the protocol structures its liquidity.
Standard constant-product AMMs are maximally vulnerable because their price impact is continuous and predictable. A bot can calculate exactly how much to buy to push your trade to the edge of your slippage tolerance. The math is transparent.
Concentrated liquidity AMMs, where liquidity providers allocate capital within specific price ranges, have more complex impact curves. This does not eliminate sandwich attacks but makes the math harder and the outcome less predictable for the attacker.
Order book based DEXs, where trades are matched between resting orders rather than executed against pool reserves, are structurally much harder to sandwich. There is no continuous price curve to exploit. The trade either matches an existing order or it does not. Several DEXs on higher-throughput chains have revived the order book model specifically because it provides cleaner execution guarantees.
Protocol-level design decisions matter for execution quality in ways that slippage settings and RPC choices cannot fully compensate for.
Time-Weighted Average Price Orders
For large trades, the most practical defense against sandwich attacks is not a technical tool. It is trade sizing.
A trade that represents 0.01% of a pool's liquidity has minimal price impact and minimal front-run profit potential. A trade that represents 5% of a pool's liquidity moves the price significantly and is a high-value target.
TWAP orders, available on several protocols, break a large trade into many smaller pieces executed at intervals over a set time window. Instead of one large transaction that creates a predictable price impact, you generate many small transactions whose individual impact is too small to profitably sandwich.
The tradeoff is execution time. A TWAP order takes minutes to hours to complete. You are exposed to price movement during that window in both directions. For traders whose priority is minimizing front-run exposure on large positions, this is generally an acceptable cost. For traders who want immediate execution, it is not.
What to Actually Do Before Your Next Trade
Here is the practical layer, sequenced from lowest to highest friction:
Set slippage tight. For most liquid pairs on established pools, 0.1% to 0.5% is achievable. Accept that some transactions will revert and retry. The gas cost of a retry is almost always less than the cost of a successful sandwich.
Switch your RPC to a private endpoint. Flashbots Protect or MEV Blocker can be added to MetaMask or any wallet that supports custom RPC settings in under two minutes. There is no fee and no meaningful downside for ordinary trading.
Use a DEX aggregator that routes through private order flow. Several aggregators have integrated MEV protection into their default routing. Check whether the interface you use has this feature and whether it is enabled.
For large trades, use intent-based protocols or TWAP execution. The execution experience is slightly different but the fill quality on large trades is substantially better.
Know which pools are worth trading in. Thin pools with low total value locked are front-run targets even for small trades because the price impact is larger. Stick to pools where your trade size represents a small fraction of total liquidity.
The Honest Framing
Front-running is not going away. The economics that create it are structural. As long as block proposers have ordering power and transactions carry predictable price impact, someone will find a way to extract value from the gap between submission and settlement.
The infrastructure for protection has improved dramatically. Private mempools, intent-based trading, and TWAP execution tools now exist and are accessible without technical expertise. Using them is not optional hygiene for serious DeFi traders. It is the baseline.
The traders getting consistently front-run in 2025 are the ones who have not updated their setup since 2021. The tools to stop it are free, they take minutes to configure, and they work.
The mempool does not care that your trade is small. Set it up so the bots do not either.
