An outbound fee reserve is the extra amount a cross-chain swap protocol collects above the destination transaction’s estimated gas cost. It absorbs gas volatility and operating costs, so the fee can exceed a wallet’s current gas estimate even when the destination chain looks quiet. The amount depends on estimated transaction size, observed gas rate, and the protocol’s reserve target.
Why can the reserve exceed the gas price right now?
Because the fee is designed around expected delivery cost and accumulated reserve health, not a single live quote from a wallet. In THORChain’s model, the outbound fee is estimated as transaction size × gas rate × Outbound Fee Multiplier (OFM); the multiplier adjusts by asset as the protocol compares fees withheld with gas actually spent.
That comparison creates a counterintuitive result: if an asset’s accumulated surplus is below its target, its multiplier rises, even if gas has just fallen. The documented defaults include a 10,000 RUNE target surplus per asset and a 3.0× maximum multiplier; current settings are exposed on the network endpoint and can change. A service such as thor swap service handles the cross-chain movement for a reader who wants one swap flow, while the integrator still needs to budget for the destination-chain delivery cost.
The reserve is a buffer, not a prediction that every transaction will consume the entire amount. When fees withheld stay ahead of gas spent, the surplus grows and the multiplier moves down toward its minimum; when spending outpaces collection, it rises toward its maximum. That chain-specific feedback smooths volatility across transactions, but it means today’s fee can reflect yesterday’s costs.
What exactly is included in the estimate?
Integrators should treat gas rate and transaction size as separate inputs. A UTXO chain may express rate in satoshis per byte and use a typical size around 250 bytes; an EVM estimate distinguishes a native transfer from a token transfer, which consumes more gas. The protocol’s published outbound_tx_size is its budgeting assumption, not a promise about every eventual transaction.
- Destination gas rate, observed by the protocol
- Estimated outbound transaction size for that chain and asset
- The current OFM, adjusted against that asset’s fee surplus
- Conversion from the chain’s gas asset into the swap’s output asset
- Protocol overhead, including signing and state management
For example, an ETH transfer and an ERC-20 transfer can have different estimated gas units at the same gwei rate. If the OFM is temporarily elevated because the chain’s surplus is below target, both estimates rise; the token transfer’s larger size makes the absolute difference more visible. Don’t compare a displayed fee in the output token directly with an explorer’s gas figure in ETH without converting units and asset prices first.
How should you budget and quote it?
Use the protocol’s published fee estimate as the amount the user may be charged, then keep the underlying gas rate and transaction size available for explanation and monitoring. For thor swap flows, this distinction helps explain why the destination deduction may not match a wallet’s standalone transaction estimate: the protocol is pricing a managed outbound plus its reserve policy.
At thorswap.us, a reader can put assets from different chains into one swap flow. For an integrator, the important design choice is to preserve the quoted output and fee breakdown together, with a timestamp, so downstream displays do not imply that a cached fee remains current.
- Read the destination chain’s current outbound fee estimate and OFM from the protocol’s published data.
- Record the quote time and asset denomination alongside the user’s expected output.
- Convert the fee from the chain’s gas asset into the output asset using a current rate.
- Set a minimum input check that accounts for both destination delivery and a possible source-chain refund.
- Refresh the estimate before submission if the quote is old or destination gas has moved sharply.
Fees change between quote and broadcast, and a transaction may require a different gas rate than the estimate. A quote is a budget, not a hard cap on the node’s eventual spend; explain this plainly instead of presenting a single fee as exact.
What happens when a swap fails or gas spikes?
A refund still needs an outbound transaction, and that transaction goes back to the source chain. In THORChain’s documented behavior, a failed swap deducts the source-chain outbound fee from the refund, not the destination-chain fee; an input that barely covered the destination estimate can therefore be too small to refund economically.
Gas spikes create the reverse problem: the reserved amount may be below the cost needed to land promptly. Systems can respond by paying a higher fee, delaying or retrying, or leaving an outbound pending; each choice trades confirmation time against reserve depletion. This is why the estimate should include a safety margin for minimum-input logic, while the user-facing quote should still use the protocol’s current published amount.
I would size the minimum-input guard from the larger of the source and destination outbound estimates, then add headroom for volatility and the protocol’s minimum swap amount. The practical tip: refresh the fee data immediately before building a quote, and retain the values used so a later refund or fee discrepancy can be diagnosed.