Timechain Wiki

PayJoin

18 min read

PayJoin (Pay-to-Endpoint, formalized as BIP-78 in 2020) is a coordinated two-party transaction in which the recipient contributes one of their own UTXOs to the input set alongside the sender's. The result resembles an ordinary 2-input payment but deliberately scrambles the common-input-ownership heuristic (CIOH) that chain-analysis firms rely on for clustering. Unlike CoinJoin, PayJoin needs no equal-denomination outputs and no multi-party anonymity set; the privacy benefit is systemic — every PayJoin makes CIOH structurally less reliable across the whole transaction graph. Direct privacy gain to any single participant is modest, but cumulative adoption degrades chain-analysis clustering for everyone. Adoption stayed low under the original BIP-78 (2020) design, but BIP-77 (Payjoin v2) — merged in 2025 — re-architects the protocol to be asynchronous and serverless, so neither party need run a server or be online at once, removing the largest historical barrier; Bull Bitcoin shipped the first commercial v2 mobile wallet in 2026.

Why this note matters

PayJoin is the privacy-enhancing transaction pattern most likely to be useful for ordinary commerce — a routine merchant payment that incidentally improves privacy for both parties. The note matters because:

  • It’s the only privacy primitive that piggybacks on ordinary payments rather than requiring separate mixing operations. The privacy benefit accrues during normal economic activity.
  • It addresses the CIOH structural reliability at the network level rather than just for individual holders. Every PayJoin makes CIOH less reliable as a chain-analysis primitive across the whole graph.
  • It pairs naturally with CoinJoin in the holder’s toolkit — different mechanisms, different operational profiles, different threat-model fits. CoinJoin is post-acquisition mixing; PayJoin is in-flow privacy.
  • It is less politically charged than CoinJoin — PayJoin has not (so far) triggered the regulatory enforcement attention that Samourai and Wasabi did, partly because the mechanism is harder to characterize as a mixing service.
  • The adoption barrier is the dominant story: PayJoin’s privacy properties are excellent in theory but underdeveloped in practice because wallet-and-merchant adoption remains a coordination problem.

The defensible position: PayJoin should be enabled wherever a holder’s wallet supports it; the marginal operational cost is essentially zero once configured. The realistic privacy benefit is modest for individual transactions but cumulatively significant as adoption grows.

What PayJoin is

PayJoin is a coordinated transaction between sender and receiver in which both parties contribute inputs. From the on-chain view, the transaction looks like:

Inputs:   [Sender's UTXO]  [Receiver's UTXO]
Outputs:  [Payment to receiver]  [Change back to sender]

The transaction structurally resembles an ordinary 2-input, 2-output payment — the kind of transaction Bitcoin produces millions of times per day. There is no equal-denomination output structure, no special script type, no obvious on-chain marker. Chain-analysis sees an ordinary transaction.

The critical property: CIOH is wrong. The chain-analysis firm presumes the two inputs are co-owned; in reality, they are from two different parties. Every PayJoin transaction the firm cannot identify is a false-positive in their clustering — a transaction where their fundamental heuristic produced a wrong answer.

The mechanism in compressed form:

  1. The receiver provides a payment endpoint (an HTTP URL, typically over Tor) rather than just a static address. The endpoint is encoded in a BIP-21 payment URI alongside the standard address.
  2. The sender constructs a draft transaction as a normal payment — one of their UTXOs, payment to the receiver’s address, change to themselves. They send this draft to the receiver’s endpoint as a PSBT (BIP-174).
  3. The receiver modifies the transaction by adding one of their own UTXOs as an additional input and increasing the payment output to match. The amount the receiver ends up with is the same as the original payment; the additional input plus output makes the receiver’s UTXO effectively “self-pay.”
  4. The receiver signs their own input and returns the modified PSBT to the sender.
  5. The sender re-signs their own input (their original signature is no longer valid because the transaction has changed) and broadcasts.

The result is a transaction that looks like an ordinary payment to anyone observing the chain — but the input set is fundamentally not co-owned, breaking CIOH for chain-analysis purposes.

What PayJoin defeats

CIOH applied to this transaction: the chain-analysis firm presumes the inputs are co-owned. They aren’t. The firm’s clustering rule produces a wrong answer.

Change detection applied to this transaction: the firm presumes one of the outputs is change. The change-detection heuristic may identify the wrong output. Worse, the firm cannot reliably tell which output is the payment and which is the change — both outputs go to parties who are inputs.

