Atomic Swaps Explained: How HTLCs Settle Cross-Chain Trades

Two strangers, two blockchains, no escrow agent, and no way for either chain to see what happens on the other. Atomic swaps explained simply: this setup can still trade safely, because neither party can walk off with both sides. The mechanism needs only a 32-byte secret, a hash function, and two clocks set to different times.

This guide covers atomic swaps at the protocol level: the Bitcoin Script that locks the funds, the matching EVM contract, why the two timelocks have to be asymmetric, and the failure modes that whitepaper diagrams tend to leave out. It's a follow-up to our explainer on delivery-versus-payment (DvP) settlement. An atomic swap is DvP done across two ledgers that can't see each other. At the end we compare that model with light-client bridge verification, a different way to reach trust-minimized cross-chain settlement.

Key Takeaways:An atomic swap is a cross-chain trade where both legs settle or both refund, enforced by Hash Time-Locked Contracts (HTLCs) on each chain.An HTLC releases funds to whoever reveals the preimage of a hash before a deadline, and returns them to the sender after that deadline, as standardized for Bitcoin in BIP-199.The party who generates the secret must lock first with the longer timelock, otherwise they can refund one leg and claim the other.Academic work models an HTLC swap as an American call option without a premium, which lets the secret holder abandon the trade for free if prices move (arXiv:2211.15804).Light-client bridges don't need a live counterparty: the destination chain checks an SPV proof of the Bitcoin transaction itself.

Table of Contents

• What Is an Atomic Swap, Precisely?
• How Does an HTLC Work in Crypto? The Anatomy of a Hashlock and Timelock
• How Atomic Swaps Work: A Step-by-Step BTC–ETH Transaction Flow
• Why Must the Timelocks Be Asymmetric?
• What Can Go Wrong? Five HTLC Failure Modes
• Beyond Hashlocks: Adaptor Signatures, PTLCs, and Submarine Swaps
• Bitcoin Atomic Swap vs Light-Client Bridge: Which Settlement Model Fits?
• Practical Takeaways for Developers and Traders
• Frequently Asked Questions

What Is an Atomic Swap, Precisely?

An atomic swap is a peer-to-peer exchange of assets on two different blockchains in which a cryptographic condition links both transfers, so either both complete or neither does. "Atomic" is used here the way database engineers use it: the operation can't be left half-done.

The idea goes back to a 2013 Bitcointalk proposal by Tier Nolan, recorded on the Bitcoin Wiki's atomic swap page. The first widely publicized live swaps between independent chains came in 2017, including a Litecoin–Decred trade. Today, Garden's 2026 protocol survey names Garden, Boltz, Komodo AtomicDEX, and Atomiq as the main implementations. Garden says it has settled more than $2.4B atomically, but that is a vendor figure, not an independently audited one.

The underlying problem is simple. Bitcoin can't read Ethereum's state, and Ethereum can't natively read Bitcoin's. You can't write a contract that says "release my ETH when your BTC arrives," because neither chain can check the other.

HTLCs work around this by linking the two chains through shared knowledge instead of shared state. The same secret unlocks both legs, and using it on one chain makes it public for the other.

How Does an HTLC Work in Crypto? The Anatomy of a Hashlock and Timelock

A Hash Time-Locked Contract is a spending condition with two mutually exclusive paths: a claim path unlocked by a hash preimage, and a refund path unlocked by time. Every HTLC in crypto, from on-chain swaps to Lightning payment routing, is a variation on these two branches.

The hashlock

The initiator (call her Alice) generates a random 32-byte secret s and computes H = SHA-256(s). She publishes H and keeps s to herself.

Because SHA-256 is preimage-resistant, nobody can work out s from H. Anyone who presents an s' where SHA-256(s') = H has shown they know the secret. Once that proof appears on-chain, it is public.

The timelock

Bitcoin offers two timelock opcodes. BIP-65's OP_CHECKLOCKTIMEVERIFY (CLTV) enforces an absolute block height or timestamp. BIP-112's OP_CHECKSEQUENCEVERIFY (CSV) enforces a delay relative to when the output was confirmed.

