Four checks for unused assets after a partial crypto swap

After a partial fill, check whether the swap is still running, identify which asset remains, trace any refund, and compare the returned amount with the fees paid. On THORChain, a streaming swap can execute in smaller sub-swaps; if its price condition is not met for some attempts, those portions may remain unswapped while others succeed. The network sends the successful output and refunds the remaining source asset when the stream’s attempts are over, according to THORChain’s streaming swap documentation. That means “part-filled” can describe progress, not a failed transaction or a lost balance.

This differs from a single swap, which attempts execution as one trade, and from an order-book venue where the order record may show a partial match and a separately cancellable remainder. THORChain’s pool-based route uses liquidity pools and may use streaming to split the trade; the price target can leave some input unexecuted. The interface is only one view of that process. A fuller walkthrough of wallet-side steps is available in this thor swap guide; the checks below focus on reconciling what happened after a partial fill.

Is the swap still executing or finished?

First, establish whether the stream has completed before treating the unused input as available to spend. A streaming swap is made of successive attempts, so a screen showing some output does not by itself establish that all attempts have ended. THORChain’s developer guide says the network tracks the successful and failed portions across the attempts, then sends output and refunds the unexecuted source amount after the attempts are made.

Look for a terminal status in the wallet or interface, and compare it with the transaction activity visible for the source chain and destination chain. A pending or incomplete status calls for waiting and checking again; submitting a second swap with the apparent remainder could duplicate the trade if the original stream is still active. If the interface does not make completion clear, use the transaction identifiers it provides to inspect the associated activity before taking further action. A displayed fill percentage is useful context, but completion status is the decision point.

Which asset is the unused balance in?

Check the token and chain of the remainder before deciding what to do with it. In a streaming swap with a price limit, unsuccessful sub-swaps leave input in the source asset for refund; successful sub-swaps produce the requested output asset. The two balances can appear side by side in an interface, but they are not interchangeable: one is the result of completed trades, the other is input that did not trade.

Record the source asset, destination asset, amounts sent and received, and the wallet addresses involved. Compare the asset symbols and chain labels, not only the approximate dollar value. THORChain’s documentation describes a cross-asset swap as moving through connected pools, while the user sees a single swap; the destination amount therefore should not be mistaken for a return of the original input. For a partial stream, reconcile the output and remaining source separately.

Can you trace a refund and explain the difference?

Use the transaction history to determine whether the unfilled source amount has actually returned to the expected wallet. A refund is a separate event to verify, not an assumption based on a smaller-than-expected output. THORChain’s swap guide says the protocol returns a refunded inbound swap to the original sender by default; check the source-chain record and receiving address against the transaction details shown by the wallet or swap interface.

Then account for fees before concluding that the refund is short. The amount received may differ from the amount originally sent because the swap process involves network transactions and outbound costs; the exact treatment depends on the route and asset. Compare like with like: source amount sent against source amount returned, and destination amount received against the completed portion. Keep the relevant transaction identifiers and timestamps together. If the status is complete but the refund is not visible, those records give support or an explorer a concrete starting point.

What should you check before using the remainder?

Once the stream is complete and the source-asset return is visible, reconcile the four checks before spending or resubmitting anything:

• Status: Is the stream complete, or are more sub-swaps still pending?
• Asset: Is the remainder the original source token on the expected chain?
• Record: Does a refund transaction show the amount going to the expected address?
• Fees: Can the gap between sent and returned amounts be explained by the transaction and outbound costs shown?

If all four line up, the remainder is an unfilled balance rather than evidence that the successful portion failed. If one does not, pause before creating another swap and resolve the missing status or transaction detail first. The practical trade-off is straightforward: streaming can seek a price condition across multiple attempts, but it may leave input untraded and require a refund reconciliation. Watch the final stream status, the source-chain refund record, and the net amounts after fees; those signals distinguish a completed partial fill from one still in progress.