Exact-Input vs Exact-Output Crypto Swaps

An exact-input swap fixes how many input tokens the instruction should spend and sets a minimum acceptable output. An exact-output swap fixes the requested output and sets a maximum input. With ordinary tokens and a successful full swap, the first keeps spending fixed while receipts vary; the second keeps receipts fixed while spending varies. Neither mode freezes a quote or guarantees execution.

Choose which swap amount must stay fixed

“Sell 120 X” and “acquire 5,893.857363 Y” can describe the same initial quote. They authorize different responses when the pool changes before execution.

Uniswap's current v4 swap guide describes both modes this way. The distinction is useful across swap interfaces, but the actual router, token behavior and settlement instructions determine what a particular call does.

Choose the side that represents the requirement. If the spending budget is fixed, specify exact input. If a later operation needs a particular token quantity, specify exact output. The other field supplies a boundary, not another exact amount.

A minimum output is not the expected receipt: a successful instruction can deliver more. A maximum input is a ceiling: a successful instruction can spend less. Setting an exact-output maximum equal to the entire wallet balance does not mean that balance will necessarily be consumed, although it permits spending up to that bound within the call's rules.

Build exact-input and exact-output tickets against one pool

Consider an illustrative pool with 8,000 X and 400,000 Y. Both hypothetical tokens have six decimals. It follows Uniswap v2 constant-product pricing with the documented 997/1,000 input adjustment, equivalent to a 0.30% swap fee. Assume ordinary transfers, no separate provider charge, no liquidity changes and no other activity except the intervening swaps specified below. Y is a token unit, not an assumed dollar.

This deliberately uses the v2 model so both directions can be checked directly. Uniswap's v2 pricing documentation distinguishes forward calculation of output from backward calculation of required input. The same reserve formula should not be substituted for a concentrated-liquidity simulation.

Start with 120 X of gross input. Its fee adjustment leaves 119.64 X for pricing. Multiply that effective input by the 400,000 Y reserve and divide by 8,000 X plus 119.64 X. Before token rounding, output is approximately 5,893.857363134326 Y.

Here, 120 X means 120,000,000 raw X units, and the rounded quote is 5,893,857,363 raw Y units. Keep those integers in the instruction record alongside the human-readable amounts.

The v2 library at a pinned source revision performs integer calculations in token base units. Its output calculation discards the fractional raw unit, giving 5,893.857363 Y. For required input, multiply the raw X reserve by the raw Y target and by 1,000. Divide by 997 times the Y reserve remaining after that target, discard the fraction and add one raw X unit. Asking for that rounded output requires 120.000000 X in the starting state.

Construct these alternative instructions:

For this example only, define the first boundary as 99% of quoted output, rounded down to six decimals. Define the second as 101% of quoted input. These are explicit teaching conventions for a 1% allowance on each variable amount, not recommended tolerances or a claim about every interface's percentage conversion.

With unchanged reserves, both tickets produce the same token exchange: 120 X for 5,893.857363 Y. The exact-output ticket leaves 1.2 X of its maximum unused. The exact-input ticket receives more than its floor.

The same intervening trade can separate their outcomes

Now suppose someone else sells X to this pool before either ticket executes. Each row below is a separate alternative starting from the original reserves. The 20 X, 40 X and 60 X cases are not successive trades.

In the 40 X case, the preceding trader receives 1,984.109215 Y. Reserves become 8,040 X and 398,015.890785 Y. The full 40 X enters the reserve balance; the fee adjustment applies to pricing. Uniswap's fee explanation confirms that v2 swap fees enter pool reserves. Updating the reserve with only 39.88 X would produce an inconsistent next quote.

Against that state, the exact-input ticket receives 5,835.872804 Y. That is 0.954015 Y above its minimum, so its output check passes. Its gross spending remains 120 X.

The exact-output ticket still requests 5,893.857363 Y. It now needs 121.210228 X, exceeding the 121.2 X cap by 0.010228 X. For the documented direct v2 Router02 token swap, the maximum-input check rejects that call. The router does not turn it into a smaller successful acquisition. The corresponding exact-input call checks the final output against its minimum. Both behaviors are visible in the pinned Router02 source.

The first instruction accepts receiving fewer Y while preserving its X expenditure. The second refuses to exceed its X cap while preserving its requested Y quantity. Which result is useful depends on the quantity the operation needs to preserve. The identical “1%” labels apply to different amounts and authorize different outcomes.

The arithmetic was checked in integer base units, including each preceding reserve update. Forward-pricing every calculated exact-output input reaches the target; reducing that input by one raw X unit falls short in all four states. That check catches a rounding mistake a six-decimal display could hide.

Locate the unused maximum before calling it a refund

In the 20 X case, the exact-output ticket spends 120.604344 X. Its cap exceeds actual spending by 0.595656 X. Where those tokens end up depends on the payment path.

The direct v2 Router02 token function pulls the calculated input from the caller. It does not first take the full token maximum, so unused headroom stays with the caller. A wrapper can handle funding differently.

For example, Uniswap's v3 single-swap teaching contract transfers the maximum from the user into the wrapper before an exact-output swap, then returns the unused amount and resets its router allowance. That refund belongs to the documented wrapper's logic. It should not be assumed for an arbitrary integration.

Before signing, identify who holds any prefunded amount, which call returns it and who receives it. An unused allowance is also different from an unused balance: the token allowance guide explains the separate authority left behind after spending. A per-swap cap does not by itself erase a broader token approval.

Separate quantity certainty from price and completion

Exact output fixes a token quantity within the specified successful operation. It does not make the original quoted cost permanent or establish that the quote is attractive. Both swap modes still face the liquidity available along the selected route.

The price-impact and slippage comparison separates the cost already embedded in a sized quote from later deterioration. In the illustrative pool, the starting reserve ratio is 50 Y/X, while 120 X buys fewer than 6,000 Y after the curve and fee. Choosing an exact-output ticket cannot remove those mechanics.

Similarly, mode choice does not prove that a route is the best available. The split-routing worked example compares complete plans after their costs. Compare routes using the same fixed requirement: the same X input for an output comparison, or the same Y target for an input-cost comparison. Comparing a 120 X sale with a different-sized acquisition answers a different question.

Treat the table's “pass” labels as amount checks, not complete transaction simulations. Missing permission, insufficient spendable balance, an expired deadline or incompatible transfer behavior can still prevent execution. If a transaction is included and fails on Ethereum, it can still incur a gas charge; Ethereum's gas documentation distinguishes computation charges from successful state changes. A swap's token-input cap does not cap separately paid network fees.

Also inspect additional price limits. The v3 single-swap guide notes that a nonzero pool-price limit can cause less than a specified input to be swapped. This is why an “exact input” label alone is insufficient to infer full consumption across every implementation. Check the full call and its refund behavior.

Save an amount receipt before signing

Use this worksheet to turn a mode label into a reviewable instruction:

For a command-based plan, review Universal Router failure boundaries alongside the amount limits. For an operation that uses acquired tokens immediately, add the funding and settlement questions in flash swaps versus flash loans. A correct quantity calculation is only one part of a complete transaction.

After execution, record actual input, recipient output and any returned balance. Compare them with the signed fixed amount and opposite bound, then account for network costs separately. Keep the same record if an attempt fails before refreshing the quote or changing a boundary.

Finish the review with one sentence containing both quantities: “Spend exactly this much and receive at least that much,” or “Receive exactly this much and spend at most that much.” If that sentence does not describe the intended exchange, change the instruction before signing it.