An automated market maker uses pool rules to calculate swap output. Your average execution can differ from the starting reserve price even without an external market move. This guide calculates a hypothetical 100-unit swap, then separates order-size effects, fees and later slippage. The simple constant-product model does not describe every pool design.
Assumes a constant-product pool, no fees, no token deductions and no intervening transactions.
BTKWIN.COM · EDUCATIONAL EXAMPLEWhat changes inside a liquidity pool
An order book matches orders at specified quantities and prices. In the simplified pool considered here, traders exchange against reserves of two assets and a rule determines how reserves change. Their initial ratio gives context for a very small trade, not a promise that every amount executes at that same price.
The Uniswap v2 swap documentation describes constant-product pools. Denote reserves as x and y, with x × y = k before fees in the teaching model. Adding X and withdrawing Y increases one reserve and decreases the other.
The pool is therefore not a warehouse selling every unit at the initial ratio. The swap itself changes the reserves. This helps explain why an interface can display an indicative price and then show less output when the actual trade amount is entered.
Calculate a 100-unit input step by step
Assume reserves of 1,000 X and 1,000 Y, no fees, no token-specific deductions and no other trades. Their product is one million. Although the starting ratio is one to one, adding 100 X does not yield 100 Y under the curve.
After input, X reserves become 1,100. Keeping the product at one million leaves Y reserves of one million divided by 1,100, approximately 909.09. Output is the original thousand minus that remainder, approximately 90.91 Y. Keep full precision during calculation and round for display.
| Illustrative calculation | Result |
|---|---|
| Initial product: 1,000 × 1,000 | 1,000,000 |
| New X reserve: 1,000 + 100 | 1,100 X |
| Remaining Y: 1,000,000 / 1,100 | About 909.09 Y |
| Y sent: 1,000 − remaining Y | About 90.91 Y |
The direct no-fee formula is output Y = reserve Y × input X / (reserve X + input X). Here that is 1,000 × 100 / 1,100. Rounding displayed intermediate values can create small apparent discrepancies, so do not treat those display differences as violations of the underlying equation.
Average execution differs from the final marginal price
Paying 100 X for approximately 90.91 Y gives an average cost of 1.1 X per Y. That summarizes the whole trade. A marginal price derived from the ending reserves instead describes the next sufficiently small trade. It is not the average price already paid.
Percentage definitions also matter. Output of 90.91 rather than one hundred is a 9.09% shortfall against the starting output reference. Average cost of 1.1 rather than one X per Y is a 10% increase. The percentages use different denominators and do not contradict one another.
If two interfaces show different impact values, check reference price, fee inclusion, direction and whether they describe average execution or ending marginal price. Preserve a numerical example with the definition rather than assuming an identically named field has an identical calculation.
Use active liquidity rather than an unrelated total
A fictional pool with 10,000 X and 10,000 Y at the same initial ratio gives approximately 99.01 Y for a 100 X input before fees. The input is only 1% of X reserves rather than 10%, so the output is closer to the starting ratio.
A protocol-wide total or assets across many pairs do not establish depth in the pool used by your route. The concentrated-liquidity documentation also explains allocation within price ranges. The amount active around the current price can differ from a headline total.
Do not transfer this elementary reserve formula unchanged to every version labelled AMM. Identify the pool design and actual route. For practical comparison, use the previewed net output for the intended quantity and the conditions governing that preview.
Include a fee without deducting it twice
Introduce an illustrative 0.3% input fee and assume only the net input enters the output calculation. Effective input becomes 99.7 X. Using the original reserves, output is 1,000 × 99.7 / 1,099.7, approximately 90.66 Y instead of 90.91.
The user still pays 100 X. If the pool retains the fee in actual reserves, do not conclude that the final actual reserve product remains exactly equal to its initial value. The teaching no-fee invariant and the real handling of fees need separate treatment.
Network execution or a separate approval can create other costs in a different asset. An ETH-denominated fee cannot simply be subtracted from Y units without conversion. The transfer-fee calculator can organize entered charges, but does not simulate an AMM curve or retrieve pool pricing.
Price impact is separate from later slippage
Order-size impact exists in the example even if nobody else trades. Slippage concerns a difference between the preview and execution under the interface’s definition. Other transactions, elapsed time or routing changes can affect that difference. The Uniswap explanation distinguishes the concepts.
For a preview of approximately 90.91 Y, a 1% adverse-output allowance corresponds to a minimum near ninety Y in this illustration, subject to precision and actual execution rules. It does not restore output to one hundred or remove the curve’s effect. It changes the acceptance condition relative to the preview.
Before increasing a tolerance after failure, review what changed, the minimum received, route and charges. A wider allowance can make a materially worse outcome satisfy the request. It is not a remedy that creates missing liquidity.
Splitting the order does not reset the pool
In the same no-fee model with no external trades, splitting 100 X into two inputs of fifty leaves the second trade facing changed reserves. The first yields approximately 47.62 Y and the second approximately 43.29 Y. Combined output remains approximately 90.91 Y under those assumptions.
Real intervals between transactions can involve other trades, route changes or extra network costs. That means splitting is not universally better or worse. Compare total costs and outcomes while separating the effect of waiting from the effect of splitting the amount.
Before relying on a preview, record asset identities, chain, pool version, quantity, output, impact, fee, minimum and network costs. Review spender permissions separately. A visible price does not guarantee a sale of any quantity or establish token safety. Use a fresh preview rather than an old screenshot as the relevant conditional quote.
Continue reading
English content and examples reviewed: 27 October 2026. Read the Arabic edition.