Since BIP-113, timestamp-based locks are measured against the median time of the past 11 blocks, so a single miner can't fake a timestamp to open a refund early. On EVM chains the equivalent is a block.timestamp comparison inside the contract.

The Bitcoin HTLC script

Here is a typical HTLC locking script, usually wrapped in P2WSH, that pays Bob if he reveals s and refunds Alice after time T_A:

OP_IF OP_SIZE 32 OP_EQUALVERIFY OP_SHA256 <H> OP_EQUALVERIFY <Bob_pubkey> OP_ELSE <T_A> OP_CHECKLOCKTIMEVERIFY OP_DROP <Alice_pubkey> OP_ENDIF OP_CHECKSIG

Bob claims with the witness stack <Bob_sig> <s> 1. Alice refunds with <Alice_sig> 0, in a transaction whose nLockTime is at or past T_A and whose input sequence isn't final. There's no "smart contract" in the EVM sense. It's a predicate that every Bitcoin full node evaluates.

The OP_SIZE 32 check matters more than it looks. Without it, Alice could reveal a preimage of a different length that one chain accepts and the other handles differently, leaving Bob unable to use the secret on the chain he cares about. The Lightning BOLT #3 HTLC scripts enforce 32-byte preimages for this reason.

The EVM counterpart

The Ethereum leg is a contract with three functions. In simplified Solidity:

function lock(bytes32 h, address recipient, uint256 deadline) payable; function claim(bytes32 id, bytes32 preimage) { require(sha256(abi.encodePacked(preimage)) == swaps[id].h); require(block.timestamp < swaps[id].deadline); payable(swaps[id].recipient).transfer(swaps[id].amount); } function refund(bytes32 id) { require(block.timestamp >= swaps[id].deadline); payable(swaps[id].sender).transfer(swaps[id].amount); }

Both legs must use the same hash function. EVM chains expose SHA-256 as precompiled contract 0x02, so SHA-256 is the usual choice for BTC–EVM swaps, even though Solidity developers normally default to keccak256.

If a chain can't compute the counterparty's hash function, a hashlock swap between them isn't possible. That is one reason hash-function compatibility limits which chain pairs can swap.

How Atomic Swaps Work: A Step-by-Step BTC–ETH Transaction Flow

An atomic swap runs in four on-chain transactions: two locks and two claims, in a strict order. Say Alice holds BTC and wants ETH, and Bob holds ETH and wants BTC. The amounts and timelocks are illustrative.

1. Negotiate off-chain. Alice and Bob agree on amounts, exchange public keys, and choose timelocks: T_A = 48 hours on Bitcoin and T_B = 24 hours on Ethereum. Alice generates s and sends Bob only H.
2. Alice locks BTC (tx 1). She funds the P2WSH HTLC above: payable to Bob with s, refundable to Alice after T_A.
3. Bob verifies and waits. Bob checks that the script commits to the agreed H, amount, and T_A, then waits for enough Bitcoin confirmations that the transaction won't be reorged out. In the model from the HTLC settlement paper on arXiv, Bob locks at t₂ = t₁ + τ_a, where τ_a is Bitcoin's confirmation delay.
4. Bob locks ETH (tx 2). He calls lock(H, Alice, now + 24h) on the Ethereum HTLC.
5. Alice claims ETH (tx 3). She calls claim(id, s). This step makes the trade irreversible, because s is now in Ethereum calldata for anyone to read.
6. Bob claims BTC (tx 4). Bob, or a watchtower acting for him, reads s from the Ethereum transaction and spends the Bitcoin HTLC through the claim branch before T_A.

Notice where the asymmetry sits. Alice can't claim the ETH without revealing the secret that unlocks her BTC for Bob. That reveal is the delivery-versus-payment link, and it runs on information, not on a trusted escrow.

Why Must the Timelocks Be Asymmetric?

The party who knows the secret must have the longer timelock on their own funds, so the counterparty always has a guaranteed window to claim after the secret is revealed. Get this wrong and the swap stops being atomic.

Suppose the timelocks were reversed: Alice's BTC refunds after 24 hours and Bob's ETH after 48. Alice waits 24 hours, refunds her BTC, and then claims Bob's ETH with s in hour 25. She ends up with both legs.

