// schema · atomic swaps · xmr ↔ btc

Trading XMR for BTC with
no exchange in the middle.

An atomic swap is a peer-to-peer cryptocurrency trade that either completes entirely on both sides or refunds entirely on both sides — never half-done, never custodied. For BTCLTC or any pair of scripting-capable chains, HTLCs solved this years ago. But Monero has no scripting — no conditionals, no hashlocks, nothing. Until 2020 it was widely assumed atomic XMR↔BTC swaps were impossible. They aren't. The solution uses adaptor signatures and a clever asymmetric protocol where the act of claiming one side's coins cryptographically reveals the key to the other side.

adaptor signatures no scripting needed on monero asymmetric refund ~30-90 min typical comit · farcaster · haveno
01 · why this exists

§1The exchange problem

If you hold BTC and want XMR, the easy path is a centralized exchange: send BTC, receive XMR. But Monero has been delisted from most major exchanges since 2023-2024 under regulatory pressure (Binance, Bittrex, OKX, Kraken in the UK/EU, etc.). What remains either requires KYC, is geographically restricted, or is a thin-liquidity instant-swapper that's just a centralized exchange in disguise. Atomic swaps are the only mechanism that lets two parties trade XMR for BTC without trusting anyone.

α

Delisting pressure

Major exchanges have removed XMR. The remaining options are KYC-heavy, regional, or built on the assumption you'll trust the operator with custody. Atomic swaps need no operator.

β

Custody risk

Even when exchanges exist, sending funds to one means temporarily losing self-custody. Mt. Gox, FTX, Cryptopia, QuadrigaCX — the list of "temporarily" lost funds is long.

γ

Privacy at the edge

Even private chains have a privacy boundary at the exchange. Atomic swaps let you cross between chains without ever touching a KYC'd address, preserving the privacy story end-to-end.

02 · the obstacle

§2Why Monero atomic swaps are different

Classical atomic swaps (BTC↔LTC, BTC↔DOGE, etc.) use HTLCs — Hashed Time-Locked Contracts. Both chains must support a scripting language capable of expressing: "if you reveal a preimage to hash H, you can spend; if T seconds pass without that, the original owner can refund." Bitcoin has this. Monero does not. Monero has no scripting language whatsoever — every transaction is a fixed structure of stealth outputs, ring signatures, and range proofs. There is nowhere to put an "if-then" condition.

BITCOIN · script-rich

Has the tools for HTLC

  • OP_HASH160 / OP_EQUAL — can hashlock outputs
  • OP_CHECKLOCKTIMEVERIFY — can enforce absolute timelocks
  • OP_CHECKSEQUENCEVERIFY — relative timelocks
  • 2-of-2 multisig — natively supported via OP_CHECKMULTISIG / MuSig2
  • P2SH / P2WSH / P2TR — wraps scripts into spendable outputs
  • Result — can implement any HTLC condition the protocol needs
MONERO · scriptless by design

No scripting at all

  • No conditional logic — outputs are just stealth keys + commitments
  • No hashlocks — there's nowhere to put a hash check
  • No HTLC mechanism — the chain literally cannot enforce one
  • 2-of-2 multisig exists but is in-protocol cryptographic, not script
  • Unlock time exists but is just a chain-wide spend delay, not conditional
  • Result — anything "conditional" must be done off-chain via cryptography

The 2020 breakthrough

For years it was conventional wisdom that atomic XMR swaps were impossible because Monero lacks scripting. In 2020, Joël Gugger (h4sh3d) published a protocol that solved this by moving all the conditional logic to the Bitcoin side, using adaptor signatures to ensure that when one party spends on Bitcoin, the act of spending itself reveals the secret needed to spend on Monero. Monero doesn't need to enforce anything — Bitcoin enforces both sides.

03 · the primitive

§3What an adaptor signature is

An adaptor signature is the cryptographic primitive that makes scriptless atomic swaps possible. It's a partial signature that's missing a known piece — and that piece is a secret t. Anyone with t can complete the signature into a valid one. Crucially, the relationship runs both ways: if you ever see both the adaptor signature and the completed valid signature on the same chain, you can recover t by subtracting them.

The core property in three equations

