DEX Swap Slippage vs. Price Impact: Minimum Output and MEV Explained

Price impact is the price change caused by your own order relative to the pool’s available liquidity. It is already part of a realistic quote: a large trade against a shallow pool receives a worse average price than a small trade. Slippage is the difference between the expected output when a quote is prepared and the output when the transaction actually executes. Other swaps, a changing market, a delayed transaction, or a different route can change that result while the transaction waits.

Slippage tolerance is a limit the swap must satisfy. In an exact-input trade it is commonly expressed as a minimum output; if execution falls below that amount, the contract can revert. It does not undo price impact included in the quote, and it does not say how much slippage will occur. Uniswap’s Price Impact vs Price Slippage guide draws this distinction. Interfaces may calculate or label estimates differently, so do not assume every “impact” percentage uses an identical benchmark.

An order-book exchange matches orders waiting at different prices. A constant-product automated market maker instead prices a swap against token reserves. In a simplified two-token pool, balances x and y follow x × y = k. Buying more of one token removes more of it from the pool and adds the other, so the exchange ratio changes during the trade. The average fill gets worse as the order becomes large relative to usable depth.

This formula is a model, not a universal DEX rule. Uniswap’s developer guide explains that v2 uses the constant-product relationship, while v3 and v4 apply liquidity within chosen price ranges and can include hooks or different fee behavior. A displayed quote can combine pools or venues. Compare expected output for this exact size and route, not the token’s last chart price or a pool’s headline total value. See how Uniswap swaps work for protocol-specific mechanics.

Assume a toy pool contains 100 ETH and 200,000 USDC, with no swap fee, no external price move, and a constant-product curve. The initial ratio is 200,000 ÷ 100 = 2,000 USDC per ETH. A trader sends 10,000 USDC, so the pool’s USDC reserve becomes 210,000. To preserve the product, the ETH reserve becomes 20,000,000 ÷ 210,000 = 95.238095 ETH. The trader receives about 4.761905 ETH.

At the original ratio, 10,000 USDC would have bought 5 ETH. The shortfall is 0.238095 ETH, or about 4.76% of that no-impact amount. The average execution price is 10,000 ÷ 4.761905 = 2,100 USDC per ETH, 5% above the pre-trade ratio; the post-trade marginal pool price is 210,000 ÷ 95.238095 = 2,205 USDC per ETH. These are different comparisons: no-impact output shortfall, average execution price, and ending marginal price. A real quote also includes fees and the route’s actual liquidity shape. This hypothetical calculation is not a market forecast.

Keep the same hypothetical reserves, but now assume a 0.30% fee charged against the input under a specific fee convention. The amount used in the constant-product quote is 10,000 × (1 − 0.003) = 9,970 USDC, so the output is 100 × 9,970 ÷ (200,000 + 9,970), or about 4.748297 ETH. That is about 0.013607 ETH less than the 4.761905 ETH fee-free result for the same curve. Against the 5 ETH available at the opening ratio, the total shortfall is about 0.251703 ETH. Using the fee-free curve result as an intermediate step attributes about 0.238095 ETH to the curve and another 0.013607 ETH to the fee adjustment; that split depends on the comparison convention.

The 0.30% is a hypothetical rate, not a universal DEX fee. This input-adjustment formula follows the fee arithmetic used by Uniswap v2’s getAmountOut library; the contract still records the full input in its reserves, so an effective pricing input does not mean only 9,970 USDC reaches the pool. Other pools can charge a different rate, take a fee from another amount, or combine several fee components. A multi-hop route can incur a pool fee at each hop in addition to an interface fee and network cost. Check the actual route and its fee breakdown rather than applying this example’s percentage to every swap.

Suppose a route quotes 4.7619 ETH for the same input and the interface applies a 1% tolerance. The minimum output is about 4.7143 ETH: 4.7619 × (1 − 0.01). An execution returning 4.72 ETH clears the bound; one returning 4.70 ETH falls below it and should revert under that route’s protection rule. The quote remains 4.7619 ETH. The minimum is only the worst output the submitted transaction is willing to accept.

