Stream a cross-chain swap when reducing pool price impact is worth waiting for staged execution. For treasury teams, the decision depends on the trade’s size relative to route liquidity, the payout deadline, and the cost of a partial or delayed fill.
When is streaming worth the wait?
Streaming is most useful when a one-shot swap would move the pool price enough to make the execution cost material. Before setting a policy, compare the route and expected output; how thor swap routes cross-chain trades matters because the available liquidity and execution path shape that estimate. For recurring transfers, review representative routes and amounts rather than relying on one quote.
Use the quote’s expected output, price impact or slippage estimate, network fees, and estimated completion time to compare one-shot and price-optimised execution. These figures describe a route at quote time; pool depth and market prices can change before the inbound transaction is confirmed. I would stream when the expected price improvement is larger than the treasury’s tolerance for delay and execution uncertainty.
For example, suppose a $500,000 transfer has an estimated 1.4% price impact as one swap and 0.4% when streamed. Those illustrative figures imply about $5,000 less impact before network or service fees, in exchange for waiting while sub-swaps execute. If the destination payout must clear within an hour, a smaller estimated saving may not justify the timing risk.
What happens after the inbound transaction?
A streaming swap starts with one inbound transaction. The protocol divides the amount into sub-swaps, executing them over time so arbitrageurs can rebalance liquidity between parts of the trade; the resulting output is consolidated into an outbound transaction. THORChain Dev Docs describe this as price-optimised execution, with streams limited to 24 hours.
The split can lower pool impact without paying inbound and outbound chain fees for every sub-swap, as would happen if a treasury manually sent many separate swaps. But streaming does not guarantee a better realised price: the market can move against the trade, the route can change, and waiting creates exposure to price movement during execution. Do not treat the stream as a guaranteed TWAP or a fixed-price order.
Set a minimum acceptable output with the route’s price limit. If a sub-swap cannot meet the limit, execution may stop for that portion and the unswapped amount may be refunded; exact behavior depends on the protocol and route. A limit set too tightly can cause a partial fill or refund, while a loose limit offers less protection. THORChain’s documentation also describes a fully price-optimised swap fee as low as 5 basis points, excluding inbound and outbound fees; actual costs depend on pool depth and trade size.
How should a treasury set its execution policy?
Use a repeatable decision process for each payout class, with limits that finance can approve and operations can monitor.
- Group transfers by deadline. Mark each payout as time-critical or flexible, and set a maximum completion window for each class.
- Request a fresh quote. Capture route, expected output, price impact, fees, minimum output, and estimated inbound and outbound timing immediately before submission.
- Compare execution modes. Choose streaming only when its estimated improvement clears your approved savings threshold and fits the payout window.
- Set the output floor. Derive the minimum acceptable amount from the quote and treasury policy, then account for the possibility that some input is refunded.
- Track to settlement. Monitor inbound confirmation, stream progress, refunds, and outbound transaction status; reconcile the received asset against the approved minimum before closing the payout.
In a pilot, compare completed transfers against their original one-shot quotes, including fees, elapsed time, and refunded amounts. If the savings are inconsistent or deadlines are missed, narrow streaming to the routes and transfer sizes where the measured benefit reliably exceeds the operational cost.