PayJoin
A collaborative transaction (a.k.a. P2EP) where sender and receiver both add inputs, obscuring usual input-output analysis.
PayJoin (also called Pay-to-Endpoint, P2EP) is a privacy-enhancing transaction format where both the sender and the receiver contribute inputs. The result is an on-chain payment that defeats one of the strongest chain-analysis heuristics: "all inputs to a transaction share an owner."
A normal payment: sender contributes inputs, receiver contributes nothing. Chain analysts assume all inputs to the transaction belong to one wallet, and use that to cluster addresses.
A PayJoin: sender contributes their inputs, and the receiver adds at least one of their own inputs before signing. The transaction now has inputs from two different wallets. The common-input heuristic breaks - any analyst that applies it is going to merge two unrelated wallets into one false cluster.
Practical wins:
- For the sender: the analyst's assumption that all inputs to your transaction are yours becomes wrong. Past clustering analyses get polluted.
- For the receiver: the amount they were paid is hidden, because their output also carries the value of the coin they added.
- The receiver also gets some consolidation opportunistically - they spend an old UTXO at the same time they're being paid.
The catch is coordination: both wallets need to talk before broadcast. Standards like BIP-78 define an HTTP-based PayJoin protocol where the receiver runs an endpoint. A second version, BIP-77 (async PayJoin, merged in 2025), passes the messages through an untrusted store-and-forward server called a directory, reached over Oblivious HTTP so the directory cannot tie either side to an IP address. The receiver no longer needs to run a server or be online at the moment of payment.
PayJoin is unlike CoinJoin in scale and intent. CoinJoin is many-party batch mixing for after-the-fact privacy. PayJoin is two-party regular-payment privacy. Both are useful; PayJoin is much harder to censor or coordinate against because a well-built PayJoin looks like a normal payment.
See Privacy on Bitcoin for where PayJoin fits among the tools that look like ordinary use.
Key takeaways
- Both sides contribute inputs to a single transaction
- Breaks simplistic chain analysis assumptions
- Requires special wallet support but can happen on-the-fly
Related chapters
Corrected
-
Was: The entry said async PayJoin (BIP 77) runs over Nostr or similar relays, and that both sender and receiver consolidate coins.
Now: BIP 77 passes messages through an untrusted directory server reached over Oblivious HTTP, and only the receiver consolidates. The receiver's main benefit is that the amount paid is hidden. Details
Sources (4)
External references (3)
Related terms (6)
Published . Revised . One correction logged for this page.
Edit this page on GitHub