CIOH systemic reliability: every PayJoin transaction makes CIOH structurally less reliable. The firm cannot tell which transactions are PayJoins (there’s no on-chain marker) and which are ordinary payments. They must either assume all transactions might be PayJoins (which would destroy their clustering entirely) or accept some false-positive rate. The latter is what they actually do, with the false-positive rate increasing as PayJoin adoption increases.

What PayJoin does not defeat

Address reuse: PayJoin uses a single static address (or freshly-derived address) as the payment destination. If the receiver reuses the address, the chain-analysis firm still has the receiver’s identity attached to that cluster. PayJoin protects the transaction graph, not the address-reuse failure.

Identity-resolution channels: KYC records at exchanges, public address disclosures, and the other channels KYC leakage catalogues are not affected by PayJoin participation.

Endpoint-side network analysis: the PayJoin negotiation requires HTTP communication between sender and receiver. If the receiver’s endpoint is not over Tor and the sender’s connection is observable, network-level analysis could link participants. Most PayJoin implementations use Tor by default for this reason.

Sufficient transaction volume to mask individual transactions: in a network where 99% of transactions are non-PayJoin, the chain-analysis firm can apply CIOH with a 1% error rate. The firm absorbs that error rate; the chain-analysis output is still meaningful. PayJoin’s systemic benefit requires sustained adoption to materially erode CIOH reliability.

Self-fingerprinting through the negotiation pattern: some PayJoin implementations have distinctive wallet-fingerprints (input-selection patterns, fee-estimation algorithms) that could in principle distinguish PayJoin from non-PayJoin transactions. The fingerprints have been studied; they’re modest but not zero.

How PayJoin works in practice

The BIP-78 protocol

BIP-78 (Authored by Nicolas Dorier, 2020) formalized PayJoin with several design properties:

  • HTTP-based negotiation: the sender and receiver communicate via HTTP (typically over Tor) to exchange the PSBT. The endpoint URL is encoded in a BIP-21 payment URI.
  • PSBT format: Partially Signed Bitcoin Transactions (BIP-174) provide the standard way to exchange unsigned and partially-signed transactions between non-trusting parties.
  • Backwards-compatible: a wallet without PayJoin support sees the BIP-21 URI and ignores the PayJoin endpoint, falling back to ordinary payment. The receiver still receives funds via the ordinary mechanism. PayJoin is opt-in for both parties.
  • Forward-compatible: the protocol supports negotiation of various PSBT formats and capabilities, allowing for future privacy enhancements.

The protocol’s design choices reflect a deliberate effort to make PayJoin deployable in the existing ecosystem rather than requiring a hard fork or new transaction type. This explains why the on-chain footprint is indistinguishable from ordinary payments.

The BIP-77 protocol (Payjoin v2 — asynchronous and serverless)

BIP-78’s principal adoption barrier was operational: the receiver had to run an always-on HTTP server (typically a Tor hidden service) and be online at the moment of payment to respond with the Proposal PSBT. BIP-77 (Payjoin v2), merged into the BIP repository in 2025 and now the recommended Payjoin approach, removes that requirement — the two parties no longer need to run a server or be online at the same time.

The mechanism:

  • A Payjoin Directory — an untrusted third-party store-and-forward server — holds small, ephemeral, encrypted payloads and passes them between sender and receiver whenever each next comes online. In lieu of hosting a server, the receiver opens a session with randomly chosen mailboxes on the directory.
  • HPKE end-to-end encryption (Hybrid Public Key Encryption, RFC 9180) means the directory relays only ciphertext — it cannot read or forge the transaction data passing through it.
  • Oblivious HTTP (OHTTP, RFC 9458) hides the sender’s and receiver’s IP metadata from the directory: a relay strips client-identifying headers before the request reaches the directory’s gateway, so the directory learns neither who is transacting nor what they are transacting.
  • Backwards-compatible with v1: the v2 flow is otherwise the same shape as v1, and a BIP-78 sender can post to the directory, which forwards to a BIP-77 receiver.

The practical effect is that PayJoin now works from a mobile device with no self-hosted infrastructure — the costly always-on-server role is outsourced to the untrusted directory without ceding privacy. Bull Bitcoin’s mobile wallet (v0.4.0, 2026) shipped the first commercial end-user send-and-receive implementation, built on the Payjoin Dev Kit (PDK, the shared Rust implementation library) — evidence that the async model is deployable, not merely specified. This directly addresses the receiver-online and self-hosted-server limitations that constrained v1 adoption.

