Size Treasury Swaps Against Executable Pool Depth
Treasury swaps should be sized against executable depth on both legs, then checked against fees, price limits and streaming time before funds are committed.
The Block Press Editors5 min read
A treasury swap should be sized against the amount each pool can execute at an acceptable price, not against the pool’s headline balance. On THORChain, a swap changes the ratio of assets in a continuous liquidity pool; the larger the input relative to depth, the more the pool price moves and the higher the slip-based liquidity fee. For a cross-chain route, each leg matters: a swap between two non-RUNE assets passes through their respective pools against RUNE. A usable size therefore depends on the quote for the whole route, the treasury’s price limit and whether execution can be spread over time.
The pool balance is a starting point, not a capacity guarantee. The relevant question is how much output the protocol quotes for this input now, after pool-based slip and applicable fees. A fuller account of cross-chain execution is available in thor swap. For sizing, the key is to compare the quoted result with the treasury’s acceptable outcome and the liquidity available on every leg.
What does pool depth tell a treasury?
Pool depth tells a treasury how strongly a swap of a given size will move the pool’s asset ratio. In a continuous liquidity pool, the asset ratio supplies the pool price; the trade changes that ratio as it consumes liquidity. A larger trade against the same depth creates more slip, which is reflected in the liquidity fee and the amount received.
Depth is not a fixed execution limit. A swap can exceed the balance visible on one side of a pool and still execute, but the price impact can make that execution unacceptable. Conversely, a balance that looks large in isolation may not support the desired size at the treasury’s minimum output. “Can execute” and “can execute within mandate” are different tests.
For a route with two pool legs, check both. The first leg converts the inbound asset to RUNE; the second converts RUNE to the destination asset. The two legs have separate depths and price impacts. A deep first pool does not compensate for a shallow second pool. Use the route quote’s total output and fee breakdown rather than estimating from just one pool or adding the two pools’ displayed balances.
Depth also moves. Swaps alter pool balances, while liquidity changes and arbitrage can move the ratio toward external market prices. A quote is a view of current state, not a promise that the same size will receive the same output later. Treasury approval processes should set a price limit in output terms and refresh the quote close to execution.
How should a treasury set its maximum swap size?
Set the maximum size by working backward from the treasury’s minimum acceptable output, then compare candidate sizes against current route quotes. A percentage of pool depth can be a useful screening measure, but it cannot replace a quote: the same percentage can produce different outcomes across pools and routes.
First establish the mandate in destination-asset terms. Specify the minimum amount the treasury must receive, the maximum fee or price impact it will tolerate, and any deadline for completing the conversion. Then request quotes at the intended size and at smaller sizes. This reveals whether the trade’s cost rises gradually or whether one pool leg is the binding constraint. It also makes the choice between one execution and a stream explicit.
Review the quote’s components separately. Pool slip and the liquidity fee reflect the swap’s demand on pool depth. Network fees apply to transactions on the source and destination chains; optional affiliate fees may also apply. A streaming swap can avoid repeating the external inbound and outbound transactions for each subdivision, but it does not remove pool price risk or guarantee that arbitrage will restore the pool between sub-swaps.
- Check the full route, including both pools for a non-RUNE-to-non-RUNE swap.
- Compare quoted destination output with the treasury’s minimum, not just with a spot price.
- Include network, liquidity and any affiliate fees in the approved cost.
- Set a price limit that can stop execution when market movement makes the remaining size unacceptable.
When does streaming improve execution?
Streaming can improve execution when the treasury can wait and the pool has time to rebalance between sub-swaps. The protocol divides one inbound swap into smaller internal swaps and sends the completed output in an outbound transaction. Smaller sub-swaps create less immediate price impact per attempt; arbitrageurs may rebalance pool ratios as the stream proceeds.
The benefit depends on time and market conditions. If the interval is too short for meaningful rebalancing, splitting the trade may not deliver the expected improvement. If the price moves away from the treasury’s limit, some sub-swaps may fail. THORChain’s streaming rules track successful and unsuccessful portions; the result can include executed output and a refund of the portion that did not meet the limit. A treasury should account for partial completion as an operational outcome, not assume the full amount will settle at one price.
Streaming also trades settlement speed for execution opportunity. A deadline may make a single swap preferable even if it incurs higher slip, while a patient mandate can favor smaller sub-swaps over time. The treasury’s limit and deadline should determine that choice. A quote that assumes a long execution window is not suitable if governance, custody or market policy requires funds to arrive sooner.
For an executable decision, size against current quotes, preserve a minimum-output limit, and choose the stream parameters only after considering the available time. Recheck the route if pool conditions change before the inbound transaction is made. The confirmed mechanics are that pool-relative trade size affects slip and fees, and streaming divides a swap into sub-swaps; whether arbitrage will restore depth in time, or the full amount will execute within the limit, remains unverified until the stream runs.