Thorchain can spread larger swaps over time to reduce pool price impact
Last updated -
Thorchain can take longer to complete a larger swap because streaming divides the trade into smaller internal sub-swaps. Their count and spacing affect execution time, while smaller portions can reduce pool price impact. Rapid streaming can process several portions within a block when conditions permit. Wallet arrival also depends on inbound confirmations and outbound handling. A longer estimate can therefore reflect a pricing choice, a settlement delay, or both; the quote's timing components help distinguish these causes.
Bottom line: Streaming time can overlap the outbound delay, so wallet arrival estimates should account for both execution settings and chain confirmations.
Smaller Sub-Swaps and Pool Price Impact
A streaming swap distributes demand for liquidity across smaller executions, which can improve pricing when arbitrage restores pool balances between them. Pool depth means the assets available in a liquidity pool. A swap's size relative to pool depth determines its slip-based liquidity fee, subject to the applicable minimum. A large trade changes the pool's asset ratio more sharply than a small trade against the same balances. That change affects the price that the pool can offer during execution.
Arbitrageurs trade against differences between pool prices and other markets. Their activity can restore a more favorable ratio before later sub-swaps execute. Longer spacing gives that activity more time, although market movement can still worsen the overall price. For exchanges between external assets, the stream uses the relevant RUNE-linked pools. Both pools' liquidity matters; streaming does not create additional deposited reserves.
Swap Count and Block Interval
Swap count sets the number of internal portions, while a market stream's interval sets their separation in Thorchain blocks. With positive spacing, more portions require more execution opportunities. Increasing the interval extends the gaps between those opportunities. Block-based scheduling describes protocol execution, not an exact clock-time appointment.
The quantity setting concerns portions of the input amount, not separate deposits. Smaller portions reduce the demand that each execution places on its pools. A higher count can therefore change both the expected liquidity cost and the expected duration. The price benefit still depends on the balances available during each attempt.
With the Advanced Swap Queue enabled, a quantity of 0 lets the network calculate the count. Omitting streaming parameters also invokes automatic streaming in that queue.
Automatic sizing follows pool conditions and protocol constraints. Minimum fee settings limit how far subdivision can reduce liquidity charges. Maximum stream-length settings also constrain the schedule. Requesting more portions cannot bypass these limits, and an interface's requested count need not become the executed count. The quote's maximum streaming quantity describes a ceiling for that quoted swap, not a universal network allowance.
Does Every Streaming Swap Wait Between Blocks?
A streaming market swap does not always wait between sub-swaps: the Advanced Swap Queue supports rapid execution when its settings permit it. A market stream with interval 0 can execute multiple sub-swaps within a block when rapid iterations are enabled. A positive interval retains block-spaced execution. Those options differ in scheduling even though both divide the input into portions. A count alone therefore cannot establish how many blocks the trade will require.
Rapid processing also has limits. The queue's direction protection can skip repeated same-direction market swaps during subsequent iterations in a block. This limits cumulative pressure on the same pool. Available opposing trades, pool conditions, and the configured iteration allowance affect how much work a block can complete.
One Deposit and Consolidated Settlement
A cross-chain streaming swap ordinarily uses one inbound deposit and consolidates successful sub-swap output for delivery after the stream finishes. The protocol performs the internal portions without requiring a new source-chain transfer for each one. Manually dividing a trade into separate swaps creates additional inbound and outbound transactions instead. Streaming avoids that repetition of external-chain fees. The initial deposit still needs its source-chain fee, and final delivery still incurs an outbound fee. An interface can also include an affiliate charge.
Partial completion can produce both target-asset delivery and a source-asset refund.
What Else Adds Time Before Funds Reach a Wallet?
Wallet arrival includes source-chain confirmation, Thorchain observation and finality requirements, internal execution, outbound scheduling, signing, and destination-chain confirmation. The source chain must first include the deposit. Validators then agree on what they observed, and applicable confirmation counting protects against chain reorganizations. Larger transaction values can require additional confirmations on chains that use economic finality. A deposit confirmation alone therefore does not establish that internal swapping has finished or that the destination chain has received an outbound transaction.
Outbound scheduling adds a separate security-related delay that depends on value and network conditions. Time spent executing a streaming swap counts toward its outbound delay period. Adding the full streaming estimate to the full outbound-delay estimate can therefore double-count overlapping time. The swap quote separates these components, but its total_swap_seconds estimate excludes outbound signing and destination-chain confirmation. Its streaming duration describes internal execution; it does not include every event required for the recipient's wallet to show confirmed funds.
An outbound marked as scheduled still awaits its eligible processing time. Signing and broadcast follow, then the destination chain confirms the payment.
Choose a Schedule That Fits the Arrival Deadline
Quotes for block-spaced and rapid execution should use the same input amount, destination, and minimum output. If the slower quote offers higher expected net output, the extra wait may serve a pricing goal. That choice only fits an arrival deadline that allows time for confirmations and outbound handling. Pool changes can erase the estimated advantage before or during execution.
- If arrival time matters, compare the quote's total estimate as well as streaming duration, and allow extra time for signing and destination-chain confirmation.
- If the interval or count changes, obtain a quote that reflects the new settings.
- If interfaces charge different affiliate fees, include those charges in the net-output comparison.
- If the minimum output is essential, retain that protection when comparing faster execution.
- If a quote has expired, obtain a fresh quote before sending the deposit.
What Happens When a Price Limit Blocks a Sub-Swap?
A failed price check in a streaming market swap can leave input unswapped, which the protocol returns when it settles the stream. If the first market-stream attempt fails, the network stops further attempts and refunds the input, less applicable fees. Failures after successful portions can produce partial completion. Settlement sends the successful target-asset output and refunds the unsuccessful input portions. The source-chain outbound fee reduces the refund. If the remainder cannot cover that fee, the protocol cannot send a source-asset refund. Price protection therefore does not require every portion to succeed, and successful internal conversions do not reverse simply because later portions fail.
A streaming limit swap has different waiting behavior when limit processing is enabled. It can remain queued for acceptable price conditions until execution or expiry. In the Advanced Swap Queue, the second slash-separated memo value sets a custom lifetime for a limit swap; it is not the market stream's block interval. Expiry or cancellation settles any filled portion and refunds the unswapped remainder. Waiting for a price condition therefore has a different cause from deliberate spacing between market sub-swaps.
Execution Caps and Operational Pauses
Network limits constrain streaming schedules, while trading pauses interrupt the conditions underlying a normal execution estimate. Maximum streaming length depends on the asset category and the active network settings. A market stream's execution cap does not promise wallet delivery within that period. Source-chain and destination-chain confirmations still take their own time. Trading halts prevent affected swaps from executing, so the selected intervals cannot describe uninterrupted processing during a pause.
Queue availability also differs by swap type. The network can process market swaps while skipping limit swaps. A general indication that trading is active therefore does not establish that a queued limit swap is advancing. In the Advanced Swap Queue, EnableAdvSwapQueue set to 2 means market-only mode.
Thorchain questions, answered
Does My Wallet Need to Stay Open During a Streaming Swap?
An active stream runs in the protocol without keeping the wallet interface open. Closing the interface does not cancel an on-chain deposit or stop the queue. The inbound transaction identifier lets you locate the swap and its eventual outbound payment or refund.
Do I Need to Hold RUNE Separately for Each Streaming sub-swap?
A swap between external native assets does not require a separate RUNE balance for each internal portion. The protocol handles the RUNE settlement between its pools. Your deposit still needs the source chain's transaction fee; that fee depends on the input chain, not the number of internal portions.
Can I Change the Minimum Output of a Queued Streaming Limit Swap?
The original sender can modify a queued streaming limit swap's minimum output through the limit-swap modification mechanism. The protocol matches the order by its sender and source/target asset pair. This applies to limit swaps that the Advanced Swap Queue holds for conditional execution.
Why Can a Transaction Indexer Omit My Streaming Swap After the Deposit Confirms?
An indexer can lag behind the deposit because Thorchain may still be counting confirmations before finalizing the inbound transaction. Midgard does not display that transaction until the relevant finality event occurs. A source-chain confirmation and protocol finality are separate states, so absence from that indexer alone does not prove a failed swap.
Will a Higher Wallet Network Fee Speed Up sub-swaps That Have Already Started?
A higher source-chain transaction fee can help a deposit reach confirmation before streaming starts, but it does not shorten an already-running stream's interval or increase its rapid-iteration allowance, because those internal operations follow the protocol's execution settings rather than the wallet's inbound fee.
Can a Streaming Swap Refund Go to a Different Address?
A swap can specify a custom refund address that is valid for the input asset's chain. The protocol otherwise refunds the original sender, and an invalid custom address falls back to that sender. This matters when a contract sends the deposit, because its sending address may differ from the intended refund recipient.
Does the Largest Streaming Deposit Always Get Queue Priority?
The largest original deposit does not automatically receive priority for every portion. The queue scores streaming swaps using the upcoming sub-swap's size, with fee and slip scoring influencing processing order. Subdivision therefore affects scheduling as well as liquidity cost; the total deposit alone cannot predict which swap executes next.
When Can Trading History Reduce a Streaming swap's Outbound Wait?
Available Swapper Clout can reduce the effective outbound value that the protocol uses to calculate its delay. Clout reflects fees attributed to swap addresses, and concurrent outbounds share available credit. This can reduce the scheduling delay, while source-chain finality and destination-chain confirmation retain their own requirements.