MEV in swaps: sandwich attacks, slippage and protection

Technical review: September 6, 2026. Educational content. All numerical examples are hypothetical, not market quotes or investment recommendations.

MEV in swaps helps explain why a DEX swap can execute on worse terms than expected even when the wallet reports a successful transaction. It does not mean every disappointing exchange rate is an attack. Liquidity, fees, market movements and transaction ordering affect execution in different ways. Understanding those differences is more useful than relying on a protection label alone.

This guide focuses primarily on swaps and execution on Ethereum. For the broader exchange model, see our guide to decentralized exchanges. Other networks can use different systems for submitting and ordering transactions. An RPC configuration, service promise or behavior observed on Ethereum should not automatically be assumed to apply to every blockchain.

MEV in swaps: what it means

MEV stands for Maximal Extractable Value: value available through the inclusion, exclusion or ordering of transactions, beyond the ordinary block rewards and gas fees. The Ethereum documentation on MEV discusses several forms, including arbitrage, liquidations and sandwich attacks.

The economic point is that changing the sequence of otherwise similar operations can change who captures value. Buying before an order that moves a pool’s price is different from buying after it. For someone who simply wants to exchange tokens, the practical questions are how much arrives and which execution conditions were authorized.

A bad outcome does not identify an attacker by itself. Another swap appearing near yours in a block is not sufficient evidence of a sandwich. A credible reconstruction examines trade direction, the pools involved, actual ordering, reserve changes and the relationship between the suspected transactions.

Who handles the transaction before confirmation?

The wallet prepares and signs an operation; the submission channel passes it into network infrastructure. In Ethereum’s ecosystem, searchers identify opportunities, builders can assemble blocks and proposers participate in proposing them under the consensus system. These roles are not simply another name for the DEX, and they need not belong to the same organization.

From a user’s perspective, ask who sees the request before confirmation, who forwards it and which route is used if the initial attempt fails. An aggregator’s name on the screen may not answer all three questions. Execution involves more than the interface where the quote first appeared.

This distinction also helps with troubleshooting. A pending transaction may involve route availability, fees, its nonce or the order’s constraints. Increasing slippage without diagnosing the problem changes the price protection, but it may not address the reason the transaction has not landed.

Slippage, price impact and fees are separate costs and constraints

Price impact is the effect of your own trade on the price available from the liquidity it uses. An order that is large relative to a pool can receive a worse average rate even when nobody else intervenes. Uniswap’s explanation of price impact centers on this relationship between trade size and liquidity depth.

Slippage describes the difference between an expected and executed outcome using the interface’s chosen reference. Slippage tolerance is an authorized limit, not a fee automatically collected by the protocol. A wide tolerance does not force poor execution, but it can allow an outcome substantially worse than the initial quote.

Fees need a separate comparison. Ethereum gas fees, pool fees and any service charges may be shown differently across products. A route offering more output tokens may be less attractive after additional costs. Conversely, the route with the lowest gas estimate may provide a worse exchange rate.

Worked example: read the minimum output, not just the percentage

Suppose an interface estimates an output of 1,000 units of the destination token. For this teaching example, we explicitly define the minimum as quoted output multiplied by one minus the tolerance. A 1% tolerance gives 990; a 5% tolerance gives 950. This is not a universal formula for every SDK or order type: inspect the actual minimum displayed and signed in a real transaction.

If execution returns 992 units, the shortfall from the quote is eight units, or 0.8%. In this model it satisfies both limits. Setting a 5% tolerance therefore does not mean automatically paying a 50-unit charge. The permitted shortfall and the realized shortfall are different quantities.

If available output instead falls to 975, it does not meet a minimum of 990, but it exceeds 950. Assuming an atomic swap and a contract that enforces the specified minimum, the first order should not execute at that output. This does not make every failure free: a transaction included on-chain and then reverted can still consume gas.

The example does not establish that a sandwich occurred or calculate an attacker’s profit. It only separates quoted, minimum and actual output. Measuring an attack would also require a defensible estimate of execution without the suspected intervention, along with fees and other relevant transactions.

A second example: price impact without an attacker

