Start with the previous IBC transfer, not a new exchange amount
- Identify the sending chain and account
Keep the original transfer reference and packet context, including the route where your wallet exposes it. The account expecting a refund is tied to that transfer. A portfolio application showing ATOM in several locations does not establish which balance is about to become available.
- Establish the completed timeout or error handling
The IBC transfer implementation invokes a refund when its timeout handler runs; an error acknowledgement also has refund handling. A local countdown reaching zero is not the same evidence as that completed source-chain processing. Ask for the actual recorded outcome rather than inferring it from elapsed wall-clock time.
- Check what the sending account can now use
Verify the returned asset and its chain in the wallet. Then review the native ATOM sending balance relevant to the exchange instruction. Do not add the outstanding transfer amount to a balance that may already include its refund, and do not assume a refund on another chain is a native Cosmos Hub receipt.
Three references for three different questions
| Record | Question it answers | What it does not prove |
|---|---|---|
| Original IBC transfer | Which interchain attempt is being discussed? | That the exchange was paid |
| Refund outcome on its sending chain | What returned, where and to whom? | That it is available on every ATOM-labelled network |
| New exchange payment | Was the instructed native ATOM payment made? | That the earlier IBC problem was part of the exchange |
A deadline and a processed refund are different evidence
IBC’s channel-and-packet specification describes timeout handling with proof about the receiving chain. It is not merely the sender deciding that enough seconds have passed. The transfer application then handles the refund. This is why a browser timer or a delayed application status should not be used alone to declare the money restored and ready to spend.
The ibc-go transfer code also distinguishes how returned funds are accounted for: depending on the transfer path, tokens can be unescrowed or vouchers re-created for the sender. For this exchange, you need to identify the actual returned holding rather than treating every refund as a fresh native ATOM credit on Cosmos Hub. The old interchain operation and the new conversion have different destinations and records.
Checks before committing to the SOL purchase
- Does the wallet show a real available balance?
- Use the observed source account state after the refund is established. If an application’s expected refund and current balance do not reconcile, resolve that discrepancy first. A future or presumed receipt should not determine the amount you promise to send.
- Are you relying on an earlier quote or payment window?
- Review current exchange conditions after the source funds become available. A delayed IBC refund does not preserve a previous estimate or extend a funding deadline. Keep any question about the old transfer with the wallet or route responsible for it.
- Can support distinguish the old transfer from new funding?
- Label each reference by purpose. Provide the existing record rather than sending another IBC transfer or exchange payment to test a hypothesis. When the required ATOM payment is established, investigate the SOL payout separately through its own receiving details and transaction record.
IBC refund and exchange questions
- Does an expired local timer prove the refund is spendable?
- No. Verify completed timeout handling and the source account’s actual asset balance.
- Does an IBC refund always appear as native ATOM on Cosmos Hub?
- No. Check the original path, returned holding and chain.
- Is the old IBC transaction the new exchange payment?
- No. Identify a separate payment matching the current exchange instruction.
- Does waiting for a refund keep an earlier exchange estimate valid?
- Do not assume so. Review current conditions once the required source balance is available.
Primary IBC references
Reviewed: