> For the complete documentation index, see [llms.txt](https://token-swap-manual.gitbook.io/token-swap-manual-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://token-swap-manual.gitbook.io/token-swap-manual-docs/thor-swap-slippage-limits-for-a-large-cross-chain-order.md). # thor swap slippage limits for a large cross-chain order A large thor swap can enforce a price floor on a pool-based route if you set the minimum output from a fresh, fee-inclusive quote and accept the route’s refund rules. THORSwap compares cross-chain routes, but the displayed quote, the slippage limit and the amount you finally receive answer different questions. For a large order, the distinction matters most when execution is split over time. ### thor swap limits protect execution, not the displayed quote A slippage limit sets the worst rate at which an order, or a slice of it, may execute. It does not reserve the quoted rate while the source-chain transaction confirms. Keep these four points in view when comparing routes: * **Set a net-output floor.** Start with the amount expected after route fees. * **Separate price impact from tolerance.** The quote may already include substantial pool slip. * **Check how slices are protected.** A streaming fill can be partial. * **Price the failed outcome.** A refund still takes time and can incur network fees. **Net output:** If a fresh quote expects 100 ETH after its stated fees, a 50-basis-point tolerance puts the illustrative floor at 99.5 ETH. Check the actual “minimum received” or trade target before signing; a percentage shown beside a route is useful only if you know which quoted amount it uses. **Price impact:** A quote that already loses 80 basis points to pool depth does not become an 80-basis-point limit. Adding 50 basis points of tolerance permits further deterioration from that quoted output. Compare routes using net units received for the same input, then judge how much additional movement you will allow. **Streaming:** THORChain can divide one inbound deposit into sub-swaps and send one outbound payment after the stream. Its trade target is checked during execution; later slices can fail even after earlier ones fill. You may receive some destination asset and a refund of the unspent source asset, rather than the full-order minimum you calculated. **Refunds:** A market swap that misses its target is refunded instead of waiting indefinitely for a better price. The source transaction has already happened, and a refund can incur an outbound fee on the source chain. A tight limit therefore buys price discipline at the cost of a higher chance of delay and an incomplete trade. ### Pool depth sets the useful size of each slice For a THORChain pool route, the order’s size relative to both pools sets its price impact. A BTC-to-ETH swap passes through the BTC/RUNE and ETH/RUNE pools; the thinner leg can dominate the result. For one pool, the approximate slip fraction is input divided by input plus the pool’s input-side depth, and the second leg adds its own slip. Streaming reduces the size of each sub-swap and gives arbitrageurs time to rebalance pools between them. It is most useful when the single-swap quote is poor because the order is large relative to depth, while the trader can tolerate a longer execution window. More slices do not drive costs to zero: protocol minimum slip fees and the maximum stream length constrain the benefit, and market price can move throughout the stream. For example, splitting an order into ten equal slices roughly divides each slice’s immediate depth demand by ten. It does not guarantee one-tenth of the original total cost, because pool balances, arbitrage activity and the asset price change between executions. Treat the streaming quote as a model of those conditions, then inspect its estimated slice count and duration. ### Each route buys a different balance of time and certainty An immediate pool swap favors speed when its net quote is acceptable and the order can survive the price move before the inbound transaction is observed. A streamed pool swap usually improves the modeled rate for a large order, but extends exposure from minutes toward hours; an L1 stream can be capped at roughly 24 hours. A conditional limit swap waits for its target instead, so it may expire without filling or fill only in part. Manual tranches offer another form of control: send one portion, inspect the settled result, then decide on the next. That can be sensible when market conditions may change sharply, but each tranche needs another source-chain transaction and potentially another outbound payment. Compare those repeated fixed fees with the price improvement you expect from spacing the order yourself. Time estimates need the whole path. Source-chain confirmation, network observation, any streaming interval, outbound delay and destination-chain confirmation all count. On a market stream set ten THORChain blocks apart, ten slices span about nine intervals—roughly nine minutes at six-second blocks—before adding chain confirmations and outbound delay; a large outbound can add materially more time. ### A large BTC-to-ETH order shows where the limit bites Take an illustrative $250,000 BTC-to-ETH order. Suppose an immediate route quotes 98.8 ETH net and a ten-slice streaming route quotes 100 ETH net, with a longer settlement estimate. A 50-basis-point tolerance against the latter quote suggests a 99.5 ETH full-order floor, but that shorthand is reliable only for a route that enforces the limit on the whole order. In THORSwap, compare the route details, fee breakdown, estimated duration and minimum received for the same input and destination. Then initiate the [thor swap](https://thorswap.us) after refreshing the quote and checking that the encoded minimum matches the floor you intend. On a THORChain route, the fee-aware quote parameter **liquidity\_tolerance\_bps** derives a trade target from expected output; 50 basis points means 0.5% below that expectation. The older **tolerance\_bps** calculation excludes swap and outbound fees and can set a target that fails unnecessarily. Suppose the first six slices execute, then the market moves through the target for the remaining four. The outcome can be about 60 ETH plus refunded BTC, with the precise amounts determined by the executed slices and fees. That is the edge case a full-order “99.5 ETH minimum” summary conceals: the limit protects the rate of fills, while completion of the entire order depends on later market conditions. ### The best limit depends on the cost of waiting or refunding Choose the narrowest tolerance that still leaves room for plausible movement before execution, then compare its failure cost with the extra output offered by a slower route. For a liquid pair, testing illustrative tolerances such as 25, 50 and 100 basis points against fresh quotes shows how the minimum changes; none is a universal setting. If the required floor exceeds the current net quote, a conditional order expresses that price requirement more clearly than increasing slippage tolerance. Include source gas, pool liquidity fees, interface fees and destination outbound fees in the same unit before ranking routes. THORSwap swap fees on qualifying large orders are typically around 0.25%–0.5% before applicable discounts; network fees vary with congestion, and pool costs vary with depth. The quoted net output is the practical comparison figure, while the fee breakdown tells you why two routes differ. I would favor streaming when the improvement in net output comfortably pays for its longer exposure and a partial fill is operationally acceptable. If the entire position must arrive by a fixed time, or a BTC refund would disrupt the next trade, the answer changes: use a faster route with a viable floor, or submit smaller orders you can reassess after each settlement.