The rule T_A > T_B rules this out. Alice has to reveal s before T_B, which leaves Bob at least T_A − T_B to use it.

How big should that gap be? It has to cover the worst case: Alice reveals s one second before T_B, the Bitcoin mempool is congested, and Bob's claim must still confirm before T_A. A 24-hour gap equals about 144 Bitcoin blocks at the ~10-minute target. That is a cushion, but a thin one if Bob's node is down or fees spike. Production values vary by implementation, and the public research doesn't standardize them.

What Can Go Wrong? Five HTLC Failure Modes

HTLCs are atomic only if both parties stay online and the chains keep including transactions on time. In practice, the following five issues account for most of the gap between "trustless in theory" and "safe in production."

1. The free option problem. Between Bob's lock and T_B, Alice holds the right but not the obligation to complete the trade. If the price moves against her, she does nothing and refunds after T_A. Han et al. (2019) formalized this as an American call option with no premium. arXiv:2211.15804 proposes collateral that scales with amount × lock time. In its example, an aborting initiator pays the counterparty 1.5Q in compensation. No major production protocol has been confirmed to deploy this.
2. Liveness risk. If Bob is offline between Alice's claim and T_A, Alice can refund her BTC while already holding his ETH. The system is trustless toward counterparties, but it still relies on your own uptime, which is why serious implementations run watchtowers.
3. Fee and mempool griefing. A claim that doesn't confirm before the deadline is worth nothing. Fee spikes, low-fee transactions pinned in the mempool, or a counterparty broadcasting a competing refund at the boundary can all push a valid claim past its window.
4. Reorgs on the first leg. If Bob locks after too few confirmations and Alice's tx 1 is reorged out, Bob's ETH is locked against a BTC leg that no longer exists. This is why the τ_a wait isn't optional.
5. Linkability. Both HTLCs commit to the same H, and both claims reveal the same s. A chain analyst can match the two legs trivially. Classic hashlock swaps are not private.

Our view: the free option problem isn't a bug that someone will eventually patch. It follows directly from separating "lock" from "commit." Any design where one party chooses when to reveal gives that party optionality.

Beyond Hashlocks: Adaptor Signatures, PTLCs, and Submarine Swaps

Modern swap protocols replace the hash preimage with a signature-embedded secret, which fixes the linkability problem and allows swaps with chains that have no scripting. Three variants matter.

Adaptor signatures and scriptless scripts

An adaptor signature is a Schnorr or ECDSA signature that has been "encrypted" by a secret scalar t. With Schnorr, a pre-signature s' becomes a valid signature s = s' + t. Publishing s lets anyone holding s' compute t = s − s'.

The secret travels inside an ordinary-looking signature, so no hash appears on-chain. This is how BTC–XMR swaps work despite Monero having no HTLC opcodes. Bitcoin Optech's adaptor signature reference covers the construction.

PTLCs after Taproot

Point Time-Locked Contracts lock to an elliptic-curve point T = t·G rather than a hash. Since Taproot activated at block 709,632 in November 2021, Bitcoin's BIP-340 Schnorr signatures make PTLCs practical, and a cooperative swap can look like a single-key spend.

Submarine swaps

Submarine swaps, which Boltz popularized, link an on-chain HTLC to a Lightning payment that uses the same payment hash. They move BTC between layers rather than between chains. The settlement logic is the same two-branch HTLC.

Bitcoin Atomic Swap vs Light-Client Bridge: Which Settlement Model Fits?

An atomic swap settles a bilateral trade between two people who each hold the other's desired asset. A light-client bridge settles a one-sided transfer by having the destination chain verify that a Bitcoin transaction happened. Both avoid trusted custodians, but they put the remaining trust in different places.

A light-client bridge works roughly like this. Relayers submit Bitcoin block headers to a contract on the destination chain. The contract checks proof-of-work and chain continuity, following the Simplified Payment Verification design in section 8 of the Bitcoin whitepaper.

A user then submits a Merkle proof that their transaction is included in a header with enough confirmations on top. No counterparty has to be online with matching ETH, and no secret has to be revealed in time.

TeleSwap, a Bitcoin bridge using SPV light client verification, uses this model. Nothing is minted without a verified Bitcoin transaction: once the light client verifies the user's BTC deposit, TeleBTC is minted, a 1:1 collateral-backed BTC representation. Lockers holding the BTC are collateralized and slashable.

