When a Swap Fails, Where Does the Refund Land?

If your swap failed and you want one sentence: the refund returns to the address your deposit came from, automatically, and there is nothing for you to configure. On UpSwap the upstream vendor (NEAR Intents / Relay) traces the deposit transaction and sends the returned amount back to that same source address — the industry calls this 原路退回, refund-to-source (model confirmed 2026-06-11).

This is good news and a warning at the same time. It is good news because you do not have to trust UpSwap to hold your money or to correctly type a refund address into a form — the refund is bound to on-chain reality, not to a support agent's input. It is a warning because the mechanism is only as safe as the wallet you sent from. If you started the swap from an address you do not fully control, the refund will faithfully travel to a place you cannot reach.

Why does a swap fail and trigger a refund at all? Most commonly, no solver fills your intent at the quoted price before it expires, so the deposit is returned — the mechanism is covered in our intent-based swap explainer. For the full map of where funds physically sit during a stalled or failed order, see Guide #1 on custody and fund location. This guide zooms in on the single downstream question those two raise: which address does the money come back to, and what makes that address a dead end.

UpSwap's refund has two paths, and knowing which one you are on tells you whether to wait or to open Telegram.

Path 1 — vendor auto-refund-to-source (primary). The upstream vendor traces your deposit transaction and returns the funds to the source address that signed it. This is the default and covers the large majority of failed swaps. You do nothing; the money reappears at the wallet you sent from once the vendor's refund cycle completes. Timing depends on the source chain's confirmation behavior — see Guide #3 on stuck and pending swaps for per-chain expectations.

Path 2 — distributor address + manual Telegram (fallback). If auto-refund-to-source is not possible, the vendor sends the funds to the UpSwap distributor refund address (the refundTo field in the routing call). UpSwap then contacts you via Telegram at @upswapservice using your orderId to return the funds manually. This path is the safety net for exactly the situations this guide is about — where the source address cannot cleanly receive an inbound transfer.

The critical, honest detail: the fallback is not uniform across chains. The 14 EVM chains covered (ethereum, arbitrum, base, optimism, polygon, bnb, avalanche, linea, scroll, blast, mode, hyperevm, hyperliquid, berachain) share one distributor EVM wallet (EVM_FEE_RECIPIENT, the same controllable address cross-chain), so a stranded EVM refund lands somewhere UpSwap can actually retrieve and forward. Non-EVM chains (Bitcoin, Solana, Tron, Sui, NEAR, Cardano, Stellar, XRP) currently have no controllable distributor wallet — they use a placeholder, and recovery relies entirely on manual Telegram coordination. This is verified against UpSwap's internal refund-address.ts logic dated 2026-06-11. We state it plainly because it changes what you should do before swapping from a non-EVM chain.

Cross-chain swaps that route through NEAR Intents / Relay use a deposit-address model: you send your funds to a one-time deposit address the vendor generates, and the vendor delivers the output to your destination. There is no account, no login-bound balance, no user profile the refund can look up. The only identity the system has for you is the on-chain fact of which address funded the deposit.

So when a refund is issued, the vendor does the one thing it can: it reads the deposit transaction and sends the money back to the from address of that transaction. It has no awareness of who you are, whether that address is a personal wallet or an exchange's omnibus, whether the contract at that address exists on this chain, or whether the address will credit an unexpected inbound. It just sends. This is why the source address is not a detail — it is the refund destination, full stop.

Contrast this with how some competitors handle it, because it clarifies UpSwap's design. ChangeNOW lets you optionally specify a refund address at exchange creation, and a refund can then go to the initial source address or that pre-specified address — but never to a new address supplied afterward (per ChangeNOW terms). SimpleSwap treats the refund address as an optional field requested per trading pair, and in some cases reserves the right to offer the original address as the only option (per SimpleSwap terms). UpSwap removes the field entirely: users do not set a refund address; it always goes to source. That is simpler and eliminates the class of errors where a user fat-fingers a refund address — but it puts the full weight on choosing a safe source wallet, which the next section is about.

