A partial cross-chain swap refund arrives after the route accounts for input it did not spend and submits a return transaction; timing depends on chain confirmations and route design, so there is no universal minutes figure. If you swap only a few times a year, check the deposit and refund separately before trying again.
What does a partial refund return?
It returns the portion of your input asset that the swap did not consume. If a route receives 100 tokens and uses 62, the unspent 38 may be returned, while the spent portion is exchanged for the destination asset. Those figures are illustrative; the actual amounts depend on execution.
A route can leave input unspent when a price limit prevents further swaps, or when a route executes only part of an intended trade. A liquidity pool prices each trade against its available reserves, so the amount it can exchange at an acceptable rate can change as the swap proceeds. The refund is the remainder of the input, not compensation for receiving less output than expected.
Fees can make the amount you receive back smaller than the simple difference between your deposit and the amount exchanged. A route may have already paid network costs or completed part of the swap before it returns what remains. Check the transaction records for the amount consumed, any recorded fees, and the refund amount.
Why can a cross-chain refund take longer?
On one chain, a contract can sometimes calculate the unused input and return it in the same transaction. Across chains, the route may need to confirm your deposit, execute one or more swaps, then send a separate refund transaction on the original chain. Each step needs to be recorded by its network.
For example, a local exact-output swap can stop once it has bought the requested amount and return excess input in that transaction. In a cross-chain route, the destination-side swap might finish after the source deposit has already been confirmed, so any leftover input may require a later transaction back on the source chain. The delay depends on the route and the two networks, not on a fixed refund window.
If a thor swap is how you plan to move between assets such as BTC and ETH, it gives you a single cross-chain swap flow instead of making you handle each transfer separately. Keep in mind that one flow can still involve separate on-chain steps: a thor swap result and its refund, if any, should be checked as distinct transactions.
What should you check before trying again?
Use the transaction hash for the deposit to confirm that it reached the route, then look for a completed swap or refund transaction. The source and destination chainsβ block explorers show whether each transaction was confirmed and which token moved. Check the refundβs chain, asset, amount, and receiving address; a return in the original input token is different from destination-chain output.
A tiny remainder can also be difficult to return if the route or network cannot process an amount that small. There is no single dust threshold that applies across chains and assets, so compare the recorded refund with the original deposit and fees. If the route has not reached a final state, wait for its transactions to settle before submitting the same funds again.
My rule for an occasional thor swap is to verify the refund on-chain before deciding what to do next. Once the refund is confirmed, check that the amount is spendable in your wallet; then make a fresh swap only if the original destination and amount still suit you.
- Separate unspent input from output shortfall.
- Allow for a separate refund transaction and network confirmation.
- Verify the refund asset, chain, amount, and address in the block explorer.
- Wait for a final transaction state before retrying.
Top comments (0)