Price Impact and Slippage: Read Swap Output, Limits and Costs

Identify which comparison each number describes

Price impact describes how the trade itself affects available pricing. A larger order relative to liquidity can receive a less favorable average rate even if nobody else trades between preview and execution. A change from a saved preview to the eventual result is a separate comparison. Interfaces may define their displayed percentages differently, so confirm the reference used in each field.

For example, a small-size reference suggests 100 output units, while a preview for your actual size offers 98. If execution delivers 98, nothing changed relative to that preview. The earlier two-unit difference needs its own explanation, including order size, route and included fees. The Uniswap explanation of price impact discusses the role of trade size and liquidity; its terminology should be read within that product’s context.

Work through a simple constant-product model

Assume a hypothetical pool begins with 1,000 units of token A and 1,000 of token B. For this calculation only, their product stays at 1,000,000. Ignore all fees, external transactions and rounding until displaying results. This model illustrates a mechanism; it does not describe every pool design, protocol version or liquidity range.

Adding 100 A makes the A reserve 1,100. The B reserve required by the invariant becomes 1,000,000 divided by 1,100, approximately 909.0909. The output is the difference between the original 1,000 B and that remaining reserve: approximately 90.9091 B. A starting reserve ratio of one-to-one therefore does not mean that an order of any size receives one B for every A.

The mathematical framework is described in the Uniswap v2 pricing documentation. Our example deliberately excludes that implementation’s fee calculation and additional execution details. Its purpose is to make the changing reserve balances visible rather than estimate a live trade.

Keep the unit and denominator consistent

The average output rate is 90.9091 B divided by 100 A, approximately 0.909091 B per A. Compared with a reference of one B per A, output per input falls by approximately 9.0909%. Expressing the reciprocal gives a different-looking figure: 100 A divided by 90.9091 B is approximately 1.1 A per B, or a 10% higher input cost per output unit.

Neither percentage should be copied into the other convention. Label both the direction and denominator. The same care applies when comparing a buy quote with a sell quote or converting a token price into its inverse. A disagreement between percentages can arise from different units rather than an arithmetic error or an additional charge.

Compare alternative sizes from the same starting reserves

Here are three alternative swaps, each starting independently from the original 1,000 A and 1,000 B. They are not sequential transactions. For input q, output is 1,000 − 1,000,000 ÷ (1,000 + q). The average output rate declines as this input becomes larger relative to the hypothetical reserves.

Real routes can involve multiple pools, fee tiers, intermediating assets and liquidity concentrated within ranges. Do not use this table to predict their outputs. Refresh the preview for the intended amount instead of multiplying a small test quote by a large number. Also check token decimals: a mistaken unit can turn an intended small request into a much larger one.

Measure what changes after the preview

Suppose a saved full-size preview expects 100 output units after its included route costs. Execution later produces 99.4. The shortfall relative to that preview is 0.6 units, or 0.6%. That is separate from any impact already reflected in the expected 100. Favorable changes are possible too, but an earlier improvement does not guarantee another.

If the interface also displays 2% price impact, do not automatically report a 2.6% total loss. Determine each denominator and whether fees or trade-size effects overlap. Reconstruct the stages using comparable amounts. The Uniswap comparison of impact and slippage is a useful starting distinction, while the exact fields on the current request remain essential evidence.

Read the acceptance condition rather than an assumed charge

For an exact-input example, an expected receipt of 100 and a minimum of 99 means the request accepts a result meeting that minimum under its conditions. It does not impose a fixed one-unit charge. For an exact-output request, the important condition may instead be the maximum input that can be spent. Confirm which quantity you have fixed before deciding what the limit protects.

Check the actual token amounts shown, including rounding. The Uniswap single-swap guide distinguishes exact-input and exact-output patterns. Broadening the accepted range permits a less favorable outcome; it does not improve a quote that already shows a large size effect. If a submitted on-chain swap reverts, inspect network fees separately from the uncompleted asset exchange.

Separate the route, included fees and additional spending

Record the input asset and amount, expected output and acceptance bounds, then additional fees with their currencies. A fee already embedded in the expected output should not be deducted again. A network fee in ETH cannot be subtracted numerically from a USDT receipt as though they were the same unit. Use an explicit conversion rate and timestamp for a common-currency comparison.

The route may change when the amount or market state changes. One visible pool’s reserves do not necessarily describe the entire route. The transfer fee calculator can isolate a subsequent transfer cost, but it does not reconstruct live swap pricing. Keep a later withdrawal or bridge step separate unless the quote explicitly includes it.

Respond to a large impact warning methodically

First verify the network, both token identities and input units. Then review the current route and size-sensitive output. Increasing tolerance does not add reserves to a pool. Splitting a trade also offers no automatic improvement: in our fee-free model, sequential pieces use the reserves left by earlier pieces rather than repeatedly receiving the original rate.

Before signing, save the expected output, minimum receipt or maximum input, route and extra fees. After execution, compare those records with the receipt and actual token movements. A low impact figure does not validate a token contract or establish that it can later be sold. For transaction-status uncertainty, use the transfer helper; for execution-price arithmetic, keep a separate record of the weighted fills and reference.

Continue reading