A swap quote describes an expected outcome at a particular moment. Before the transaction executes, pool balances can change and other transactions can be placed ahead of yours. Those changes can make the result worse even when the swap contract follows the instructions you signed.
Maximal extractable value, usually shortened to MEV, concerns value captured through transaction inclusion, exclusion, or ordering. For a person making a token swap, the practical issue is how the route, price limit, and submission method affect execution. Understanding these mechanics helps you evaluate protections without assuming that any single setting can eliminate risk.
MEV is broader than sandwich attacks
Transaction ordering creates opportunities in several activities. Arbitrage can bring prices across trading pools closer together. Liquidations can enforce a lending protocol's collateral rules. Sandwich attacks are another form, and they can directly worsen the price a swap user receives. The term MEV therefore describes a broad economic phenomenon rather than one uniform attack.
Ethereum's official MEV documentation describes these categories and their effects. The important distinction for users is between ordinary market activity, the price effect of their own order, and strategically arranged transactions that extract value from their execution. A poor fill alone does not tell you which explanation applies.
How a sandwich changes the trading environment
In a common sandwich pattern, an actor learns about a pending swap and arranges trades around it. The first trade changes the pool price in a direction that is unfavorable to the targeted user. The user's swap then executes against that changed state. A later trade unwinds the actor's position, potentially capturing value after fees and other costs.
Consider a hypothetical buyer exchanging token A for token B in an automated market maker. Another buyer acquires B just before the user's swap, making B more expensive in that pool. The user's transaction accepts the higher price because it remains within the permitted execution bounds. The earlier buyer then sells B after the user's purchase. This illustrates ordering risk; actual profitability depends on liquidity, fees, competing transactions, and successful execution.
The user's wallet may have approved the correct router and the intended token. The problem can occur within an otherwise valid swap. Contract approval safety and execution-price protection address different parts of the transaction.
Separate price impact from slippage
Price impact is the change in pool pricing caused by the trade itself. A large order relative to available liquidity generally has more impact. Slippage describes the difference between an expected outcome and the outcome available when the transaction executes. Other trades, ordinary market movement, and adversarial ordering can all contribute.
A displayed quote commonly already incorporates the route's estimated price impact. The slippage tolerance then sets an additional boundary around the quoted execution. Read the interface's definitions because applications may calculate or label these fields differently. Adding a price-impact percentage and a slippage percentage without examining their bases can misstate the expected cost.
The routing guide explains how pool depth and the path between assets influence a quote before any pending-transaction risk is considered.
A minimum output is a boundary, not a forecast
For a simple exact-input swap, an application may translate your tolerance into a minimum amount received. Imagine a quote of 1,000 hypothetical units and a displayed minimum of 990. The contract can accept an outcome at or above that boundary, subject to its other checks. The 10-unit gap is permitted deterioration in this illustration; it is not an additional fee that must be paid.
If the minimum falls to 950 after the tolerance is widened, the transaction permits substantially more adverse movement. That flexibility may help an order execute in changing conditions, while also creating more room for unfavorable execution. Do not interpret a successful transaction as evidence that the wider setting was economical.
A very tight bound has a tradeoff too: normal state changes may cause execution to revert. No single tolerance is appropriate for every asset, amount, liquidity condition, or route. Inspect the actual minimum and decide whether the possible outcome is acceptable before signing.
Private submission changes who can see the order
Some services send a transaction through a private channel instead of immediately broadcasting it to the public transaction pool. Reducing early public visibility can make certain front-running strategies harder. The result depends on the service's architecture, which parties receive transaction information, and the ordering rules used downstream.
Evaluate the details behind a “MEV protection” label. Does the service share full transaction data with multiple builders? Does it disclose selected hints? Can it fall back to public submission, and under what conditions? Does the selected network support the advertised behavior? These questions matter more than the badge alone.
Private routing is not a blanket guarantee of the quoted price, inclusion speed, confidentiality, or successful execution. You still depend on the route's contracts and token behavior. Different privacy settings can also trade faster inclusion against broader information sharing. Read the current configuration rather than relying on a description from an earlier version.
Liquidity and order design also matter
A route with deeper usable liquidity may reduce the price movement caused by the trade, but the quoted output and total costs still need comparison. Splitting one order across pools can change execution characteristics. Manually splitting it into many transactions adds separate gas costs and creates several moments when market conditions can move.
Do not assume that smaller pieces are automatically cheaper or protected. In an unchanged pool, a sequence of same-direction trades still changes the reserves cumulatively. Any benefit depends on what happens between those trades, the available routes, and the fees. Compare the complete proposed execution rather than treating transaction count as a safety measure.
Limit orders and intent-based systems may offer a different set of execution conditions. For example, an order can specify a price at which a filler is allowed to complete it. That can constrain the result, but the order may remain unfilled, expire, or require cancellation. Those mechanisms also have their own contracts and authorization requirements.
Account for failed transactions and network fees
An included Ethereum transaction that reverts can still consume gas for computation already performed. A failure at the minimum-output check does not imply that the network work was free. A transaction rejected before inclusion, or never included at all, is a different case. Check the receipt rather than inferring fees from the interface's error message.
Repeated retries can therefore change the economics of a small swap. Raising the slippage setting after each failure may convert a visible failure into an expensive successful execution. First identify whether the problem is an expired quote, insufficient liquidity, a token restriction, inadequate gas configuration, or another condition. The swap cost guide explains how to compare network fees with the amount ultimately received.
Use evidence when reviewing an unexpected result
If a fill seems wrong, preserve the quote time, signed minimum output, transaction hash, route, gas cost, and actual token balance changes. Compare the execution with the conditions you authorized. Explorer records can show transactions and pool events, although interpreting them may require understanding several contracts in the same route.
A nearby purchase and sale are not, by themselves, proof of a sandwich. Ordinary arbitrage and unrelated activity can resemble parts of the pattern. Claims of an attack need evidence connecting the transactions and their economic effect. Avoid presenting the entire gap between a quoted value and the received value as attacker profit; fees and normal price movement may explain part of it.
Build a consistent pre-swap review
Before submission, check the route, quote age, expected output, minimum output, and gas estimate. Inspect the service's execution and privacy conditions. If the minimum is unacceptable, revise the trade or wait rather than authorizing an outcome you already consider too costly. Refresh stale information before confirming.
Review spending permissions separately using the token approval and wallet safety guide. After submission, track the transaction's actual status before retrying it. A delay does not necessarily mean failure, and a successful receipt should be followed by a check of the resulting assets and costs.
Evaluate protection as a set of controls
Good execution review combines understandable pricing, appropriate bounds, suitable liquidity, careful submission, and evidence after the trade. Each control addresses a particular failure mode. Together they make the decision clearer, while leaving the limits of market conditions, network operation, and contract behavior visible.
