How to Choose a Refund Wallet for a Stuck Swap

Use a wallet you control on the chain where you sent the deposit, and verify it can receive that exact asset. The right address depends on the source chain and the swap’s registered refund parameters; once a deposit is pending, you generally cannot change those parameters for that swap.

The Refund Address Is a Source-Chain Destination

A refund returns the unswapped source asset to the address recorded when the swap was initiated; it does not send the asset to your destination wallet. On Chainflip, Validators witness the deposit onto the State Chain, where the swap is processed through the JIT AMM. If price protection cannot be met within the retry duration, the protocol can send the deposit back on its original chain.

Use an address that can receive the asset on the exact source chain. For example:

• BTC sent from Bitcoin needs a Bitcoin address you control.
• ETH or an ERC-20 sent from Ethereum needs an address able to receive it on Ethereum.
• SOL or a Solana token sent from Solana needs a Solana address you control.

Matching address formats is not enough: an EVM address may look the same across Ethereum and Arbitrum, but funds sent on one chain are not thereby available on the other. An exchange deposit address is a poor default unless the exchange confirms it can credit protocol refunds for that asset and chain. Refunds may arrive as a separate transfer without the memo, tag, or context an exchange expects.

Check the Bound Address Before You Wait

For a pending swap, first identify the refund address and retry duration actually registered with the swap; do not infer either from the destination address or the wallet that made the deposit. Work through these checks in order:

1. Match the source asset and chain. Read the deposit transaction and swap record together. Confirm whether the source was native BTC, ETH, SOL, or a token on a particular chain; token tickers alone can conceal chain mismatches.
2. Inspect the recorded refund parameters. Find the refund address, minimum accepted price or slippage tolerance, and retry duration. These are set at initiation. A broker or interface should not be assumed able to redirect a refund after the channel or Vault call has been registered.
3. Check address control and format. Confirm you can sign for the address, it is valid on the source chain, and it can receive the source asset. For Bitcoin, ensure the address type is supported and can receive the transaction; for Solana, verify the correct public key rather than an EVM address.
4. Read the swap state before taking action. A deposit may still be waiting for source-chain confirmations or witnessing. Retry duration begins in State Chain blocks after the protocol registers the deposit; one State Chain block is about six seconds. Use the quote’s recommended retry duration where available. For scale, 100 blocks is an illustrative ten minutes, while a documented SDK quote example recommends five minutes; asset pair and quote determine the appropriate value.
5. Allow for a partial refund and fees. In a DCA swap, earlier chunks may already have converted and still go to the destination; only the unexecuted remainder returns in the source asset. A refund can also be reduced by a refund fee and source-chain broadcast cost, so do not expect the original deposit amount to reappear in full.

A Refund Is Different From a Failed Egress

A swap refund addresses a failure to execute under its price protections; it does not by itself resolve an output transfer that failed after the swap completed. If the record shows the destination egress was attempted, investigate that transfer’s status separately rather than waiting for the source refund address to receive funds.

Before acting, ask: can I control this address on the source chain, and does the swap record show a refund is actually due? If the deposit is still pending, give its confirmation and retry windows time to resolve; for the full process and next steps, see how Chainflip handles stuck swaps.