Who actually controls the refund when a swap does not complete

07 September 2026

The refund is controlled by the same automated system that runs the swap itself. No human holds the keys to your returned funds at any point.

When a swap fails to complete, the system must decide whether to release a refund. That decision is made by the same piece of software that manages the swap addresses and escrow wallets. The refund process is fully deterministic: if the system detects that the swap cannot finish - because you sent too little, sent to the wrong network, or the timer expired - it triggers a return transaction. The return transaction is constructed and signed by the software, using the private keys stored on the server that generated the swap address in the first place.

There is no refund department. There is no support agent who can push a button to send your money back. The software either refunds automatically when certain conditions are met, or it does not. If the conditions for a refund are not programmed into the swap logic, no refund will occur no matter how many tickets you open.

This design exists for a reason. A human-controlled refund system would be a central point of failure. An employee could be coerced, bribed, or hacked. An automated system removes that risk - but it also removes flexibility. If your deposit arrives in a way the software was not programmed to handle, the money sits in the swap address until someone manually recovers it, which may not be possible.

What actually triggers a refund depends on the exact failure mode. For example, if you sent less crypto than the quote required, the system may hold the deposit and wait for the missing amount. If you never send the rest, the swap eventually times out and a refund fires. But if you sent exactly the wrong amount - below a minimum threshold that the software considers "dust" - the refund logic may not fire at all. That is covered on the sibling page about sending less than the quote required.

The swap address itself is a temporary wallet generated fresh for each trade. The private key for that address is stored on the server that created it. When the swap either completes or fails, the software sweeps the balance out of that temporary address. For a completed swap, it sends onward to the destination. For a failed swap, it sends back to the deposit address you provided. After the sweep, the temporary address is discarded. No one retains control over it.

This is why you must provide a return address when you start a swap. That return address is the only destination the software will use for a refund. If you lose access to that address, the refund goes there anyway. The software has no way to redirect it. There is no "recovery" option because the system is deliberately blind to who you are. It knows only the addresses you gave it.

The hub page titled "What a failed swap leaves behind and how to recover it" explains the broader situation: what you can actually get back, what is lost forever, and what steps you can take when the automated refund does not arrive. That page is the next thing to read because it covers the limits of this automated control and what happens when the software cannot complete a refund on its own.

In short: the software controls the refund. Not a person, not a support team, not a third party. The code decides. If the code does not see a valid refund condition, the money stays where it is until someone with server access intervenes - and that intervention is rare and slow.

Back to bridges