σ' = σ + t · G The signer creates an adaptor signature σ' by adding the secret scalar t (encoded as a curve point t·G) to what would be a valid Schnorr signature σ. σ' alone is NOT valid on-chain — it would fail verification.
σ = σ' t · G ← COMPLETE the signature A counterparty who learns t can subtract it from σ' to recover the valid σ, broadcast it, and claim the coins.
t = extract(σ', σ) ← EXTRACT the secret Whoever sees the completed σ on-chain alongside the previously-known σ' can compute t = σ' − σ. This is the property atomic swaps depend on.

An adaptor signature is therefore a two-way trapdoor: knowing t lets you finish the signature; seeing the finished signature lets you recover t. In an atomic swap, t happens to be the spend key needed for the other chain. So spending on one chain cryptographically grants the counterparty the ability to spend on the other.

This is the magic — the key reveal is forced

If Alice claims her BTC by completing the adaptor signature into σ, then σ is now visible to the world on the Bitcoin chain. Bob, who created σ', can compute t = σ' − σ and now possesses the secret needed to unlock his XMR. Alice cannot stop this — it's a property of the math, not a courtesy from Alice.

04 · the protocol

§4The eight-step XMR ↔ BTC dance

The canonical protocol (Gugger 2020, used by COMIT's xmr-btc-swap). Alice wants to buy XMR with her BTC. Bob wants to sell XMR for BTC. The party that moves first by locking funds is the one whose chain has scripting — i.e. Bob locks XMR last, after he's sure Alice has committed her BTC behind enforceable timeouts. Eight steps from start to settlement.

ALICE holds BTC · wants XMR ← message exchange → BOB holds XMR · wants BTC STEP 1 · setup & key exchange exchange public keys, agree on amounts, generate secrets s_A, s_B STEP 2 · pre-sign refund transactions both sign BTC-refund + adaptor-sig structures BEFORE any funds move STEP 3 · LOCK BTC Alice broadcasts BTC-lock tx → 2-of-2 multisig output, timelocked refund Bob watches BTC chain STEP 4 · LOCK XMR Bob broadcasts XMR-lock tx → output owned by joint key S_A + S_B Alice watches XMR chain STEP 5 · Bob sends adaptor signature σ' = adaptor sig on BTC-redeem, encrypted under s_A·G STEP 6 · CLAIM BTC Alice completes σ' using her s_A → broadcasts BTC-redeem with σ Alice gets her BTC, σ is now public! Bob extracts s_A = σ' − σ STEP 7 · Bob extracts s_A from chain s_A = σ' − σ · Bob now has both halves of the XMR spend key STEP 8 · CLAIM XMR Bob combines s_A + s_B = full spend key → spends XMR-lock to his own wallet SWAP COMPLETE

The eight steps, written out

1

Setup

Alice & Bob exchange public keys and agree on amounts. Each generates a secret scalar (s_A, s_B) that will become a half of the eventual XMR spend key.

2

Pre-sign refunds

Both parties cooperatively pre-sign BTC-refund and adaptor signature structures, with appropriate timelocks. Critical: these signatures exist before any funds are committed.

3

Alice locks BTC

Alice broadcasts a BTC-lock transaction. The output is a 2-of-2 multisig of Alice and Bob's keys. Alice can refund after timeout T1; Bob can claim with adaptor sig.

4

Bob locks XMR

Once Bob sees BTC-lock confirmed, he broadcasts XMR-lock. The XMR output is controlled by the joint key (s_A + s_B)·G — neither party alone can spend it.

5

Bob sends σ'

Bob sends Alice an adaptor signature σ' on the BTC-redeem transaction, encrypted under the curve point s_A·G that he learned during setup.

6

Alice claims BTC

Alice (who knows s_A) completes σ' into a valid σ, broadcasts BTC-redeem. She gets her BTC. The completed σ is now on the Bitcoin chain, public.

7

Bob extracts s_A

Bob computes s_A = σ' − σ from the on-chain completed signature. He now possesses Alice's secret scalar.

8

Bob claims XMR

Bob combines s_A + s_B to derive the full XMR spend key, signs and broadcasts XMR-redeem. Swap complete. Both parties have their target asset, no third party involved.

05 · safety

§5What if someone bails?

The whole point of "atomic" is that no honest participant can lose money. The protocol handles four failure modes — and notably, all the timelock logic is on the Bitcoin side. Monero needs no enforcement; the refund mechanism is purely cryptographic.

Failure modeWhenOutcome
Bob never locks XMRAfter step 3, before step 4Alice's BTC-lock has a refund timeout T1. After T1, Alice unilaterally signs BTC-refund and recovers her BTC. Bob never moved.
Bob locks but never sends σ'After step 4, before step 5Alice's BTC-refund timeout still applies. She refunds BTC at T1. Bob's XMR is now locked in a key only the joint pair can spend — at T2 (later than T1), an emergency XMR-refund path leaks Bob's s_B to Alice... but in the canonical protocol, Bob recovers XMR via a different cryptographic refund using s_A revealed by Alice's BTC-refund.
Alice never claims BTCAfter step 5Alice has σ' but never broadcasts. Bob can't extract s_A. After T1, Alice refunds her BTC — and the BTC-refund tx contains Bob's signature that reveals s_B to Alice, who can then unilaterally claim XMR. Bob loses XMR; Alice gets both (this is why Bob must NOT lock XMR until BTC-lock is confirmed).
Network partition / sluggish blocksAny stepThe biggest real risk in practice. If Bitcoin gets congested and a critical refund tx can't confirm before its timelock expires, funds aren't lost but the swap can end in an awkward state requiring patience. Generous timeouts (24-72 hours) prevent this.

The asymmetric timelock structure

The protocol uses two cascading timeouts on Bitcoin: T1 (Alice's refund window — typically ~24h) and T2 > T1 (Bob's "punishment" window — typically ~48h). This asymmetry forces a strict ordering: if Alice tries to be tricky and both claim BTC and refund, the protocol leaks her keys to Bob via the cancellation path. Honesty is enforced by the timeouts, not by trust.

06 · in the wild

§6Implementations you can actually use

The protocol has been implemented several times by independent teams. All are open source. None require trusting an exchange.

xmr-btc-swap (COMIT)

REFERENCE · RUST · 2021–PRESENT

The canonical implementation: comit-network/xmr-btc-swap. Originated from h4sh3d's 2020 protocol paper. Ships a swap CLI for takers and an asb ("Automated Swap Backend") for makers/liquidity providers. The codebase most other tools build on.

UnstoppableSwap

GUI · DESKTOP · USER-FRIENDLY

A graphical wrapper around xmr-btc-swap. Discovers makers automatically, handles wallet integration, and gives a normal-looking trade UI. The most common entry point for non-technical users in 2026.

Farcaster

ALTERNATIVE PROTOCOL · RUST · MODULAR

farcaster-project/farcaster-node. Independent Rust implementation by a separate team. More modular architecture, easier to extend to other coin pairs in principle. Both COMIT and Farcaster swap protocols can interoperate at the chain level — only the off-chain dance differs.

Haveno

DEX · BISQ FORK · MONERO-FIRST

Fork of Bisq rebuilt around Monero. Uses atomic swaps internally for the trustless settlement piece, wrapped in a full peer-to-peer marketplace with fiat on-ramps. Multiple Haveno networks exist (the "official" one + community forks).

eigenwallet

INTEGRATED WALLET · 2025+

Newer wallet that bundles atomic swap functionality directly. Aims to make BTC↔XMR trading as easy as sending a normal transaction. Built on xmr-btc-swap libraries underneath.

Custom CLI workflows

POWER USER · TERMINAL

Both COMIT and Farcaster expose JSON-RPC interfaces. Power users run asb as a persistent maker offering liquidity, or script swap takings programmatically. Spreads are typically 1-3%, swaps complete in 30-90 minutes (Bitcoin confirmations are the bottleneck).

Practical considerations

i

Liquidity is thinner than CEXes

Realistic range: 0.001 to ~5 BTC equivalent. Larger swaps require finding a specific maker willing to provide that depth, or splitting into multiple swaps.

ii

Spreads are 1-3%

Wider than centralized exchanges. The maker is taking on protocol risk, dealing with confirmation times, and providing liquidity from their own funds. Spread compensates for capital lockup.

iii

Both nodes must be running

To preserve the privacy story, you should run both a local bitcoind (or Electrum) and a local monerod. Using third-party RPC endpoints reveals what you're swapping to the operator of those endpoints.

07 · the broader story

§7What this proves

Cross-chain atomic swaps between a scripting-rich chain and a scriptless chain were widely considered impossible until 2020. They turned out to be possible — using cryptography rather than scripts. This has implications well beyond XMR↔BTC.

i

Scriptless chains aren't isolated

Any chain that supports Schnorr-like signatures can participate in adaptor-signature swaps. The XMR↔BTC blueprint generalizes — there are research designs for XMR↔ETH, XMR↔Tari, and arbitrary pairs.

ii

Privacy chains survive delisting

When centralized exchanges delist a privacy coin, atomic swaps preserve the on-ramp/off-ramp. Monero's continued utility despite regulatory pressure is partly because of this.

iii

The future is adaptor signatures everywhere

The same primitive that enables XMR↔BTC swaps also powers the Lightning Network's PTLCs, future Bitcoin sidechain pegs, and a growing class of "scriptless script" protocols. Atomic swaps are an early concrete example of cryptography replacing on-chain logic.

The deeper point

Monero spent a decade being criticized as "isolated" because of its lack of scripting. Adaptor signatures turned that criticism into a non-issue: the very scriptlessness that limited Monero on its own chain turns out to be irrelevant when paired with any chain that has scripting. You only need scripting on one side of an atomic swap. Monero rides on Bitcoin's, Bitcoin rides on its own — and both parties get what they wanted.