See our UpSwap vs ChangeNOW comparison for how these refund models differ alongside fees and coverage. Data current as of 2026-06-26.

These are the four source wallets where auto-refund-to-source either fails to credit or lands somewhere unspendable — one concrete failure mechanism each.

1. CEX withdrawal address / exchange hot wallet. When you "swap from Binance," the deposit transaction originates from the exchange's shared hot wallet, not from an address you control. An auto-refund traces that deposit and sends the returned amount back to the hot wallet. Exchanges do not auto-credit an unexpected inbound tied to your account — the funds land in an omnibus wallet with no automatic link to your balance. You must open a manual recovery ticket, reviewed case-by-case, which may carry a fee, can take days to weeks, and is explicitly not guaranteed. Binance states recovery "is not guaranteed" and processes about 4,000 recovery requests per month; a typical unlisted-token-on-supported-network case carries a 20 USDT fee and up to 30 working days (Binance blog). If you have already hit this, our wrong-network recovery matrix walks the per-exchange ticket process end to end.

2. Single-use / rotated exchange deposit address. Some exchange deposit addresses are ephemeral or rotated per deposit. If a refund arrives after such an address has been de-provisioned or is no longer mapped to your account, the inbound may not credit and again requires a manual ticket. The refund tracing sends funds to whatever the deposit source was, with no awareness of that address's lifecycle. (This is a reasoned inference from published deposit-recovery behavior rather than a directly quoted refund policy — flagged honestly.)

3. Gnosis Safe / multisig not deployed on the refund chain. A Safe is a smart contract deployed per-chain via a proxy factory. The address is deterministic (CREATE2), so it can be identical across chains, but the contract only exists where it has actually been deployed. If a refund lands on a chain where your Safe is not deployed, the address exists as a target but nothing controls it, and funds can be lost. Worse, older CREATE-based factories or attacker-triggered deployments can let the same address be deployed with different owners on another chain — demonstrated in the Optimism/Wintermute incident where an attacker controlled ~20M OP tokens meant for a multisig. Receiving assets requires no signature, so the sender gets no error: the loss is silent (Safe docs + incident writeup).

4. Smart-contract wallet / ERC-4337 account that is counterfactual. Account-abstraction wallets often use counterfactual addresses computed via CREATE2. Such an address can receive a plain token transfer before the account is deployed — but the balance sits at an undeployed contract, and the owner cannot move it until the account is deployed on that specific chain (deployment normally triggers on the first outbound UserOperation). Cross-chain, the same counterfactual address is only identical if the same factory, salt, and init parameters are used; a different factory, salt, or init can yield either the same address controlled by someone else or a different address entirely. If the refund chain is one where your smart account is not deployed or is deployed with different owners, funds are received but unspendable. For per-chain address anatomy and verification, see Guide #6 on pre-send verification (EIP-4337 + ERC-4337 docs).

Data current as of 2026-06-26.

Here is the single most useful sentence in this guide: never start a cross-chain swap directly from a centralized-exchange withdrawal. Not because the swap won't work when it succeeds — it usually will — but because of what happens the one time it does fail and refund. The refund goes back to the source, and the source was Binance's, OKX's, or Coinbase's hot wallet, not you. Whether the extra on-chain hop is worth it in fees and time is exactly the tradeoff our Binance-withdrawal vs cross-chain-swap break-even matrix lays out.

Worked example. You want to swap BTC to USDT. You go to your exchange, hit withdraw BTC, and — to save one step — you paste the swap's deposit address as the withdrawal destination directly. The withdrawal executes from the exchange's shared BTC hot wallet. The swap fails (no solver fills at the quote). The vendor traces the deposit transaction and refunds the BTC to the address it came from: the exchange hot wallet. That inbound is now sitting in an omnibus wallet with no automatic tie to your account. You open a recovery ticket. Coinbase, for one, states it "does not have the ability to recover funds" outside a narrow supported-network allowlist, and where it does offer discretionary recovery it charges an additional 5% fee on amounts over $100 with no guarantee (Coinbase help; this figure is from a search snippet, so re-check the live page before relying on the exact number).

The correct sequence: withdraw BTC from the exchange to your own self-custody wallet (a wallet whose keys you hold), wait for it to arrive, then start the swap from that wallet. Now if the swap fails, the refund traces back to your self-custody address — which you control and which will simply show the returned balance. One extra on-chain hop buys you a refund path that does not depend on a support agent's discretion.

This rule applies to every pair, not just Bitcoin. The same trap sits behind ETH to USDT, SOL to USDT, and BTC to ETH: whatever chain you fund from, fund it from a wallet you control.

When auto-refund-to-source can't complete, UpSwap's safety net behaves differently depending on your source chain's family — and this is a real limitation worth stating plainly rather than papering over. Across UpSwap's coverage of 24+ chains, 111+ tokens, and 166 pairs, this EVM/non-EVM split is the single most important thing to know before you fund a swap.

EVM chains have an automatic distributor-wallet fallback. All 14 covered EVM chains share one controllable distributor wallet (EVM_FEE_RECIPIENT, the same address cross-chain). If a refund can't return to your source, it lands in that wallet, which UpSwap controls, and the team coordinates the return to you. Because the address is real and controllable, the stranded funds are recoverable by design. This covers ethereum, arbitrum, base, optimism, polygon, bnb, avalanche, and the rest of the EVM set (verified against internal refund-address.ts, 2026-06-11).

Non-EVM chains rely on manual Telegram coordination. For Bitcoin, Solana, Tron, Sui, NEAR, Cardano, Stellar, and XRP, there is currently no controllable distributor wallet — the code uses a placeholder. If a refund can't return to source on one of these chains, recovery is a manual process. This is a genuine gap, and we name it so you can prepare rather than be surprised.

The practical takeaway: EVM source + controlled wallet = refund is either automatic-to-source or automatically caught by the distributor. Non-EVM source = auto-refund-to-source is your reliable path and the manual fallback is a slower human process. Choose your source wallet accordingly, and this matters for USDT TRC20 to ERC20 and USDT ERC20 to TRC20 where Tron is non-EVM.

Run these five checks before you send the deposit. They take under a minute and they remove the most common cause of lost-refund tickets in this guide. One honest caveat: even a controlled source wallet is best-effort — if you fund from a non-EVM chain, the manual fallback is still a human process — so these checks maximize your odds rather than guaranteeing recovery.

1. Do I fully control this address? You must hold the private key (for an EOA) or be a confirmed signer with control (for a smart account) on the exact chain you're sending from. If the answer is "it's my Binance withdrawal," stop — that's a no.
2. Can this address receive an inbound transfer of the source asset? A refund is an ordinary inbound transfer. A plain EOA always can. An exchange address may not credit an unexpected one. A counterfactual smart account can receive but not spend until deployed.
3. Is it a plain EOA — or, if a smart account, is it deployed on the refund chain? When in doubt, prefer a plain EOA (MetaMask, Rabby, a hardware wallet's account) as the swap source. Smart accounts are fine only when you've confirmed deployment and ownership on that chain.
4. Is it definitely NOT a CEX-generated address? Not a withdrawal-origin hot wallet, not a single-use deposit address. If the address came from an exchange in any form, it fails this check.
5. For a Safe or multisig: is it deployed with your owners on the refund chain? Confirm the Safe exists on that exact chain and you control the owners. Safe's own guidance: make a test transaction first to confirm control before relying on it.

If all five pass, auto-refund-to-source should return your money to a wallet you can reach if the swap fails, and you never touch the fallback path. If any check fails, fix the source wallet before swapping — do not proceed and hope. For per-chain address-verification anatomy (and how to avoid address-poisoning traps while you're at it), see Guide #6 on pre-send verification.