Glossary

Atomic Swap

A trustless exchange of cryptocurrencies between two parties where either both transfers complete or neither does.

Key Takeaways

  • Atomic swaps are all-or-nothing cryptocurrency exchanges: two parties trade assets across different blockchains without a trusted intermediary, guaranteed by HTLCs that ensure either both transfers complete or neither does.
  • Timelocks provide the safety net: if one party fails to complete their side of the trade within the deadline, the other party automatically recovers their funds through the refund path.
  • Submarine swaps extend the concept to bridge on-chain Bitcoin and Lightning Network channels, enabling trustless loop-in and loop-out operations for channel liquidity management.

What Is an Atomic Swap?

An atomic swap is a peer-to-peer exchange of cryptocurrencies between two parties that executes without any trusted intermediary. The term "atomic" comes from computer science, where it describes an operation that either completes entirely or has no effect at all. In the context of trading, this means both sides of the swap settle together, or neither side settles. There is no state where one party has sent their coins but the other has not.

Traditional cryptocurrency exchanges require you to deposit funds with a centralized platform that matches orders and settles trades on your behalf. This introduces counterparty risk: the exchange could be hacked, freeze withdrawals, or simply disappear. Atomic swaps eliminate this risk by replacing the trusted intermediary with cryptographic guarantees. The swap is enforced by Bitcoin Script (or equivalent scripting on other chains), not by trust.

The concept was first described by Tier Nolan in 2013 on the Bitcointalk forum, and the first on-chain atomic swap between Bitcoin and Litecoin was executed in 2017. Since then, the technique has been adapted for cross-layer swaps, decentralized exchange protocols, and Lightning Network liquidity management.

How It Works

Atomic swaps rely on a cryptographic primitive called a hash time-locked contract (HTLC). An HTLC locks funds behind two conditions: a hash lock (requiring knowledge of a secret preimage) and a timelock (a deadline after which the funds can be reclaimed). By using the same hash on both sides of the swap, the two transactions become cryptographically linked.

Step-by-Step Process

Consider Alice, who holds Bitcoin and wants Litecoin, and Bob, who holds Litecoin and wants Bitcoin. Here is how they execute an atomic swap:

  1. Alice generates a random secret (the preimage) and computes its hash. She creates an HTLC on the Bitcoin blockchain that locks her BTC. Bob can claim these coins by revealing the preimage before a 24-hour timelock expires. If he does not, Alice reclaims her BTC.
  2. Bob sees Alice's HTLC on-chain and verifies the amount and timelock. He creates a matching HTLC on the Litecoin blockchain using the same hash, locking his LTC. Alice can claim by revealing the preimage before a 12-hour timelock. If she does not, Bob reclaims his LTC.
  3. Alice claims Bob's LTC by revealing the preimage to the Litecoin HTLC. This transaction is published on the Litecoin blockchain, making the preimage visible to everyone.
  4. Bob sees the revealed preimage on the Litecoin chain and uses it to claim Alice's BTC from the Bitcoin HTLC.

The critical insight: Alice's act of claiming the Litecoin necessarily reveals the secret Bob needs to claim the Bitcoin. Neither party can cheat because claiming one side exposes the information required for the other.

Asymmetric Timelocks

Notice that Alice's HTLC has a longer timelock (24 hours) than Bob's (12 hours). This asymmetry is deliberate and essential for safety. Alice, who knows the preimage, must claim first. If both timelocks were equal, Alice could wait until the last moment, claim Bob's LTC, and then let her own HTLC expire before Bob has time to use the revealed preimage. The longer timelock on Alice's side guarantees Bob has sufficient time to react after Alice claims.

The general rule: the party who knows the preimage (the initiator) must have the longer timelock on the contract they created, giving the counterparty adequate time to complete their claim after the preimage is revealed.

HTLC Script Structure

The on-chain HTLC that powers an atomic swap uses a script with two spending paths:

OP_IF
  OP_SHA256 <hash_of_preimage> OP_EQUALVERIFY
  <counterparty_pubkey> OP_CHECKSIG
OP_ELSE
  <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP
  <initiator_pubkey> OP_CHECKSIG
OP_ENDIF

The first branch (the claim path) requires the counterparty to provide both the preimage that hashes to the embedded value and a valid signature. The second branch (the refund path) becomes available only after the timelock expires, allowing the creator to reclaim their funds.

Submarine Swaps

