Glossary

CoinSwap

A privacy protocol where two parties exchange Bitcoin outputs without a visible on-chain link, making transaction tracing much harder.

Key Takeaways

  • CoinSwap is a Bitcoin privacy protocol where two parties atomically exchange UTXOs through separate, unlinked transactions that appear as ordinary payments on-chain, unlike CoinJoin which combines inputs into a single detectable transaction.
  • The protocol uses cryptographic primitives such as HTLCs or adaptor signatures to guarantee atomicity: either both sides of the swap complete or neither does, with no trust required.
  • CoinSwap offers the strongest on-chain unlinkability among Bitcoin privacy techniques, but trades off higher on-chain fees and multi-transaction overhead for that privacy gain.

What Is CoinSwap?

CoinSwap is a privacy protocol for Bitcoin that allows two parties to exchange ownership of their coins through separate, independent transactions. Proposed by Greg Maxwell in 2013, the core idea is simple: if Alice and Bob each send Bitcoin to the other in separate transactions, a blockchain observer sees two unrelated payments rather than a single mixing transaction. This breaks the on-chain link between a user's old coins and new coins.

Unlike CoinJoin, which merges multiple users' inputs into one large transaction with equal-sized outputs, CoinSwap transactions look identical to ordinary single-party payments. There is no special transaction structure for chain analysis firms to flag. The swap participants simply appear to be sending normal payments to unrelated addresses.

The protocol remained largely theoretical for years due to implementation complexity. In 2020, Bitcoin developer Chris Belcher published a detailed design document and began building Teleport Transactions, bringing CoinSwap closer to practical use.

How It Works

A basic CoinSwap involves two parties who want to break the transaction graph linking their coins. The process uses a combination of multisig escrow addresses and cryptographic locks to ensure atomicity.

  1. Alice and Bob each create a 2-of-2 multisig address requiring both parties' signatures to spend
  2. Alice sends her coins to the Alice-Bob multisig address (funding transaction 1)
  3. Bob sends his coins to a separate Alice-Bob multisig address (funding transaction 2)
  4. Both parties pre-sign refund transactions with timelocks as a safety mechanism
  5. Using a shared hash lock, the parties atomically reveal the information needed to spend from each other's multisig
  6. Alice claims Bob's coins and Bob claims Alice's coins in separate spending transactions

The result is four transactions total: two funding transactions and two spending transactions. On-chain, these appear as unrelated payments. An observer sees Alice send coins to one address and later receive coins from a completely different address, with no visible connection between the two events.

Private Key Handover

An optimization called private key handover can reduce the number of on-chain transactions. Instead of both parties creating spending transactions from the multisig, they exchange the private keys directly after the atomic swap completes. This allows each party to spend from the other's multisig at any time without additional on-chain activity, reducing fees and improving privacy by leaving fewer footprints.

Adaptor Signatures vs. HTLCs

CoinSwap can use two different cryptographic mechanisms for atomicity:

  • Hash time-locked contracts (HTLCs): the traditional approach where a shared hash preimage links the swap. The drawback is that if the same hash appears in multiple transactions, an observer can correlate them
  • Adaptor signatures (PTLCs): the preferred approach where each hop uses a different signature tweak, preventing correlation across transactions. This leverages scriptless scripts to hide the swap mechanism entirely within standard-looking signatures

Belcher's design originally used ECDSA-2P (two-party ECDSA) to make the 2-of-2 multisig addresses indistinguishable from regular single-signature addresses. This maximizes the anonymity set because the swap addresses blend in with every existing pay-to-witness-public-key address on the network. More recent implementations also support Taproot with MuSIG2 for the same effect using the key-path spend.

Multi-Hop Routing

For stronger privacy, CoinSwap supports multi-hop routing similar to onion routing. Instead of swapping directly with one counterparty, Alice routes through multiple intermediate makers:

Alice → Maker1 → Maker2 → Maker3 → Alice (new coins)

# Each hop is an independent CoinSwap
# Only Alice knows the full route
# Each maker knows only the previous and next hop

This means that even if one maker is compromised or cooperates with an analyst, they cannot determine the origin or destination of the coins. A minimum of three or more colluding makers would be needed to deanonymize a swap, and fidelity bonds make such attacks economically prohibitive.

