When a Cross-Chain Swap Exceeds THORChain Route Capacity

A THORChain swap that is too large for its route’s available liquidity may incur steep price impact, wait for acceptable price conditions, or be refunded, depending on how it is submitted. For a non-RUNE pair such as BTC to ETH, THORChain routes through the BTC/RUNE and RUNE/ETH continuous liquidity pools in one state-machine operation. The user does not receive or handle the intermediate RUNE.

“Capacity” can mean two different things: the amount the pools can trade at an acceptable price, or the network’s ability to process swaps and send out assets. Those limits behave differently. A route does not have one universal maximum trade size; its effective limit depends on pool depth, the price the user will accept, queue conditions, and destination-chain settlement. Treasury operators weighing route selection can find a fuller discussion of transfer trade-offs in thor swap.

What sets a route’s effective capacity?

Pool depth and the swap’s minimum-output condition set its effective trading capacity. In THORChain’s continuous liquidity pool model, each connected asset has a pool paired with RUNE. A non-RUNE swap consumes liquidity in both pools, so the output from the first leg affects how much the second leg can deliver.

As the input grows relative to pool depth, the pool’s pricing curve returns progressively less output per unit of input. The protocol charges a slip-based liquidity fee, and the trade can also move the pool price. This is not the same as hitting a fixed route limit: a large trade may still execute, but at a worse rate. A minimum-output limit turns that price impact into a condition. If the trade cannot meet the limit, the swap rules determine whether it waits or refunds.

That distinction matters when a quote looks adequate at submission. Pool balances and competing swaps can change before execution. The quoted output is an estimate against a particular state; it is not a reserved slice of liquidity.

What happens when the swap cannot meet its price?

A market swap attempts execution at the available pool price; a limit swap waits for its price condition. In THORChain’s advanced swap queue, a market swap with a minimum-output target is attempted immediately and refunded if the target cannot be met. A limit swap remains queued until its target becomes achievable or it expires. The queue mode is controlled by the `EnableAdvSwapQueue` Mimir setting, so limit-swap behavior depends on that setting.

Streaming swaps split the input into smaller sub-swaps over time. This can reduce price impact per execution and give arbitrageurs time to rebalance pools between sub-swaps. It does not create liquidity or guarantee completion at the requested price. If the stream’s price limit cannot be met, THORChain’s documentation says the total or remaining inbound amount is refunded. If part of a streamed or limit swap has already executed, the swapped portion can settle while the unspent remainder is returned.

For a large transfer, the practical choices are to accept a lower minimum output, let smaller sub-swaps execute over time, or use a limit condition that waits for a better price. Each makes a different trade-off: immediate execution favors speed, streaming spreads execution, and a limit condition favors price while adding uncertainty about when—or whether—the swap completes.

Can queue or outbound capacity delay settlement?

Yes. Processing throughput and pool liquidity are separate constraints. THORChain’s swap queue orders eligible trades, and network settings can limit how many swaps a block processes or how many rapid iterations the queue runs. When activity is high, a swap may take longer to reach execution even if pool depth could support it.

Settlement adds another stage. After the internal swap, THORChain schedules an outbound transaction from its vault to the destination chain. Outbound delays and destination-chain conditions can affect when the recipient sees funds. A swap shown as executed is therefore distinct from an outbound transaction being broadcast and confirmed.

• Pool depth: determines the trade’s price impact and the output available along both pool legs.
• Minimum output: determines whether a market attempt can execute or must refund.
• Streaming or limit conditions: can spread execution over time or wait for the required price, with partial completion possible.
• Queue and outbound load: can delay processing or delivery even when liquidity is sufficient.

What should a treasury check before sending?

Check the route’s expected output and price impact at the intended size, then compare the minimum output with the transfer’s actual requirement. For a streamed swap, confirm that the execution window and the possibility of partial completion fit the treasury’s settlement needs. A limit swap can preserve a price floor, but it can remain unfilled or expire; an immediate market swap can settle sooner but accepts the execution price subject to its protection condition.

Also distinguish the pool route from the application that presents it. An interface may quote or select a route, but the protocol’s pool state and swap rules govern execution after funds arrive. Before treating a pending swap as failed, check whether it is awaiting inbound confirmation, queue processing, or outbound settlement. The key operational point is simple: route capacity is not a single size ceiling. It is the interaction of pool depth, acceptable price, processing throughput, and delivery timing.