Receiver-side requirements

For a receiver to support PayJoin, they need:

  • An HTTP endpoint (typically Tor hidden service) where senders can negotiate
  • A wallet that supports PayJoin as a receiver
  • UTXOs to contribute: the receiver needs to have UTXOs of appropriate size to add to incoming transactions. (Some implementations dynamically construct the contributed UTXO from existing balances.)
  • Operational tolerance for slight transaction-cost increases: PayJoin transactions have more inputs and outputs than equivalent non-PayJoin transactions, increasing the on-chain fee modestly.

These are the v1 (BIP-78) receiver requirements, and the always-on-server obligation was the main adoption barrier — most merchants are reluctant to run a Tor hidden service. Under BIP-77 (Payjoin v2) the hosted-server requirement disappears: the receiver still needs UTXOs to contribute and a v2-capable wallet, but the store-and-forward Payjoin Directory means no self-hosted endpoint and no requirement to be online at payment time.

BTCPayServer integrates PayJoin support; merchants using BTCPayServer can enable PayJoin with minimal additional configuration. This is the largest single source of PayJoin-capable merchants under the v1 model; the v2 serverless flow lowers the bar further for wallets that implement it.

Sender-side requirements

For a sender to use PayJoin, they need:

  • A wallet that supports PayJoin as a sender: Sparrow, Wasabi, JoinMarket, and several others.
  • The receiver’s BIP-21 URI with PayJoin endpoint: typically encoded in a QR code or copied from a merchant’s payment page.
  • The willingness to wait for the negotiation: a few seconds typically, occasionally longer.

Sender-side adoption is easier than receiver-side because no infrastructure is required — wallet software does the work. As of 2026, the major sovereign-Bitcoin wallets all support PayJoin sending.

When PayJoin makes sense

  • Routine merchant payments: any payment to a PayJoin-supporting merchant should be made via PayJoin if the sender’s wallet supports it. The marginal cost is near-zero; the marginal privacy benefit is real.
  • Larger commercial transactions: the higher the transaction value, the more meaningful the CIOH-misleading effect (both for the individual transaction and for the systemic effect on the chain-analysis firm’s clustering quality).
  • Receiver-side adoption for privacy-respecting businesses: businesses that value privacy as a service for their customers should run PayJoin endpoints. BTCPayServer makes this operationally feasible.

When PayJoin doesn’t make sense

  • No PayJoin endpoint available: most merchants don’t support PayJoin yet. The sender falls back to ordinary payment; no harm done.
  • Tiny payments: the extra on-chain cost from the additional input may exceed the privacy benefit for very small payments.
  • High-frequency micro-payments: Lightning is better-suited (see Lightning privacy properties); PayJoin is for on-chain payments.
  • High-stakes privacy requirements: PayJoin alone is not sufficient for high-stakes privacy. Combine with CoinJoin, Tor, and the broader privacy stack.

PayJoin’s distinctive contribution: systemic privacy

PayJoin’s most interesting privacy property is what it does to chain-analysis at the systemic level rather than what it does for individual transactions.

Consider what happens as PayJoin adoption grows:

  • At 1% adoption: chain-analysis firms apply CIOH with a ~1% false-positive rate. The firm’s clustering is essentially still accurate.
  • At 5-10% adoption: the false-positive rate is meaningful. The firm must invest in trying to identify PayJoin transactions specifically; their clustering accuracy degrades.
  • At 20-30% adoption: CIOH becomes structurally unreliable. The firm must move to weaker heuristics or accept much lower clustering quality.
  • At higher adoption: CIOH-based clustering becomes nearly worthless. The firm’s intelligence value to its customers degrades materially.

This is a public-goods property: the privacy benefit accrues to everyone, including non-PayJoin users, because the chain-analysis firm’s clustering quality affects everyone’s privacy floor.

The contrast with CoinJoin is instructive: CoinJoin provides strong individual privacy (post-mix outputs are clustering-ambiguous) but doesn’t materially affect chain-analysis quality for non-CoinJoin users. PayJoin provides modest individual privacy but degrades chain-analysis quality across the network.

A complete privacy practice uses both: CoinJoin for individual post-acquisition privacy; PayJoin for in-flow privacy and the systemic public-goods contribution.

Why adoption is gated

