> For the complete documentation index, see [llms.txt](https://onchain-basics.gitbook.io/onchain-basics-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://onchain-basics.gitbook.io/onchain-basics-docs/dex-slippage-bounds-for-integrators.md).

# DEX Slippage Bounds for Integrators

When a swap must execute within a known price budget, quote against current pool state and encode that budget as an on-chain minimum output; refresh both when the quote ages. A deadline limits how long the transaction can wait, but only the output bound rejects execution at an unacceptable price.

### How do you turn a quote into an execution bound?

Build the quote from the exact chain, pool, fee tier, route and raw input amount that the transaction will use. For concentrated-liquidity pools, output depends on active liquidity across the ticks the swap crosses, so a spot-price calculation alone is not an executable quote. If your integration needs to handle QuickSwap V3, check the router ABI for that specific deployment before encoding parameters; the linked [QuickSwap crypto](https://ameblo.jp/pokke-web3/entry-12982172274.html) article gives the trading context.

For exact-input swaps, compute amountOutMinimum = floor(quotedOut × (1 − tolerance)) in the output token’s smallest units. Say a quote returns 987.40 USDC for 1,000 USDC of input and your chosen tolerance is 0.5%: the minimum is 982.463 USDC, encoded as an integer using the token’s decimals. The quote already reflects pool fees and modeled price impact; the tolerance is a separate allowance for state changes before execution.

For exact-output swaps, protect the input side instead: set amountInMaximum = ceil(quotedIn × (1 + tolerance)). Round the bound in the user-protective direction and never convert through floating-point numbers. A one-unit rounding error can cause a revert for low-decimal tokens or unintentionally loosen the bound.

### What should happen between quote and transaction?

Simulate the encoded call against recent state, then submit promptly with a short expiry. A deadline around 30–120 seconds is a common starting range, adjusted for the chain’s block cadence and expected wallet delays; it is not a substitute for amountOutMinimum. QuickSwap deployments can use different router interfaces across networks, so derive the deadline field and price-limit behavior from the deployed contract rather than assuming every V3 fork has the same parameters.

On-chain execution checks the bound against the pool state when the transaction runs. If another swap moves the price so the result falls below amountOutMinimum, the call reverts; the user still pays gas for that failed transaction. A generous tolerance reduces reverts but lets execution drift further from the quote, including from adverse transaction ordering. The Bank of Canada’s research on automated market makers describes how trade size and pool liquidity affect execution price, which is why one fixed tolerance is a poor policy across routes.

For example, if a 1,000 USDC trade quotes 987.40 USDC output, a 0.5% bound permits up to 4.937 USDC less output than quoted. If that allowance is too large for the user’s intent, choose a tighter bound or split the trade; widening it merely to make the transaction pass weakens the protection. If the route includes multiple pools, quote and bound the whole route, not each hop independently.

* Revert on minimum output: refresh state and quote before offering a retry.
* Deadline expiry: rebuild the transaction with a new quote and deadline.
* Unexpected token behavior: account for transfer taxes or rebasing; standard exact-input paths may mismeasure received amounts.
* Price-limit partial fill: inspect the actual input spent and output received when a nonzero square-root price limit is used.

For QuickSwap integrations, I would default to a quote-derived bound and a short deadline, then let the caller select a tighter tolerance where execution certainty matters more than completion. Log the quoted amount, bound, pool state block and final receipt so failed or unexpectedly poor executions can be diagnosed.

### What integrators ask before shipping

#### Does slippage tolerance include price impact?

No. Price impact is the quote’s expected effect from trading against the current pool liquidity; tolerance covers additional movement between quoting and execution. The 987.40 USDC example already includes modeled fee and impact. Applying 0.5% to that output creates a 982.463 USDC floor, rather than adding the modeled impact a second time.

#### How often should the integration refresh a quote?

Refresh immediately before signing or submitting, and whenever the route, amount, pool state or user tolerance changes. A quote is a state-dependent simulation, not a reservation of liquidity. A short deadline limits stale pending transactions, but it cannot make an old quote current or guarantee inclusion before expiry.

#### What if the router supports a price limit?

A price limit can stop a swap from crossing a chosen boundary, which is useful when the user cares about the terminal pool price as well as minimum output. However, reaching that limit can produce a partial fill on routers that permit it. Check returned amounts and unspent input, and confirm the target deployment’s semantics before relying on the parameter.

#### Should the app retry after a slippage revert?

Retry only after fetching fresh pool state and obtaining a new user-approved bound. Replaying the same calldata cannot fix a changed price and may fail again; silently increasing tolerance can execute at a price the user never accepted. Keep the original quote and revert reason available for diagnosis.

Quote the full route, derive integer bounds from the user’s tolerance, and expire stale transactions quickly. That gives integrators a clear, testable rule: execution either meets the encoded limit or reverts.