Which Refund Address to Use on a Crypto Swap (and Which Not To)
The refund field decides where your money goes when an order cannot complete. Why it has to sit on your deposit network, why an exchange deposit address fails on tag chains, and the ten-second habit that prevents it.
Every instant swap asks you for two addresses, and only one of them gets any real thought. The payout address is obvious — that is where coins land. The second field, the refund address, usually gets whatever is open in another tab: a software wallet, a hardware wallet, an exchange deposit address, or a string copied from a chat six months ago. That second field is where expensive mistakes live. At the time of writing (2026-10-15) our quote API answered 100 USDT-TRC20 with 0.1621607 XMR and 0.01 BTC with 1.46243728 XMR — amounts that never reach you if an order fails and the refund lands somewhere nobody can spend from. This article covers which address to use, and what actually happens when it is wrong. (recovering misdirected funds)
The refund field sits on your deposit network — not your payout network This is the part most people get backwards, and it is a one-sentence rule: a refund returns the asset you sent, on the chain you sent it from. The API documentation shows it in a single request — an eth-eth order with a Bitcoin payout address (bc1q…) and an Ethereum refund address (0x…), two different networks in one order, with no network selector to help you. Put the payout network's address in the refund field and the order will usually be refused for an invalid address format. Occasionally it is accepted and the problem surfaces later, when the refund is broadcast and cannot be spent by the receiving chain. As of writing, VeilSwap aggregates 541 assets across 74 networks, so the two addresses in your order will land on different chains more often than not. (recovering misdirected funds)
When the refund path is actually used Refunds are the edge of the flow, not the main road. An order opens in waiting_deposit and moves through confirming and settling to paid. If nothing arrives within 30 minutes, the deposit address expires and the order closes — no funds were ever held, so there is nothing to refund. If your deposit does arrive but the swap cannot complete (a route disappears, a provider declines the fill, the amount falls outside the pair limits), the deposited asset is returned. One honest limit, stated on the order page: an amount far below the announced deposit cannot be processed, and cannot be refunded either. So keep the transaction id from the wallet you sent with. When a refund is broadcast, the order page shows its own hash, which means both legs of the story stay independently checkable on-chain.
Why a self-custody address beats an exchange deposit address: three concrete consequences First, attribution. An exchange deposit address belongs to an account that passed identity checks. If your refund lands there, the exchange observes the incoming transfer, its amount, its timing and its source — a refund into a wallet you control stays a movement between addresses you own. Second, and this is the mechanical one: memo chains. Seven of the assets in the catalogue require a memo or tag alongside the address (XRP, XLM, HBAR, ATOM, Algorand-USDC and Stacks among them). A refund sent to an exchange address on those chains without the correct tag reaches a pooled wallet, and crediting then depends on a support procedure rather than on the chain. Third, minimums. Exchanges set their own thresholds before a deposit is credited at all, and on 2026-10-15 one XMR was quoted at 0.00657903 BTC — a refund of that size can sit below a threshold nobody read. Self-custody removes all three problems at once.
The rule that prevents most of this: send from the wallet you want money returned to Unless you specify otherwise, a refund goes back to the address you sent from — so the safest refund destination is the wallet doing the sending. It is on the correct network by construction, and you already hold it. The trap is exchanges. When you withdraw from an exchange, the address that spends the money is the exchange's hot wallet, not your deposit address. A refund arriving at a hot wallet is an internal accounting event you cannot see, produce or argue with, and some of those credits never happen at all. If your funds already sit on an exchange and have to come from there, spend ten extra seconds at order creation and fill the refund field with an address from a wallet you hold, on the same network as the deposit.
What a refund costs, and why cost is rarely the problem A refund is an ordinary on-chain transaction, so it pays that network's going rate. On 2026-10-15 the Bitcoin mempool was light: 80,607 pending transactions totalling 39.47 million virtual bytes, with the recommended fastest rate at 1 sat/vB. A typical single-input, two-output SegWit transaction is about 141 vB, so it costs roughly 141 satoshi — 0.00000141 BTC. At that level, cost is almost never the reason a refund does not work. Other networks price differently: a TRC20 transfer consumes energy and bandwidth instead of bidding into a rate market, so its timing depends on the sender's energy position rather than on how much anyone pays. The useful conclusion is that on the chains people actually use, money is rarely the problem. The address is.
Five checks before you send One: network match — the refund destination has to be on the deposit asset's network, not the payout's. Two: memo or tag — if the asset needs one, the order flow flags it; copy it exactly, it is not optional and it is not your order id. Three: source check — read the address your wallet will actually spend from; if it belongs to an exchange or a contract, expect a refund to land somewhere you cannot retrieve on your own. Four: format sanity — good wallets reject malformed addresses before signing; if a swap form accepted an address your wallet refuses, stop and re-check. Five: fresh copy — paste from the wallet itself rather than from chat history, a screenshot, or a notes file that may have been edited since.
The mistakes that actually happen Almost every failed refund traces back to one of six habits: filling an exchange deposit address that has since been retired for that account; putting the payout network's address in the refund field; depositing from an exchange hot wallet, so the address you sent from was never yours; skipping the tag on a memo chain; sending from an address that cannot receive funds back, such as a smart contract or a relayer a wallet's internal swap feature uses; and underpaying by so much that no refund is possible at all. None of these need bad luck, just about a minute of attention at order creation. Everything needed to reconstruct a case is on the order page: your order's own deposit address and its 30-minute window, the payin hash for what you sent, the payout hash for what was delivered, a refund hash when money comes back, and literal status names — waiting_deposit, confirming, settling, paid, expired, refunded, failed.
The refund field looks like a formality and behaves like insurance. Fill it with an address on the deposit network, from a wallet you hold, with the correct tag when the chain demands one, and the failure modes described above stop applying to you: an order that cannot complete simply returns what you sent, to a place you can spend it from. If you have not tried the flow yet, the practical version is short — choose the pair, read the quote before you commit, set both addresses deliberately, and send from a wallet you own. Every rate quoted here is as of writing (2026-10-15) and moves with the market; the live quote on the exchange page is the number that counts.