CoinSwap vs. Other Privacy Techniques

Bitcoin offers several privacy techniques, each with different tradeoffs. Understanding how CoinSwap compares helps users choose the right tool for their needs.

PropertyCoinSwapCoinJoinPayJoinSilent Payments
On-chain visibilityLooks like ordinary paymentsDetectable equal-output patternLooks like a normal paymentStandard transaction
Number of transactionsMultiple (2-4+)Single transactionSingle transactionSingle transaction
Participants2+ (multi-hop)Multiple (coordinated)2 (sender + receiver)2 (sender + receiver)
Privacy typeBreaks transaction graphObscures output ownershipBreaks common-input heuristicPrevents address reuse
Fee overheadHigh (multiple txs)Moderate (shared tx)LowNone

For a deeper analysis of Bitcoin privacy approaches, see the research article on the Bitcoin privacy landscape and transaction graph privacy defenses.

Teleport Transactions and Current Implementations

Chris Belcher began building Teleport Transactions (originally called Teleport CoinSwap) in 2020, with the goal of making CoinSwap practical for everyday Bitcoin users. The project uses a maker/taker model inspired by JoinMarket's CoinJoin implementation:

  • Takers initiate swaps, choose the route, and pay fees to makers
  • Makers run always-on nodes that advertise liquidity and earn fees for participating in swaps
  • Makers advertise via Tor hidden services to preserve network-level privacy
  • Fidelity bonds (time-locked Bitcoin) prevent Sybil attacks by making it expensive to operate many fake maker nodes

Active development continues under the Citadel-Tech organization on GitHub, with OpenSats funding. As of 2026, the implementation includes CLI tools (makerd and taker), a GUI application, fidelity bond support, and Taproot with MuSIG2 contract types. The software supports testnet4 and includes integration testing, though mainnet use is not yet recommended for production funds.

Use Cases

The primary use case is improving fungibility by breaking the on-chain transaction graph. When coins pass through a CoinSwap, their history is effectively severed. This is valuable for users who want to prevent merchants, employers, or other parties from tracing their financial history through chain analysis.

High-Value Privacy

Because CoinSwap provides stronger unlinkability than CoinJoin, it is particularly suited for situations where privacy is critical. The multi-hop routing ensures that no single counterparty can connect the user's old and new coins, even under coercion.

Improving Network-Wide Privacy

CoinSwap has a unique property: it improves privacy for all Bitcoin users, not just swap participants. Because CoinSwap transactions look like ordinary payments, an analyst can never be certain that any given transaction is not a CoinSwap. This creates doubt about the reliability of transaction graph analysis across the entire network.

Risks and Considerations

Higher On-Chain Fees

A single CoinSwap requires multiple on-chain transactions (typically four for a basic swap, more with multi-hop routing). During periods of high fee market activity, these costs can be significant. CoinJoin, by contrast, batches participants into a single transaction, sharing the fee burden.

Amount Correlation

If Alice swaps exactly 1.5 BTC and receives exactly 1.5 BTC (minus fees) shortly after, an analyst may correlate the amounts. CoinSwap implementations mitigate this by splitting outputs across multiple transactions: for example, returning 1.5 BTC as three separate UTXOs of varying sizes at different times.

Sybil Attack Risk

An adversary could run many maker nodes to increase the chance of controlling all hops in a multi-hop swap. If the adversary controls every maker in the route, they can link the taker's old and new coins. Fidelity bonds address this: makers must lock Bitcoin in time-locked outputs to prove economic commitment, making large-scale Sybil attacks prohibitively expensive.

Liveness Requirements

Both parties must remain online during the swap process. If a maker goes offline mid-swap, the taker must wait for the timelock to expire before recovering their funds. This can take hours or days depending on the configured timelock values, creating a poor user experience compared to instant CoinJoin rounds.

Maturity and Adoption

CoinSwap implementations are still in active development and not yet recommended for mainnet use with significant funds. Users interested in Bitcoin privacy today may prefer more mature solutions like PayJoin or Silent Payments while CoinSwap tooling continues to mature. For background on these alternatives, see the research on PayJoin and Silent Payments.

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.