PayJoin

What Is PayJoin?

PayJoin (also called Pay-to-Endpoint or P2EP) is a Bitcoin privacy protocol where both the sender and receiver contribute inputs to a single transaction. In a standard Bitcoin payment, only the sender provides inputs: they fund the transaction, send the payment, and receive change. In a PayJoin, the receiver also adds one or more of their own UTXOs as inputs, while the transaction still achieves the same net payment.

This simple modification breaks the foundational assumption used by blockchain surveillance firms: the common-input-ownership heuristic (CIOH). This heuristic assumes that all inputs in a transaction belong to the same entity. By mixing sender and receiver inputs in a single transaction, PayJoin makes this assumption unreliable, not just for PayJoin users but for every Bitcoin user on the network.

The concept originated from a Blockstream privacy workshop in 2018. Ryan Havar proposed Bustapay (BIP 79) in August 2018, and Nicolas Dorier subsequently authored BIP-78, which became the primary PayJoin specification. BTCPay Server shipped the first production implementation in April 2020.

How It Works

To understand why PayJoin is effective, consider how a normal Bitcoin transaction looks on chain. Alice wants to pay Bob 1 BTC. Alice has a 1.5 BTC UTXO. She creates a transaction with one input (1.5 BTC) and two outputs (1 BTC to Bob, 0.5 BTC back to herself as change). Any observer can reasonably guess that 1 BTC is the payment amount.

In a PayJoin, Bob also contributes an input. Suppose Bob adds a 0.5 BTC UTXO. The transaction now has two inputs (1.5 + 0.5 = 2 BTC) and two outputs (1.5 BTC to Bob, 0.5 BTC to Alice). On chain, it appears that 1.5 BTC was sent to Bob, but the actual payment was only 1 BTC. The amount on the public ledger is technically real but economically misleading.

BIP-78 Protocol Flow

BIP-78, authored by Nicolas Dorier, defines the synchronous PayJoin protocol. It uses BIP-174 PSBTs as the data format for coordination between sender and receiver:

1. The receiver presents a BIP 21 URI containing a standard Bitcoin address and a pj= parameter pointing to their PayJoin endpoint (an HTTPS or Tor .onion URL)
2. The sender constructs a fully signed, finalized PSBT (the "Original PSBT") and sends it via HTTP POST to the receiver's endpoint. This PSBT is broadcastable as a fallback if PayJoin coordination fails
3. The receiver validates the Original PSBT, adds their own signed inputs, optionally adjusts outputs, and returns a "Payjoin Proposal PSBT" in the HTTP response
4. The sender validates the proposal (verifying all original inputs are preserved, fees are equal or higher, and no unauthorized modifications were made), re-signs only their own inputs, and broadcasts the final transaction

# BIP 21 URI with PayJoin endpoint
bitcoin:bc1qexample...?amount=0.01&pj=https://merchant.com/pj

# Sender creates Original PSBT and POSTs to the pj endpoint
# Content-Type: text/plain (base64-encoded PSBT)

# Receiver responds with Payjoin Proposal PSBT
# HTTP 200, base64-encoded modified PSBT

# Sender validates, re-signs their inputs, and broadcasts

If the receiver's endpoint is unreachable or returns an error, the sender simply broadcasts the Original PSBT as a normal transaction. This graceful fallback means PayJoin never prevents a payment from completing.

BIP-77: Serverless PayJoin

BIP-78 requires the receiver to run an always-online HTTPS server or Tor hidden service, limiting adoption to merchants with infrastructure. BIP-77 (authored by Dan Gould and Yuval Kogman) solves this by introducing an asynchronous, serverless architecture.

Instead of direct HTTP communication, BIP-77 uses an untrusted relay called a "Payjoin Directory." Neither sender nor receiver needs to be online simultaneously:

1. The receiver generates ephemeral encryption keys and creates a Bitcoin URI with a mailbox URL and session metadata
2. The sender encrypts the Original PSBT using the receiver's public key (via HPKE with ChaCha20-Poly1305) and posts it to the directory mailbox through Oblivious HTTP (OHTTP), which strips identifying information like IP addresses
3. The receiver polls the mailbox when convenient, decrypts the PSBT, constructs the proposal, and posts the encrypted response
4. The sender retrieves the proposal, validates it, signs, and broadcasts

All messages are padded to uniform sizes to prevent traffic analysis. The directory relay cannot read message contents or correlate senders with receivers. BIP-77 was merged into the Bitcoin BIPs repository in June 2025, and wallets including Bull Bitcoin and Cake Wallet have shipped production implementations.

Breaking the Common-Input-Ownership Heuristic

The common-input-ownership heuristic is the single most important assumption in blockchain analysis. It states that if a transaction has multiple inputs, all those inputs are controlled by the same entity. Chain surveillance firms use this heuristic to cluster addresses, trace fund flows, and build transaction graphs across the entire Bitcoin network.

PayJoin directly violates this assumption. In a PayJoin transaction, the inputs come from two different entities (sender and receiver), but on chain the transaction is indistinguishable from one where a single entity consolidates their own UTXOs. An analyst cannot determine which inputs belong to the sender and which belong to the receiver.