On that base, the protocol reports $529.8M in total volume bridged across 561,288 bridge transactions and 13 supported networks, per TeleSwap network stats (retrieved 2026-10-25).

Custodial wrapping carries a different risk profile, which we cover in our WBTC bridge custody risk vs trustless bridges comparison.

The tradeoff is structural. An HTLC swap trades custody risk for coordination risk: you trust no one with your coins, but you need a counterparty with the right asset, at the right size, at the right moment, who won't use the free option against you.

Light-client verification removes the coordination problem, because the proof is about Bitcoin, not about another person. What it adds is reliance on correct header relay and on adequate collateral. Which model is "more trustless" depends on which of those risks you're better placed to manage.

Practical Takeaways for Developers and Traders

• Enforce 32-byte preimages on every leg. Skipping the size check is a classic cross-chain HTLC pitfall.
• Choose timelock gaps for the worst-case mempool, not the average one. Assume the secret is revealed at the last moment and fees spike at the same time.
• Run a watchtower or stay online. If you are the second party to claim, an offline node can mean losing your funds.
• Wait for real confirmations before locking the second leg. A reorged first leg leaves you exposed.
• Price the option. As a market maker in HTLC swaps, you are writing an option. Charge for it or require collateral.
• Choose the model to match the job. For a peer-to-peer BTC–XMR trade, an adaptor-signature swap fits. To move BTC into an EVM asset without finding a counterparty, a light-client route avoids the coordination problem. See our BTC to WBTC on Ethereum wallet guide for one example, or our 7-step trustless BTC swap guide for the full process.

Frequently Asked Questions

What is an HTLC in crypto?

An HTLC (Hash Time-Locked Contract) is a spending condition that pays a recipient who reveals the preimage of a hash before a deadline, and refunds the sender after that deadline. On Bitcoin it is written in Script with OP_SHA256 and OP_CHECKLOCKTIMEVERIFY. On EVM chains it is a contract with lock, claim, and refund functions. HTLCs underpin both atomic swaps and Lightning payment routing.

How do atomic swaps work step by step?

The initiator locks funds to a hash with a long timelock, the counterparty locks to the same hash with a shorter timelock, the initiator claims by revealing the secret, and the counterparty uses that revealed secret to claim. That makes four on-chain transactions. The initiator can't collect without revealing the secret, so either both legs settle or both refund.

Is a Bitcoin atomic swap completely trustless?

It is trustless toward your counterparty but not toward your own uptime or the chain's fee market. If you are offline when you need to claim, or your claim fails to confirm before the timelock expires, you can lose funds. The initiator also gets a free option to walk away if prices move.

Why does the initiator need the longer timelock?

The initiator holds the secret, so their refund must unlock later than the counterparty's, or they could refund their own funds and then claim the counterparty's. The gap T_A − T_B is the counterparty's guaranteed window to use the revealed secret.

Can you do an atomic swap with Monero or other non-scripting chains?

Yes, by using adaptor signatures instead of hashlocks. The secret is embedded in a signature, so it can be extracted when the signature is published. That requires no hash opcode on the non-scripting chain, and it also hides the link between the two legs.

How is an atomic swap different from a light-client bridge?

An atomic swap needs a live counterparty holding the other asset, while a light-client bridge verifies a Bitcoin transaction directly on the destination chain using an SPV proof. Atomic swaps carry coordination and free-option risk. Light-client bridges rely instead on header relay and collateralized participants, and they don't require the user to stay online after sending BTC.

Conclusion

An atomic swap settles a cross-chain trade with a single shared secret. The hashlock ties the two legs together, the asymmetric timelocks keep the secret holder from taking both, and the order of reveals turns two blind ledgers into DvP settlement. The costs are structural too: a free option for the initiator, liveness requirements for both parties, and a coordination problem that keeps liquidity thin.

If you want trust-minimized settlement without needing a counterparty, light-client verification is the other route to examine. To see SPV-verified Bitcoin settlement in practice, read the protocol details at teleswap.xyz/docs or try a BTC swap at teleswap.xyz.