MEV and Sandwich Attacks: How DEX Execution Can Be Affected

MEV is about ordering, not about price views

ethereum.org defines maximal extractable value as “the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block.”

The definition has three verbs for a reason. Including a transaction is worth something. So is excluding one. So is reordering two that would otherwise have executed in the opposite sequence. MEV is the payment for controlling that sequence.

The page also notes the history: the concept was first called “miner extractable value” because miners controlled inclusion and ordering under proof-of-work, and the term changed after The Merge moved those roles to validators. The extraction methods did not change with the name.

Most MEV is captured by searchers — independent participants running algorithms to detect opportunities and bots to submit them — with validators taking a share through priority fees. The page is explicit that in competitive opportunities such as DEX arbitrage, searchers may pay 90% or more of the value in gas fees, because the only way to guarantee inclusion is to bid the highest price.

The four common patterns

DEX arbitrage. The same asset trades at two prices on two venues. Buy low on one, sell high on the other. Simplest and most competitive.

Liquidations. A lending position becomes eligible for liquidation when its collateral value falls relative to its debt. Whoever submits the liquidation first collects the incentive.

Sandwiching. A large pending swap will move a pool’s price. A bot trades ahead of it to buy at the old price and sells after it at the new one.

Generalised frontrunning. A bot watches the mempool, copies a profitable transaction’s logic with its own addresses, and resubmits it with a higher gas price. This is the pattern that made private transaction relays necessary.

For an ordinary user, the first two are mostly background noise. The third is the one that shows up as an unexpectedly poor fill.

The sandwich, step by step

The setup is a constant-product pool. Liquidity providers have deposited both assets, and the pool prices them by the ratio of reserves. A large trade moves that ratio against itself; that is price impact, and it is what the attacker harvests.

The sequence:

1. A victim submits a swap to the public mempool, where it is visible before it is mined.
2. A searcher computes the price impact the swap will have.
3. The searcher submits a buy with a higher priority fee, landing immediately before the victim.
4. The victim’s swap executes at a worse price, because the attacker’s buy already moved the pool.
5. The searcher sells immediately after, at the price the victim’s trade created.

The attacker’s profit is bounded by the victim’s price impact and by the victim’s slippage tolerance. The tolerance is the parameter that makes the attack possible: if the victim’s minimum output is set above what the sandwiched execution would deliver, the victim’s transaction reverts and the attack earns nothing.

A worked example, in full

Pool: 1,000,000 DAI and 100,000 UNI. Constant product, no fee, for arithmetic clarity. The pool price is 10.00 DAI per UNI.

Without a sandwich. The victim swaps 10,000 DAI:

• UNI received = 100,000 × 10,000 / (1,000,000 + 10,000) = 990.0990 UNI
• Execution price = 10,000 / 990.0990 = 10.10 DAI per UNI
• Price impact = 1.00%

With a sandwich. The bot buys with 30,000 DAI first:

• UNI received by the bot = 100,000 × 30,000 / 1,030,000 = 2,912.6214 UNI
• Pool after the bot’s buy: 1,030,000 DAI and 97,087.3786 UNI
• Pool price after the buy: 10.609 DAI per UNI

Now the victim’s 10,000 DAI executes:

• UNI received = 97,087.3786 × 10,000 / 1,040,000 = 933.5325 UNI
• Shortfall versus the unsandwiched case = 990.0990 − 933.5325 = 56.5665 UNI, or 5.71%
• Execution price = 10,000 / 933.5325 = 10.712 DAI per UNI, against 10.10 without the bot

The bot then sells 2,912.6214 UNI into the pool:

• Pool before the sale: 1,040,000 DAI and 96,153.8461 UNI
• DAI received = 1,040,000 × 2,912.6214 / (96,153.8461 + 2,912.6214) = 30,576.7056 DAI
• Gross profit = 30,576.7056 − 30,000 = 576.71 DAI, a 1.92% return on the 30,000 deployed