The systemic privacy benefit creates a coordination problem. An individual merchant gains essentially nothing from running a PayJoin endpoint — the privacy improvement they personally get from each PayJoin transaction is modest. The systemic benefit accrues to the network; the individual costs (infrastructure, fees) accrue to the merchant. This is the classic collective-action structure that limits adoption.

The BTCPayServer integration partially addresses this by reducing the per-merchant cost to near-zero. But mainstream payment processors (Strike, Cash App, exchange-based payment systems) have no privacy-aligned incentive to deploy PayJoin, and their dominance in payment flow limits PayJoin’s reach.

A holder participating in PayJoin from the sender side does not solve the adoption problem but does contribute to demand-signaling that influences future merchant adoption decisions.

Counter-arguments and tensions

”PayJoin’s individual privacy benefit is too small to be worth bothering with”

The argument: A single PayJoin transaction provides modest privacy improvement — it misleads CIOH for that one transaction, but the holder’s broader privacy profile is barely changed. The operational effort to make PayJoin work (compatible wallet, willing merchant, occasional negotiation delays) outweighs the per-transaction benefit.

Response: Substantively true for the individual-privacy lens. PayJoin’s primary value is the systemic public-goods contribution to CIOH reliability erosion, not the individual transaction’s privacy. For a holder evaluating “should I use PayJoin,” the answer is “yes if your wallet supports it, because the marginal cost is near-zero and the network benefit is real” rather than “yes because your individual privacy will materially improve.” The framing matters: PayJoin is not an alternative to address-reuse hygiene or CoinJoin; it’s a complement that contributes to a broader privacy ecology.

”PayJoin adoption will never get high enough for the systemic benefit to materialize”

The argument: The collective-action problem is structural. Without a forcing mechanism (regulation, exchange policy, wallet defaults), PayJoin will remain at single-digit-percent adoption indefinitely. The systemic-privacy argument is theoretical, not practical.

Response: Real concern. The trajectory is uncertain. Two countervailing points: (1) wallet-software defaults are shifting — Sparrow defaults to attempting PayJoin when a compatible URI is detected; future wallets may make PayJoin the default outbound transaction format wherever possible; (2) the privacy-tool ecosystem post-2024 has consolidated around protocols rather than tools (BIP-78, BIP-352, etc.) precisely because protocol-level privacy is harder to suppress regulatorily than tool-operator-based privacy. PayJoin may eventually find adoption via wallet-default mechanisms even without merchant-side initiative. The systemic-privacy argument is contingent on the trajectory; it is not guaranteed.

”PayJoin is a chain-analysis-firm gift because it teaches them what to look for”

The argument: A holder who PayJoins teaches the chain-analysis firm what PayJoin transactions look like; the firm develops detection heuristics; the systemic benefit erodes as detection improves.

Response: Partially true. PayJoin has subtle wallet-fingerprint signals that could in principle distinguish PayJoin from ordinary transactions; researchers have analyzed these and the signals are modest. The honest assessment: PayJoin’s CIOH-misleading property is robust against false-positive rate degradation but not perfectly indistinguishable; the firm’s marginal investment in PayJoin detection could improve their accuracy modestly. The systemic-privacy argument remains net positive as long as detection costs grow faster than detection accuracy, which is the current trajectory.

”PayJoin’s protocol design has weaknesses”

The argument: BIP-78 specifically uses HTTP for negotiation; the protocol requires the receiver to be online; the negotiation pattern can in principle be fingerprinted. Newer designs could improve on these.

Response: True of v1 — and the principal limitation has since been fixed. BIP-78 was designed in 2020 within the constraints of “deployable in the existing wallet ecosystem,” and its always-on-receiver requirement was the biggest of its known limitations. BIP-77 (Payjoin v2) directly resolves it: the store-and-forward Payjoin Directory removes the receiver-online and self-hosted-server requirements, HPKE encryption keeps the directory blind to payload contents, and Oblivious HTTP keeps it blind to IP metadata (see the BIP-77 protocol section above). BIP-77 is merged and is now the recommended Payjoin approach; Bull Bitcoin’s 2026 mobile wallet is the first commercial end-to-end deployment. The residual concern — negotiation-pattern and wallet fingerprinting — is a live research topic (Optech has flagged payjoin fingerprinting risks) but is common to both versions and modest. The defensible position: Payjoin v2 is the deployable standard today and it closes the design gap this objection named.

”PayJoin uses Tor and that’s a flag too”