Consider a hypothetical liquidity pool with 100 units of token A and 200,000 units of token B. Assume a constant-product curve, no fees, no intervening trades and ordinary tokens without special transfer mechanics. The initial reserve ratio is 2,000 B per A, but that is not a guaranteed average exchange rate for an arbitrarily large order.

Adding one unit of A brings its reserve to 101. Keeping the initial product of 20,000,000 constant leaves approximately 198,019.802 B in the pool. The output is therefore approximately 1,980.198 B, rather than 2,000. The roughly 0.99% difference from the initial ratio comes from the curve in this model, without a sandwich.

This is a simplified calculation, not a live Uniswap quote. Actual pools can charge fees, use concentrated liquidity or other pricing functions, and receive transactions between quotation and execution. The Uniswap v2 pricing documentation distinguishes calculating output from the safety checks needed before treating a pool’s current price as fair.

The diagnostic lesson is that lowering tolerance does not remove price impact already embedded in the initial quote. First assess the quote itself; then decide what subsequent deterioration is acceptable. Mixing those decisions can make a trade look cautious even when its starting terms are unfavorable.

How a sandwich changes execution

In a typical sandwich, an actor places a trade before the targeted swap and another after it, seeking to benefit from the resulting movement in pool pricing. The user can receive less than initially quoted while the transaction still meets the authorized minimum. The available opportunity depends on actual conditions, not simply the order’s headline value.

Shallow liquidity and permissive limits can increase exposure. Deep liquidity is not insurance, however, and a tight limit is not a complete solution. Tighter conditions can also lead to more unexecuted attempts as prices change. Evaluate the protection alongside routing and the cost of attempting the trade again.

For a later review, retain the quote and its timestamp, the signed minimum and the transaction hash. Compare execution with that contemporaneous quote, not a price observed much later. When the prior pool state is unavailable, an estimate of harm should disclose the limitation instead of claiming false precision.

Arbitrage and liquidations are not identical to sandwiching

Arbitrage exploits a price difference between markets. A liquidation can apply a lending protocol’s rules when collateral is insufficient. These mechanisms differ from deliberately worsening a targeted swap through surrounding trades. Their inclusion under MEV does not mean they have identical effects or deserve identical conclusions.

The useful question is not merely whether someone earned a profit, but how that profit arose and who bore the cost. Observed profit does not automatically prove an equal loss for a particular wallet. Aggregate MEV metrics also need a clear methodology before they can support an estimate of an individual user’s harm.

Private routing changes visibility, not the need for trust

A private submission channel can avoid ordinary distribution through the public mempool. That changes who can observe a transaction before inclusion, but it does not mean nobody sees it. The service and its authorized recipients become part of the trust assumptions.

The Flashbots Protect quick-start guide explicitly notes trust in builders not to frontrun or disclose transactions to third parties. It also warns that switching RPCs in MetaMask before confirmation can cause a transaction to be sent again through the public mempool. That is an execution risk, not merely an interface preference.

Before using a protection service, check the supported network, forwarding behavior, recipients and handling of pending requests. Verify endpoints against official documentation rather than private messages or advertisements. Configuring a submission route does not require giving a provider your seed phrase.

Settings, refunds and fallback behavior deserve separate checks

The Protect settings documentation reviewed for this article distinguishes default settings, fast mode and information-sharing options. Additional recipients can improve inclusion opportunities, but extend the set of parties being trusted. Different sharing options should not be treated as equivalent privacy guarantees.

The documentation also allows settings for reverted transactions and the block range over which inclusion is attempted. Default behavior is therefore not an unconditional promise covering every configuration. Potential refunds should likewise not be described as certain returns or evidence that the underlying swap offered good value.

Write down relevant conditions before comparing routes. If a wallet or service changes modes automatically, check whether transaction exposure changes too. A feature’s commercial name may remain the same while the effective path or recipient set changes underneath it.

Intents and auctions: the signed conditions still matter

An intent expresses trading conditions rather than directly specifying every execution step. CoW Protocol’s documentation on intents describes a signed order as trading constraints, distinct from a directly executable user transaction.