The victim’s shortfall, valued at the unsandwiched execution price, is about 571 DAI. The bot’s gross profit is 576.71. The gap between the two numbers is the price impact the victim would have paid anyway: the sandwich captures the difference between the two impacts, not the whole cost of trading.

Why the tolerance is the real control

The example only works because the victim’s transaction accepted a fill 5.71% worse than the unsandwiched outcome. If the victim had set a minimum output of 985 UNI — roughly 0.5% tolerance against a fresh quote — the sandwiched execution at 933.53 would have reverted. The bot would have paid gas on both legs and earned nothing.

This is the trade-off that makes the control awkward. A tolerance tight enough to defeat sandwiching is also tight enough to fail during ordinary volatility, and every revert costs gas. The practical answer is a tolerance calibrated to the pool’s depth and the asset’s recent range, not a fixed number copied from a tutorial.

The second control is the quote itself. A quote taken from a stale block, or from a route that differs from the execution path, sets the tolerance against the wrong baseline.

What the attacker is risking

Sandwiching is not atomic. DEX arbitrage can be a single transaction that reverts if it is not profitable; a sandwich is two trades that depend on a third party’s transaction landing between them.

ethereum.org notes that sandwiching is riskier for this reason and is exposed to a salmonella attack. If the victim’s transaction fails, is delayed, or lands after the bot’s sell, the bot is left holding the asset it bought, at a price it moved against itself. It pays gas on both legs regardless.

That risk is why sandwiches target large, predictable swaps with loose tolerances, and why they are less common on deep pools where the required front-run is large relative to available capital.

The defences, and what each one actually changes

Private transaction submission. Sending a transaction through a relay that does not publish it to the public mempool removes the signal the searcher needs. Flashbots is the best-known example: ethereum.org describes it as a service that lets searchers submit transactions to validators without revealing them to the public mempool, which prevents frontrunning by generalised frontrunners. The trade-off is dependence on the relay’s liveness and its policy.

MEV-protected RPC endpoints. Wallet and RPC providers offer submission paths that route around the public mempool. The effect is similar, and so is the dependency: you are trusting an intermediary to handle ordering.

Batch auctions. If transactions in a batch are priced at a single clearing price rather than in sequence, there is no advantage to being first within the batch. This removes the ordering profit for the batched trades; it does not remove the price impact of the batch as a whole.

Tighter slippage. Doesn’t prevent the attempt, but caps the extraction and makes failed attempts costly for the attacker.

Smaller trades and deeper pools. Reduces price impact, which reduces the profit available. The spread, depth and slippage guide covers how to read pool depth before sizing a trade.

What none of it fixes

Every defence above changes who can see your transaction or how it is ordered. None of them changes the fact that a trade large relative to the pool moves the price. If you sell 10% of a pool’s reserves, you will pay for it whether the counterparty is a bot, a liquidity provider or the next retail buyer.

The other thing none of them fixes is the settlement layer’s finality. A transaction that is ordered and included is not necessarily final; the finality guide covers the difference between inclusion and irreversibility. And for the order-type side of the same problem on a centralised venue, CEX versus DEX compares where the matching happens and who can see the order.

How these sources were checked

The definition of MEV, the account of searchers and validators, the statement that competitive opportunities can consume 90% or more of value in fees, the description of generalised frontrunners, the Flashbots relay description, the arbitrage and liquidation examples, and the sandwiching description including the salmonella risk all come from ethereum.org’s MEV page, retrieved 2026-10-24. The academic treatment of frontrunning and miner extractable value is from Daian et al., “Flash Boys 2.0” (arXiv:1904.05234), retrieved 2026-10-24.

Every figure in the worked example was computed from the stated pool reserves and trade sizes using the constant-product formula with no fee, so the arithmetic can be checked by hand. Real pools charge a fee, which would reduce both the victim’s output and the attacker’s profit. The example is illustrative, not a record of an observed attack.