The refund mechanism of an atomic swap is automatic, but how and when a refund is triggered depends on how the time locks are set on the two chains. If you do not complete your claim before the other party claims, or if the other party never acts, your funds will be returned to you after the time lock expires. There is no step where "customer support refunds you" — the refund is executed entirely by the contract logic.

A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!!
The core of atomic swaps: either everything completes, or everything is refunded
Atomic swaps solve a very specific problem: two people on different blockchains want to exchange their coins without trusting each other or trusting a third party. The answer is to use a hash time lock contract (HTLC) to bind two transactions together, so either both transactions succeed or neither happens.
This "all or nothing" outcome relies on two locks: a hash lock requires the person claiming the funds to reveal a secret value (the preimage), and a time lock sets a deadline for the funds. If the deadline passes and no one has claimed the funds using the correct secret value, the funds are automatically returned to the original owner.
The complete cross-chain process
Suppose Alice wants to exchange Bitcoin for Bob's Ethereum. The process usually has four steps:
Alice generates a secret value and locks her funds. Alice randomly generates a secret value
sand computes its hashH(s). She then creates an HTLC on the Bitcoin chain and locks her BTC into it. The condition of this HTLC is: whoever providessbefore timet1can take the BTC. She only tells BobH(s), notsitself.Bob locks his own funds using the same hash. Bob creates an HTLC on the Ethereum chain and locks his ETH into it. The condition is the same: whoever provides
sbefore timet2can take it. Note thatt2must be shorter thant1, which will be explained later.Alice claims Bob's ETH, and the secret value becomes public. Alice uses
sto unlock Bob's HTLC and takes the ETH. This action exposesson-chain, where anyone can see it.Bob uses the public
sto claim Alice's BTC. After Bob obtainss, he unlocks Alice's Bitcoin HTLC and takes the BTC. The swap is complete.
If any step is not completed, the unclaimed funds will be returned to the person who locked them after the time lock expires.
Why the time locks need to be staggered
t1 must be longer than t2, and not just slightly longer. The reason is: after Alice claims Bob's ETH, Bob needs time to use s to claim Alice's BTC. If t1 and t2 were the same length, or if t1 were shorter, Alice could claim the ETH and then Bob might find that Alice's time lock has already expired and the funds have been refunded by the time he tries to claim the BTC. Bob would then have lost his ETH for nothing.
On Bitcoin, this time difference can mean waiting for hours. Some research points out that to cover network delays and confirmation times, the interval between time locks may need to be set quite wide, and during that period the funds are locked up.
When refunds happen
Refunds are automatic, but the triggering conditions differ:
You lock your funds, but the other party never locks theirs. After your HTLC time lock expires, the funds are returned to your address. You do not need to do anything; the contract will allow the refund transaction to be executed once the time arrives.
Both parties lock funds, but Alice never claims Bob's funds. The time locks on both chains expire, and each party gets their own coins back.
Alice claims Bob's coins, but Bob fails to claim Alice's before t1. This is the most dangerous case. If Bob acts too slowly, or if Bitcoin network congestion prevents his claim transaction from being confirmed before t1, Alice's BTC will be refunded to Alice, while Bob has already lost his ETH. Bob's only hope is that Alice is willing to return it, or to find her through on-chain data and negotiate. This ultimately depends on whether Alice is honest; the protocol itself does not protect Bob from loss in this situation.
Limitations and risks
Atomic swaps sound elegant, but in practice they have quite a few limitations.
Both chains must support compatible HTLCs. Bitcoin can implement them with scripts, and Ethereum can simulate them with smart contracts. But if the hash algorithms of the two chains are incompatible, or if one chain does not support time lock conditions at all, an atomic swap cannot be done.
The "race condition" of time lock windows. Academic research points out that when the refund windows overlap, problems such as "double claiming" or "timeout competition" may occur. An attacker can rush to broadcast a refund transaction just after the time lock expires, while another claim transaction is also competing to be included. The final result depends on which transaction gets confirmed first. This is not something ordinary users can control; it depends on the ordering of miners or validators.
Poor user experience. You need to manually generate a hash, lock funds, monitor whether the other party acts, and claim within the correct time window. If any step goes wrong or you miss the window, your funds are refunded. This is one of the reasons atomic swaps have not been widely adopted so far.
Limited liquidity. Atomic swaps are peer-to-peer. You need to find someone who is willing to trade with you at the amount and price you want. There is no order book matching and no market maker. It is fine for small amounts, but for large amounts it is almost impossible to find a counterparty.
If you just want to swap coins across chains, using a centralized exchange or a cross-chain bridge is much simpler in terms of experience. The value of atomic swaps lies in "trusting no one," but the cost is that you have to bear the operational complexity and the risks of the time windows yourself.

A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!!
References
- Binance Academy · Atomic Swap Glossary Entry, page publication or update date: not indicated on the page; verification date: not indicated on the page.
- Gate Learn · Atomic Swap Glossary Entry, page publication or update date: not indicated on the page; verification date: not indicated on the page.
- CNIPA · Cross-Chain Atomic Swap Related Patent Text, page publication or update date: not indicated on the page; verification date: not indicated on the page.
- Foresight News · Atomic Swap Related Technical Article, page publication or update date: not indicated on the page; verification date: not indicated on the page.
- IACR Cryptology ePrint Archive · 2019 Atomic Swap Related Academic Paper, page publication or update date: not indicated on the page; verification date: not indicated on the page.
- European Patent Office · Cross-Chain Atomic Swap Related Patent Text, page publication or update date: not indicated on the page; verification date: not indicated on the page.
- Binance Academy · Atomic Swaps Explained Article, page publication or update date: not indicated on the page; verification date: not indicated on the page.
- IACR Cryptology ePrint Archive · 2024 Atomic Swap Related Academic Paper, page publication or update date: not indicated on the page; verification date: not indicated on the page.
- IACR Cryptology ePrint Archive · Atomic Swap Race Condition Related Academic Paper, page publication or update date: not indicated on the page; verification date: not indicated on the page.