This separation lets specialized participants seek execution within those constraints. It does not make the signature inconsequential: assets, amounts, recipient, expiry and permissions still need to be correct. A message-signing prompt without an immediate gas payment is not proof that the action cannot affect funds.

Products described as intent-based or auction-based can follow different rules. Read the specific cancellation process and, where partial fills are supported, distinguish expiry from partial execution. A broad design category does not supply a uniform guarantee of a better price.

Splitting a large order is a tradeoff, not a universal defense

The previous version recommended splitting large orders as general protection. That was too broad: fragmentation does not guarantee less MEV or better aggregate execution. If liquidity is unchanged and successive trades follow the same curve, additional clicks do not create new liquidity.

For a simple accounting example, four transactions with a hypothetical network cost of EUR 3 each cost EUR 12, compared with EUR 3 for a single transaction at the same unit cost. The additional EUR 9 would need to be justified by an actual execution benefit. These are teaching numbers, not an estimate of Ethereum gas charges.

Spreading trades over time also exposes the remaining amount to market changes between installments. A meaningful comparison covers the entire order, cumulative costs and elapsed time. Reporting only the best installment selects a favorable result while concealing the others.

A transaction-specific checklist before signing

1. Check the network and token addresses. Similar symbols do not necessarily identify the same asset.
2. Verify the spender and the approved amount. Do not grant permissions you do not understand.
3. Read input, quoted output and actual minimum output, not only the tolerance percentage.
4. Separate network charges, pool fees and any service costs.
5. Check the submission route and protection conditions, including what happens when an order remains pending.
6. Review expiry, partial-fill behavior and cancellation procedures where applicable.
7. Read the final confirmation again: a refreshed quote may change the route or expected output.

This checklist does not certify the token or contract as safe. It makes the conditions of one operation explicit. A reputable router does not make every token safe to hold, and a price limit cannot protect against every harmful authorization.

For a fair comparison between two quotes, record the same input amount, destination asset, time and fee assumptions. A quote captured several minutes earlier is not a reliable benchmark for a later execution if the market has moved. Keep estimated network costs separate from costs actually paid, and state whether token amounts are measured before or after service charges. This record does not predict which route will win next time. It makes the comparison reproducible and helps distinguish a routing difference from a change in the underlying market.

What to inspect after the swap

Check transaction status and the quantities actually received. Technical success means execution met the applicable rules, not that it achieved the best possible market-wide price. Keeping the original signing details makes it possible to compare the outcome with the conditions accepted at the time.

If an operation is pending, do not repeat it blindly. Distinguish an unincluded transaction from an expired order, a revert or a slow interface update. Follow the instructions for the wallet and route involved: a retry or replacement can change both costs and visibility.

If you suspect a sandwich, gather hashes, timestamps and the original quote before drawing a conclusion. Never publish seed phrases, keys or sensitive wallet exports when seeking help. Public transaction information and the swap’s conditions are useful evidence; control of the wallet is not required for an ordinary technical review.

Questions about MEV protection

Does zero tolerance solve the problem?

No. It can prevent some execution below a quote, but changing conditions can also prevent execution. It does not improve a poor starting quote, remove fees or eliminate contract risk.

Does a failed swap prove an attack?

No. Several technical constraints can cause failure. Attribution requires evidence; a generic wallet error and an unfavorable price movement are not sufficient by themselves.

Does private submission make the trade anonymous?

Do not confuse limited pre-inclusion distribution with anonymity. It does not remove on-chain information or imply the provider receives no data. Inspect the visibility rules of the specific service.

Which route is best for every swap?

There is no universal answer. Size, liquidity, costs, urgency and product constraints change the comparison. A defensible choice states those assumptions instead of replacing them with a MEV-protected label.

Conclusion: inspect execution rather than looking for an absolute guarantee

Understanding MEV in swaps means reading a swap as a set of conditions: quote, minimum output, route, permissions and costs. Useful checks distinguish those elements and make it possible to compare what was signed with what actually happened.

Protections can reduce particular exposures, but retain limitations and dependencies. Verify minimum output and the submission channel before signing, then retain the outcome for a consistent comparison. The goal is not a promise of zero risk, but an informed view of the risk that remains.