A narrower bound can reject a valid trade if prices move during congestion or the quote becomes stale. A wider bound can allow a worse execution before rejection. Uniswap’s developer documentation describes minimum output as a user-level guard, but parameters and failure behavior depend on the router or product. A reverted transaction may still incur a network cost depending on the chain and transaction path. Do not raise tolerance just to clear an error: first check whether the quote, token, route, fees, or network conditions changed.

Between signing and inclusion, another trade can change pool reserves. Arbitrage may move a pool toward prices on other markets; a fast market move may also make the old quote unrealistic. Your order can stay unchanged while its final output changes. A gas bid may affect inclusion priority on some chains, but it is not a universal guarantee of timing or price. A deadline can reject a transaction that remains pending too long; it cannot ensure the earlier quote.

Keep the quote-time estimate separate from the final receipt. Price impact belongs to the trade’s expected interaction with the route’s liquidity. The extra change after the quote is prepared belongs to execution slippage under the interface’s reference method. An interface may combine them in one warning or use a different reference, so record the quote, timestamp, route, and minimum output before signing if you need to reconcile the result.

A sandwich is one form of maximal extractable value, or MEV. A searcher sees a pending swap, places a trade before it that shifts the pool price against the user, lets the user’s trade execute, then trades afterward to unwind. The user can receive an output above the submitted minimum while paying a worse price than the original quote. A tight output bound can make some adverse executions revert, but it cannot prevent every ordering strategy or remove ordinary market movement.

Ethereum.org’s MEV guide explains sandwich ordering and why affected users face worse execution. MEV is broader than attacks: arbitrage can move a pool toward prices elsewhere, while sandwiching can worsen a user’s fill. Private transaction paths such as Flashbots Protect describe their own protections and trade-offs. They are chain- and provider-specific, do not guarantee a particular price, and add reliance on another transaction path; check current coverage before relying on one.

The token amount received is not the total cost of a swap. Separate the pool fee, any applicable interface fee, network cost, price impact already in the quote, execution slippage, and token-specific transfer or buy/sell fees. Some tokens have non-standard transfer behavior; a swap can fail or transfer a different amount than a plain ERC-20 assumption suggests. Approval transactions may be separate from the swap and can carry their own network cost.

A route aggregator may split a trade across pools or use several hops to improve quoted output. That can lower impact for one route while adding contract calls, fees, or token-specific risks. A quote does not guarantee best execution across all venues. Compare exact input, expected output, minimum received, pool path, fee breakdown, network, and deadline. For related mechanics, read the token approvals guide and Ethereum gas fee guide.

Before signing, verify the network and token contract addresses; input amount; route and pool depth; displayed price impact; expected output and minimum received; slippage setting; deadline; pool, interface, and network fees; and token warnings. If the output looks unusually small, compare a smaller hypothetical input or another route’s quote. If the transaction fails, inspect the reason before resubmitting. A failed attempt may still cost a network fee depending on the chain and transaction path.

After execution, compare the receipt’s actual token amounts with the quote and minimum bound, then record the route, fees, network cost, and timestamp. Do not treat the minimum as expected output or assume a successful swap was protected from every adverse execution. This article’s arithmetic uses a fee-free constant-product example. Concentrated-liquidity pools, multi-hop routes, token taxes, oracle references, and network-specific transaction ordering can produce different results.

The example above fixes the input at 10,000 USDC and sets a minimum ETH amount to receive. An exact-output swap starts with the desired ETH amount instead; because the USDC required can rise before execution, integrations commonly set a maximum input bound. Uniswap’s developer guide describes minimum output for exact-input trades and maximum input for exact-output trades as separate user protections.

A displayed 1% therefore does not mean every swap protects the same token amount. Check which side is fixed, which token the floor or cap refers to, and whether the route quote includes pool fees or other charges. A minimum amount is denominated in the output token, not a guarantee of its dollar value. If that token’s market price moves, a swap can satisfy its token-quantity bound while its dollar-equivalent result changes. Splitting one trade into several sequential swaps against the same pool also does not erase the curve impact in a fee-free constant-product model: the final reserves are the same as one combined trade. Splitting can add network costs and create more moments for other transactions to intervene; splitting across independent pools is a different routing choice that must be evaluated with each pool’s depth and fees.