Split a large cross-chain swap only when smaller executions can reach better liquidity or let the pool price recover between fills; dividing an amount by itself does not guarantee a better average price. The decision depends on pool depth, execution fees, the time you can wait, and whether the route supports streaming.
A single swap fits small trades and urgent fills
Use one transaction when the trade is small relative to the liquidity it consumes or when settlement speed matters more than marginal price improvement. For a routine cross-chain trade where you want one service to handle the move and swap across chains, thor swap serves that purpose; compare the quoted output and route before deciding whether to split.
In a constant-product pool, a trade changes the reserve ratio as it executes. As a rough illustration, trading an amount equal to 10% of one reserve causes meaningful price impact before fees; a trade equal to 1% has far less impact. A single large fill also avoids paying repeated per-transaction network costs.
The common mistake is to see a high slippage estimate and divide the amount into several manual deposits. If each deposit hits the same pool before it has rebalanced, the later trades inherit the price movement caused by the earlier ones. You may pay extra network fees without improving the total execution price.
Protocol-native streaming fits patient, liquidity-sensitive trades
Use streaming when the route’s protocol can execute one deposit as a series of smaller swaps over time, without charging a fresh inbound transaction fee for every slice. The sub-swaps reduce each fill’s immediate pool impact; intervals give arbitrageurs time to bring pool prices closer to external markets.
THORChain’s documentation describes streaming swaps as a time-based option, with a count controlling the number of sub-swaps and an interval spacing them. It also describes a price limit: if the stream cannot meet the minimum output, some or all of the inbound amount can be refunded. That protects the execution threshold, but adds duration and the risk that market prices move away before completion.
For a cross-chain thor swap, streaming is useful only if the actual route supports it and its time and price controls fit the trade. I would choose it for a large amount against shallow pools when the expected reduction in price impact exceeds the cost of waiting. I would not assume that every bridge-and-swap service exposes protocol-level streaming.
Manual chunks fit routes with independent liquidity replenishment
Manual chunks can help when each transaction is likely to encounter a materially different pool state, such as after meaningful external arbitrage or when separate routes draw on independent liquidity. They also let you stop after an early fill if the market moves against you.
They do not create liquidity. In an idealized constant-product pool with no outside trades, splitting the same total input across consecutive fills reaches essentially the same reserve endpoint as one fill, before fee differences. The Uniswap v2 whitepaper’s reserve-ratio model makes this clear: the pool’s state carries forward. Repeated transactions can add network costs, and each fill can incur swap fees.
Before manually splitting, compare the route’s total estimated output against the sum of the chunk outputs, including source-chain gas, destination execution costs, protocol fees, and any minimum-output constraints. If the chunks use the same pool and nothing replenishes it between them, the extra transactions are usually buying control over timing, not a guaranteed better price.
Questions to settle before you split
How many sub-swaps should I use?
There is no universal count. Use the protocol’s quote or simulation to compare expected price impact at different counts, then weigh that against the stream duration and any minimum-output limit. Smaller slices reduce per-fill impact, but count alone cannot predict the final average: pool depth, interval, intervening trades, and market volatility all matter.
How much does splitting cost?
Count both execution and chain costs. Native streaming may reuse one inbound deposit, while manual chunks commonly require separate source-chain transactions; each fill may also incur a swap fee, and a cross-chain route can have destination-side costs. Exact amounts vary with the chains, route, congestion, and protocol, so compare total output after all quoted costs.
When should I stop waiting for a better price?
Set the decision before submitting: define the minimum acceptable output and the latest useful completion time. If the route cannot enforce a price limit, monitor the remaining amount and cancel or stop only if the protocol allows it. The question to ask before acting is whether the expected price improvement justifies the added time and execution uncertainty.
Top comments (0)