The argument: Receivers who run PayJoin Tor endpoints can be identified via their hidden-service operation; the Tor connection itself is a network-level signal that the merchant cares about privacy. This makes PayJoin merchants identifiable to surveillance even if the individual transactions are private.

Response: Real concern. Running a Tor hidden service is a privacy-aware operational decision that itself signals privacy-orientation. For most merchants the signal is unimportant; for some merchants (those operating in regulatorily-hostile environments) it could be a real concern. The protocol does not strictly require Tor; receivers could run clearnet endpoints; but Tor is the default for the network-level privacy reasons (otherwise the sender’s IP would be visible to the receiver during the negotiation). The trade-off is real but the magnitude is generally small.

Open questions for further development

  • The BTCPayServer integration is the largest current PayJoin-merchant base. How does adoption track across the broader merchant population, and which payment-processor integrations are most likely to expand the receiver-side population?
  • Wallet-default behaviour for PayJoin is the most practical adoption lever. Which wallets currently default to PayJoin when available, and which still require explicit opt-in?
  • The Samourai/Wasabi 2024 enforcement-environment did not directly affect PayJoin, but the chilling effect on adjacent privacy tooling is real. PayJoin development is in fact advancing (BIP-77 merged; Payjoin Dev Kit; first commercial v2 wallet in 2026) — the open question is whether the async-serverless model finally breaks the historical adoption ceiling.
  • BIP-77 (Payjoin v2) is now the recommended standard; the remaining variable is wallet adoption. Which sending and receiving wallets ship v2 beyond Bull Bitcoin, and does the store-and-forward directory model create any new centralization or censorship surface worth tracking?
  • Empirical measurement of PayJoin adoption is difficult by design (PayJoin transactions look like ordinary transactions). What measurement approaches are available, and what do they suggest about current adoption levels?

Canonical sources for this note

Foundational:

  • Dorier, Nicolas — BIP-78 specification (2020) — the formalized PayJoin v1 protocol
  • BIP-77 (Payjoin v2) — the asynchronous, serverless successor (merged 2025; the recommended approach); async coordination via an untrusted Payjoin Directory with HPKE (RFC 9180) payload encryption and Oblivious HTTP (RFC 9458) metadata protection
  • Payjoin Dev Kit (PDK) — the shared Rust implementation library behind the v2 wallets
  • BTCPayServer documentation — PayJoin integration walkthrough
  • Sparrow Wallet documentation — sender-side PayJoin operation

Adjacent privacy protocols:

  • BIP-174 (PSBT) — the underlying partially-signed transaction format
  • BIP-21 (Bitcoin payment URIs) — the URI format that carries PayJoin endpoints

Academic and practitioner analysis:

  • 6102bitcoin’s Bitcoin Privacy Guide — operational PayJoin walkthrough
  • Privacy-research community analyses of PayJoin’s CIOH-degradation properties
  • Wasabi Wallet documentation on PayJoin integration
  • JoinMarket documentation — PayJoin and CoinJoin comparison

Practitioner and developer:

  • Wasabi GitHub repositories — PayJoin implementation discussions
  • BTCPayServer GitHub — merchant-side implementation
  • Discussions on the Bitcoin Privacy Twitter / Nostr / mailing list

LegacyCipher synthesis (April 2026) — operationalizes PayJoin alongside CoinJoin in the Self-custody privacy stack.

As of 2026-07-17: PayJoin remains a mature protocol with under-developed adoption, but the picture shifted with BIP-77 (Payjoin v2) — merged, now the recommended approach, and re-architected to be asynchronous and serverless (untrusted Payjoin Directory + HPKE + Oblivious HTTP), which removes the always-on-receiver barrier that gated v1. Bull Bitcoin’s mobile wallet (v0.4.0, 2026) is the first commercial end-to-end v2 deployment via the Payjoin Dev Kit. The technical capability is solid and improving; wallet adoption is now the main limiting factor. (BIP-77 / v2 facts web-verified 2026-07-17 against payjoin.org, bips.dev, Bitcoin Optech, and the Bull Bitcoin release.)

Companion Privacy practice notes:

The threat-modeling framework:

Operational practice:

Custody configurations:

  • Multisig setups — PayJoin operates with multisig as long as both parties’ wallets support the negotiation

Adjacent thinker pages:

  • Greg Maxwell — Bitcoin privacy thinker; relevant to the broader privacy-protocol design tradition

The sub-MOC home:

Graph View

Backlinks