The network-wide impact is significant: even if only a small percentage of transactions use PayJoin, the CIOH becomes unreliable for all multi-input transactions. Any transaction with multiple inputs could be a PayJoin, creating plausible deniability for every Bitcoin user. This is fundamentally different from CoinJoin, where the distinctive equal-output pattern makes mixing transactions identifiable. For a deeper analysis, see PayJoin: Bitcoin Privacy.

The Steganographic Property

PayJoin's most powerful characteristic is that it is steganographic: PayJoin transactions are completely indistinguishable from normal Bitcoin transactions on the blockchain. There is no cryptographic marker, no special script, no metadata, and no distinctive output pattern that identifies a PayJoin.

A standard two-input, two-output transaction could be a normal payment with change, or it could be a PayJoin. Even with full blockchain data, an observer cannot retroactively identify which transactions used PayJoin. This contrasts sharply with CoinJoin transactions, which produce easily identifiable patterns of equal-denomination outputs and have attracted regulatory scrutiny at some exchanges.

The steganographic property also means PayJoin transactions carry no additional virtual byte overhead compared to normal transactions. The receiver's added input replaces what would otherwise be a separate consolidation transaction, making PayJoin potentially more block-space efficient than transacting without it.

PayJoin vs CoinJoin

While both protocols enhance Bitcoin privacy, they work through fundamentally different mechanisms. Understanding the distinction helps users choose the right tool for their privacy needs and practice effective coin control:

PayJoin and CoinJoin are complementary rather than competing tools. CoinJoin provides strong anonymity sets within a mixing round, while PayJoin provides steganographic privacy that benefits the broader network. Users seeking maximum privacy can combine both techniques with careful coin control.

Use Cases

Merchant Payments

The most natural use case for PayJoin is merchant payments. When a customer pays a merchant who supports PayJoin (via BTCPay Server, for example), the merchant automatically contributes one of their own UTXOs. The customer gets privacy by breaking the CIOH, and the merchant consolidates UTXOs without paying for a separate transaction. Both parties benefit from a single on-chain interaction.

UTXO Consolidation

Receivers can use PayJoin to consolidate small UTXOs during incoming payments rather than batching a separate consolidation transaction. This saves on transaction fees while simultaneously improving privacy.

Transaction Cut-Through

A recent capability enabled by the PayJoin Dev Kit (PDK) allows transaction cut-through: the receiver can use an incoming PayJoin to simultaneously receive a payment and make their own payment to a third party in the same transaction. This concept, first described by Greg Maxwell in 2013, eliminates an entire on-chain transaction and can save up to 16% on fees compared to making separate transactions.

Privacy-Preserving Deposits

When depositing to exchanges or services, PayJoin prevents the recipient from learning which UTXOs the sender controls. Without PayJoin, the exchange can see every input and potentially link them to the sender's other addresses. With PayJoin, the exchange's own input contaminates the clustering analysis. Users practicing self-custody can maintain better operational security when interacting with custodial services.

Current Implementations

PayJoin support has grown steadily since BTCPay Server's initial deployment in 2020. Key implementations include:

• BTCPay Server: production BIP-78 support for both sending and receiving, deployed since April 2020
• Sparrow Wallet and Wasabi Wallet: desktop wallets with BIP-78 send support
• Bull Bitcoin Wallet: the first mobile wallet to ship BIP-77 (send and receive)
• Cake Wallet: added BIP-77 support in v4.28 (May 2025), becoming a major mobile implementation
• Payjoin Dev Kit (PDK): a Rust SDK (rust-payjoin) supporting both BIP-78 and BIP-77, maintained by the Payjoin Foundation and approaching a stable 1.0 release

The Payjoin Foundation, which received 501(c)(3) nonprofit status in 2026, coordinates development with funding from OpenSats, Cake Wallet, and other supporters. Active integrations with Liana wallet and Boltz exchange are underway.

Risks and Considerations

Adoption Requirements

PayJoin requires active participation from both sender and receiver wallets. Unlike silent payments, which only require sender support, PayJoin's privacy benefits depend on the receiver also running compatible software. BIP-77's serverless design significantly lowers the barrier for receivers, but wallet support remains limited compared to standard Bitcoin transactions.

Wallet Fingerprinting

A March 2026 analysis from the Payjoin Foundation documented how wallet construction patterns (signature grinding, sighash policies, nSequence values, fee rate distributions) can potentially re-identify input ownership even in PayJoin transactions. If the sender's wallet constructs inputs differently from the receiver's wallet, an observer may be able to distinguish them. Mitigations are being developed, but this remains an active area of research.

Receiver UTXO Exposure

The receiver contributes their own UTXOs to the transaction, which means the sender can see those UTXOs before the transaction is broadcast. A malicious sender could initiate PayJoin negotiations with no intention of completing, purely to probe the receiver's UTXO set. BIP-78 addresses this by requiring the receiver to track inputs across sessions and reject duplicates to detect probing attacks.

Complexity and Fallback Behavior

PayJoin adds coordination complexity compared to standard Bitcoin transactions. Network failures, endpoint downtime, or protocol mismatches can cause the PayJoin negotiation to fail. However, the protocol is designed with graceful degradation: if PayJoin fails at any step, the sender can always broadcast the Original PSBT as a normal transaction. The payment itself is never at risk.

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.