Submarine swaps are a specialized form of atomic swap that bridges on-chain Bitcoin transactions with off-chain Lightning Network payments. The name refers to how one leg of the swap "dives" beneath the blockchain surface into the Lightning layer.

These swaps are particularly important for Lightning channel management. Services like Loop and Boltz use submarine swaps to enable loop-in and loop-out operations:

  • Loop-in (on-chain to Lightning): a user sends an on-chain HTLC to a swap provider, who then sends a Lightning payment to the user's channel. This increases the user's inbound liquidity.
  • Loop-out (Lightning to on-chain): a user sends a Lightning payment to the swap provider, who then sends an on-chain transaction to the user's address. This frees up channel capacity.

The process works similarly to a standard atomic swap. The shared payment hash links the on-chain HTLC to the Lightning HTLC, ensuring atomicity across the two layers. For a deeper exploration of this mechanism, see the submarine swaps deep dive.

Submarine Swap Flow

A typical loop-out submarine swap proceeds as follows:

  1. The user generates a preimage and sends the hash to the swap provider
  2. The swap provider creates an on-chain HTLC locked to that hash, sending BTC to a script the user can claim with the preimage
  3. The user pays a Lightning invoice from the swap provider that uses the same hash
  4. The swap provider settles the Lightning payment by revealing the preimage (or in the reverse direction, the user reveals it on-chain)

The shared hash ensures that claiming one side reveals the secret for the other, maintaining atomicity just like a traditional cross-chain swap.

Use Cases

Cross-Chain Trading

The original and most straightforward use case: exchanging one cryptocurrency for another without a centralized exchange. Atomic swaps enable trustless peer-to-peer trading across any two blockchains that support hash locks and timelocks. This includes Bitcoin, Litecoin, and other UTXO-based chains with compatible scripting capabilities.

Lightning Liquidity Management

Lightning node operators use submarine swaps to rebalance their channels. When a channel's balance becomes skewed (too much on one side), a swap can move funds between on-chain and off-chain without closing and reopening the channel. This is essential for maintaining routing capacity and is the foundation of services like autoloop that automate liquidity management.

Decentralized Exchanges

Atomic swaps underpin several decentralized exchange protocols. Rather than pooling liquidity in a smart contract (as with AMM-based DEXs), swap-based DEXs match traders peer-to-peer and execute trades via atomic swaps. This preserves self-custody throughout the trade: neither party ever gives up control of their keys.

Cross-Layer Bridging

Beyond Lightning submarine swaps, atomic swap techniques are used to move assets between different Layer 2 solutions. The core mechanism (shared hash linking two conditional transfers) generalizes to any system that supports HTLCs or equivalent conditional payment primitives. For context on how different bridging approaches compare, see the Bitcoin Layer 2 comparison.

Risks and Considerations

Chain Compatibility Requirements

Atomic swaps require both blockchains to support the same hash function (typically SHA-256) and timelock mechanisms. Chains without programmable scripts or with limited scripting capabilities cannot participate in traditional HTLC-based swaps. This limits the set of assets that can be swapped atomically, though adaptor signatures and other advanced cryptographic techniques (like those used in PTLCs) are expanding the possibilities.

Timelock Coordination

Both parties must be online and responsive within the timelock windows. If Alice initiates a swap but Bob takes too long to create his matching HTLC, Alice's funds remain locked until her timelock expires. On blockchains with variable confirmation times, estimating safe timelock durations adds complexity. Too short and the swap may fail during network congestion; too long and funds are locked unnecessarily.

On-Chain Costs

Traditional on-chain atomic swaps require at least two transactions per party (one to create the HTLC, one to claim or refund). During periods of high fees, the transaction costs can make small swaps uneconomical. This is one reason submarine swaps (which move one leg to Lightning) and Lightning-to-Lightning swaps have become more popular: they reduce the on-chain footprint.

Privacy Limitations

Standard atomic swaps using the same hash on both chains create a cross-chain linkability problem. Anyone observing both blockchains can correlate the two transactions by matching the hash values, revealing that the same parties are involved. Newer protocols using Schnorr signatures and adaptor signatures can break this link by using different values on each chain while maintaining atomicity.

Free Option Problem

After the initiator creates the first HTLC, the counterparty has a window where they can observe price movements before committing their side. If the exchange rate moves unfavorably, they can simply walk away, leaving the initiator's funds locked until timeout. This "free option" problem is inherent to the two-step setup process and can be mitigated with shorter timelocks, reputation systems, or fidelity bonds.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.