For education only. Verify both chains, contracts, timeouts, fees and refund paths independently; principal can remain locked or lose value even when the protocol preserves conditional atomicity.
Direct answer
An atomic swap is an asynchronous protocol for exchanging assets without giving one custodian control of both legs. In the classic hashed timelock contract (HTLC) design, one preimage authorizes both claims and unequal deadlines preserve later refund paths. Atomicity is conditional: an honest party should not lose principal to the other party merely because the exchange aborts. It does not mean simultaneous confirmation, automatic or cost-free refunds, a fair market price, continuous liquidity or anonymity.
Each deployment must bind the chain or network, asset and contract, raw amount and decimals, recipient and refund keys, hash construction, exact preimage bytes, script or bytecode and timelock semantics. Two systems that both expose a hash and a clock are not automatically compatible. Bitcoin absolute and relative locks, EVM timestamps and another chain’s finality can have materially different rules.
Classic HTLC swaps also give the party that acts last some price optionality: it can delay while deciding whether execution is still favorable. Adaptor-signature and other scriptless protocols alter the on-chain footprint and assumptions, but they do not remove the need to audit identities, clocks, fees, liveness and recovery.
How it works
- Freeze both networks, assets, amounts, exchange rate, keys, hash and preimage encoding, contract or script bytes, clock units, fee payer and confirmation or finality policies.
- Generate a high-entropy, single-use secret
x, computeh = H(x)offline and have both implementations reproduce the digest from the same raw bytes. - The initiator funds the longer-timeout leg. The participant verifies its chain, asset, amount, keys, hash, code and deadline, then waits for the agreed safety depth.
- The participant funds the shorter-timeout leg. The initiator repeats the same checks and waits for its required confirmations or finality.
- Before an earlier operational cutoff, the initiator claims the short leg with
x, exposing the exact preimage in canonical transaction data. - The participant observes that claim, checks
H(x) = hand claims the long leg with enough time for construction, broadcast, fee recovery and finality. - If any gate fails, stop adding exposure. After each applicable timelock matures, actively construct or broadcast the corresponding refund and reconcile principal, fees, locked duration and chain evidence.
The essential budget is T_long - T_short >= observation + construction + broadcast + confirmation/finality + reorg/operations buffer. Nominal values such as 48 and 24 hours are examples, not universal safe parameters. A timelock merely enables a refund branch; it does not broadcast the refund or pay its fee.
Example
- Hash bytes. For teaching only, UTF-8
abcis raw bytes0x616263;SHA-256(0x616263) = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Hashing the displayed text0x616263instead produces a different digest. Production secrets need cryptographic entropy and must not be reused. - Timeout budget. Let the long refund mature at
48.0 hand the short refund at24.0 h. If the short claim is submitted at22.0 h, observation takes0.5 h, construction and broadcast0.5 h, and long-chain confirmation1.5 h, expected completion is24.5 h. The modeled remaining long-leg margin is48.0 - 24.5 = 23.5 h; it is not a block-production guarantee. - Price optionality. At agreement,
1 BTCat$60,000equals20 ETHat$3,000. At redemption, BTC is$63,000and ETH is$2,800; Alice delivers$63,000and receives20 x $2,800 = $56,000, a-$7,000difference to the then-current market before fees. Protocol atomicity does not lock economic value. - Abort ledger. Alice pays
0.00020 BTCto fund and0.00025 BTCto refund, totaling0.00045 BTC, or$27at$60,000/BTC. Bob pays0.006 ETHto fund and0.004 ETHto refund, totaling0.010 ETH, or$30at$3,000/ETH. Principal returns later, but the combined nonrefundable network cost is$57plus opportunity cost.
Risks
- Wrong chain or network domain.
- Wrong native asset, token contract or decimals.
- Wrong amount, claim key or refund key.
- Incompatible hash algorithm or byte encoding.
- Low-entropy, reused or prematurely exposed secret.
- Defective claim branch, script or bytecode.
- Invalid, unavailable or unsigned refund path.
- Reversed timeout order or inadequate buffer.
- Misread height, median-time, timestamp or relative-lock semantics.
- Short-leg claim and refund race near expiry.
- Reorganization removes funding, reveal or claim.
- Insufficient confirmation or finality policy.
- Fee spike, mempool eviction, censorship or unavailable fee bump.
- Monitoring, RPC, indexer, wallet or key failure.
- Counterparty delay, griefing and locked-capital optionality.
- Exchange-rate, basis and executable-liquidity movement.
- EVM call, reentrancy, gas, proxy or upgrade defect.
- Wrapped or token issuer, bridge, hook, rebase or transfer-fee behavior.
- Cross-chain linkage from reused hash, amount and timing.
- Tax, sanctions, legal, recordkeeping and disaster-recovery failure.
Common misconceptions
- Atomic means simultaneous. The two chains progress independently through an ordered, asynchronous state machine.
- An abort refunds everything automatically. A party normally must wait, transact and pay a fee; monitoring or fee failure can prolong the lock.
- Any two chains with hashes and timelocks interoperate. Algorithms, encodings, clocks, scripts, contracts and finality must actually match.
- Non-custodial means no counterparty or price risk. Griefing, optionality, volatility and operational dependence remain.
- Atomic swaps provide liquidity and privacy. They coordinate settlement conditions; they do not create quotes, depth, counterparties or unlinkable activity.
Related topics
Sources
- Atomic Cross-Chain Swaps - Association for Computing Machinery (accessed: 2026-08-13)
- On the optionality and fairness of Atomic Swaps - Association for Computing Machinery (accessed: 2026-08-13)
- BIP 65: OP_CHECKLOCKTIMEVERIFY - Bitcoin Improvement Proposals (accessed: 2026-08-13)
- BIP 112: CHECKSEQUENCEVERIFY - Bitcoin Improvement Proposals (accessed: 2026-08-13)
- Contracts - Bitcoin Developer Documentation (accessed: 2026-08-13)
- Transactions - Bitcoin Developer Documentation (accessed: 2026-08-13)
- Atomic Swaps - Decred Documentation (accessed: 2026-08-13)
- Proof-of-stake (PoS) - Ethereum.org (accessed: 2026-08-13)