An atomic swap coordinates 2 asset transfers across separate systems. Bitcoin, EVM chains, Lightning, and Arkade each follow different settlement rules.
The swap links those transfers so that the action needed to claim 1 side also provides the information needed to claim the other. Time-based recovery paths protect participants when the expected sequence stops.
The swap works by coordinating separate transfers so that the action needed to claim 1 side also provides the information needed to claim the other. Time-based recovery paths protect participants when the expected sequence stops.
That coordination is usually built with a Hash Time-Locked Contract, or HTLC. An HTLC combines a secret-based claim path with a time-based refund path. Together, those 2 conditions turn a pair of independent transfers into 1 conditional exchange.
If you want the broader definition first, read: What Is an Atomic Swap? Bitcoin Swaps Without Custodians or Liquidity Pools.
An HTLC creates 2 ways to spend the funds
An HTLC is best understood as a lock with 2 valid exits.
Exit 1 is the success path. A recipient can claim the funds by presenting a secret, usually called a preimage, that matches a previously agreed hash.
Exit 2 is the recovery path. If nobody completes the swap before a deadline, the original sender can recover the funds after the time lock expires.
These paths solve different problems. The hash lock links the 2 sides of the exchange. The time lock prevents funds from remaining locked forever if a participant disappears, a route fails, or the swap is otherwise interrupted.
The basic relationship looks like this:
secret S → hash H
Before timeout: recipient can claim by revealing S
After timeout: sender can refund without SThe hash can be shared safely before the swap starts. Knowing H does not reveal S, provided the secret was generated with enough entropy. A participant can therefore build a spending condition around the hash without giving away the information that unlocks it.
Bitcoin supports the time-based part of this design through script primitives such as CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY. BIP 65 specifies absolute lock times based on a block height or timestamp. BIP 112 adds relative lock times measured from the age of the output being spent. Either primitive can make a refund branch unavailable until its deadline, depending on the protocol design.
On an EVM chain, the same economic logic is implemented in a smart contract. The exact code and hash function may differ, but the contract still needs a claim path, a refund path, and an enforceable deadline.
How an atomic swap works step by step
Consider a simplified swap in which Alice sends BTC and receives USDC from a liquidity provider.
1. Alice generates the secret
Alice creates a random secret S. She then derives a hash from that secret and shares the hash, not the secret, with the service coordinating the swap.
The secret is the critical piece of information. At the beginning of the swap, Alice knows it and the liquidity provider does not.
2. Alice locks the BTC
Alice funds the Bitcoin side under conditions tied to the secret and a refund deadline. Depending on the route, that side may use Bitcoin on-chain, Lightning, or an Arkade VHTLC.
At this stage, the liquidity provider cannot simply take the BTC. Claiming it requires the secret. Alice also cannot immediately reclaim the funds once the swap has progressed, because the refund branch becomes available only after its deadline.
3. The liquidity provider locks the USDC
After detecting and validating Alice's funding, the provider locks the agreed USDC in an EVM HTLC. This contract is tied to the same underlying secret relationship and gives Alice a shorter window in which to claim.
The order matters. Each side should verify the other side's lock conditions, amount, asset, recipient, and deadline before taking the action that advances the swap.
4. Alice claims the USDC
Alice claims the stablecoins by revealing S. The EVM contract verifies that the secret produces the expected hash and releases the USDC to the designated destination.
This is the decisive action. Claiming the USDC makes the secret available to the liquidity provider, either publicly through the relevant transaction data or through the protocol flow used by that rail.
5. The liquidity provider claims the BTC
The provider extracts the revealed secret and uses it to satisfy the Bitcoin-side condition. Both sides of the exchange are now settled.
The 2 transfers did not happen in 1 shared transaction. They became economically linked because completing Alice's claim disclosed the information required for the provider's claim.
Why atomic swap timeouts are asymmetrical
The 2 HTLCs should not normally expire at the same moment.
Once Alice reveals the secret to claim the provider's USDC, the provider still needs time to observe that revelation and claim Alice's BTC. If both refund windows closed simultaneously, Alice could wait until the final moment, reveal the secret, claim the USDC, and leave too little time for the provider to complete the other side.
Atomic swap designs therefore use staggered deadlines. The HTLC claimed initially expires earlier. The opposite HTLC, claimed afterward with the newly revealed secret, expires later. The difference between those deadlines gives the counterparty time to observe the revelation and react.
According to Satora's current documentation, its mainnet parameters assign 24 hours to the client-funded HTLC and 12 hours to the server-funded HTLC. The funded asset changes with the swap direction, but the principle does not. The client controls the secret, claims the server-funded side first, and the server retains time to use the revealed preimage on the client-funded side.
This is the same underlying safety concern found in routed Lightning payments. HTLC expiries are staggered across a route so that an intermediary that learns the preimage still has time to settle its incoming HTLC, including when an on-chain fallback becomes necessary.
Longer timeouts provide more room to recover from congestion, confirmation delays, or temporary unavailability. They also keep capital locked for longer when something fails. Timeout design is therefore an operational trade-off, not a decorative protocol parameter.
What HTLCs guarantee
HTLCs give atomic swaps a clear settlement guarantee. Neither participant needs to give a custodian unilateral control over both sides of the trade. The hash lock connects the claims, while the time lock makes an interrupted swap recoverable.
This design reduces custody risk and the risk of final 1-sided settlement. It also makes the possible outcomes explicit. Funds can be claimed with the correct secret, or recovered through the refund path after the deadline.
These guarantees remain specific. A reliable swap still depends on correct scripts and smart contracts, available liquidity, monitoring, fee estimation, chain access, and recovery logic. Coordinators, APIs, relayers, and market makers can support the flow without taking custody of both sides.
The result is not “no trust anywhere,” but a more precise property. Control over the funds remains constrained by transparent and verifiable protocol conditions.
Where Satora fits in the flow
For a developer, the cryptographic primitive is only 1 layer of the product.
A usable swap integration must generate and protect secrets, request quotes, monitor funding, validate amounts, trigger claims, track confirmations, expose deadlines, and recover from interrupted flows. It must also translate different Bitcoin and EVM execution models into states that a wallet or payment app can display clearly.
Satora packages that lifecycle for swaps connecting Bitcoin rails, including on-chain BTC, Lightning, and Arkade, with EVM stablecoin liquidity. The current flow uses HTLC or VHTLC conditions on the Bitcoin side and EVM smart contracts on the stablecoin side. Its state machine exposes both the successful sequence and the refund paths that integrators need to handle.
This is where atomic swap infrastructure becomes useful beyond the protocol diagram. The goal is not to hide the risks behind a “trustless” label. It is to make each custody assumption, transition, deadline, and recovery action explicit enough for a real application to manage.
Explore Satora's HTLC architecture and swap state machine
FAQ
What is the difference between a hash lock and a time lock?
A hash lock lets funds be claimed by revealing a secret that matches a known hash. A time lock delays another spending path until a deadline or relative period has passed. In an HTLC, the hash lock supports successful settlement and the time lock supports recovery.
Is the secret stored on both blockchains?
No. The swap starts with hash commitments derived from the secret. The secret becomes available when the relevant claim is executed or transmitted through the payment protocol. The other participant can then use it to settle the opposite side.
Why does 1 HTLC expire before the other?
The stagger gives the participant who learns the secret afterward enough time to claim. Equal deadlines could create a race in which 1 side claims near expiry while the other side no longer has time to react.
Does a refund happen immediately when a swap fails?
Not always. Some flows can support an early exit before the other side is funded. Otherwise, the relevant time lock must expire before the refund path becomes available. Recovery can therefore be safe without being instant.
Do all atomic swaps use HTLCs?
No. HTLCs are the best-known construction, but atomic swaps can also use other cryptographic techniques, including adaptor signatures. The required property is that the 2 sides are conditionally linked with a safe failure path.
Conclusion
Atomic swaps work by linking separate transfers through information and time.
The hash lock makes knowledge of 1 secret the condition for claiming funds. Revealing that secret on 1 side gives the other participant what they need to settle the opposite side. The time lock makes failure recoverable by opening a refund path when the expected sequence does not complete.
That mechanism prevents a custodian from becoming the default settlement layer, but it does not turn the swap into 1 instantaneous cross-chain transaction. A safe implementation still needs asymmetrical deadlines, monitoring, explicit states, correct fee handling, and recovery UX.
The cryptography defines the possible outcomes. The state machine determines whether developers and users can navigate them safely.