> For the complete documentation index, see [llms.txt](https://crypto-glossary-hub.gitbook.io/crypto-glossary-hub-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://crypto-glossary-hub.gitbook.io/crypto-glossary-hub-docs/how-should-integrators-set-swap-slippage-limits.md).

# How Should Integrators Set Swap Slippage Limits?

Set a THORChain swap’s price floor from the user’s loss budget, then request the quote with *liquidity\_tolerance\_bps* so the limit is encoded in the swap memo. This gives execution a defined minimum output after fees; streaming settings can reduce price impact, but they do not replace that floor.

### What does the tolerance protect?

*liquidity\_tolerance\_bps* limits how far the eventual output may fall below the quote’s *expected\_amount\_out*. The quote endpoint converts the tolerance into a minimum-output value in the memo, which THORChain checks when processing the swap; if the output misses the floor, the swap is refunded.

Basis points are hundredths of a percent: 100 bps equals 1%. For example, if a quote returns 1.842 ETH and the integrator chooses 75 bps, calculate the floor as 1.842 × (1 − 75/10,000) = 1.828185 ETH. In production, do the calculation in the quote’s integer base units and preserve the API’s rounding behavior rather than converting through floating-point numbers.

Use *liquidity\_tolerance\_bps* rather than the legacy *tolerance\_bps* when the intended bound is on user proceeds. The THORChain Dev Docs explain that the older parameter calculates its limit from the input value and does not account for swap or outbound fees, so it can reject a trade even when its net output is within the user’s budget.

### How should you choose the number?

Choose the tolerance from the maximum acceptable shortfall, not from the route’s displayed price impact. A tighter bound protects the user but increases refunds when pools move between quote and execution; a wider bound improves completion odds but authorizes a worse fill. There is no single safe default across routes or trade sizes.

For a liquid route, you might expose a limit around 50–100 bps; a deeper shortfall budget, such as 500 bps (5%), should be an explicit user or product choice. Reject values at or above 10,000 bps, which the endpoint disallows, and make the displayed minimum net output agree with the amount encoded in the memo.

Streaming swaps split execution into subswaps to reduce price impact. The THORChain Dev Docs say that when *streaming\_quantity* is omitted or zero, the protocol selects a quantity targeting 5 bps of slippage per subswap; *streaming\_interval* sets the blocks between them, with 1 block a reasonable starting point for deeper, active pools and longer intervals giving arbitrageurs more time on shallower pools. Streaming can improve expected execution, but it takes longer and is not a substitute for an output floor.

### What should the integrator check before submission?

Fetch a fresh quote immediately before submission, then compare its net *expected\_amount\_out*, fee breakdown, expiry, and inbound details with what the user approved. This matters because a [how to check thor swap routes](https://ameblo.jp/zynnper23/entry-12982259983.html) decision depends on the current route and quote, while a stale quote can leave the interface displaying a floor that no longer corresponds to the generated memo. THORChain’s quote guidance also documents a rate limit of one request per second per IP, so debounce input-driven requests and refresh at submit time.

Keep this control scoped to the THORChain leg: thor swap may aggregate routes involving other liquidity sources, whose execution constraints can differ. A tolerance error calls for a refreshed quote or an informed choice to widen the user’s limit; a minimum-swap error instead means fees dominate the trade and should be handled against *recommended\_min\_amount\_in*, not by relaxing slippage. I would choose differently only when the user explicitly accepts a larger shortfall or the selected route is shallow enough that its current quote cannot meet the product’s completion target.