ShopPayJoin is a two-party bitcoin transaction in which both the sender and the receiver contribute inputs. This structure defeats two blockchain analysis heuristics simultaneously, and the resulting transaction is indistinguishable from a standard multi-input payment on-chain.
PayJoin is a complement to CoinJoin, not a replacement: What is CoinJoin? breaks historical UTXO links through mixing, while PayJoin prevents traceability at the moment of payment without a coordinator or third party.
What is PayJoin?
In a normal Bitcoin payment, the sender initiates the transaction by selecting one or more of their own UTXOs as inputs. The transaction typically produces two outputs: a payment output sending the specified amount to the recipient's address, and a change output returning the remainder to an address the sender controls.
This structure is so consistent that chain analysis firms treat it as an axiom. By applying the common-input-ownership heuristic (CIOH), they cluster all inputs in a transaction as belonging to the same wallet. Change output detection then identifies which output is the payment and which is returning to the sender, allowing analysts to trace funds forward across both addresses. Applied at scale across Bitcoin's full transaction history, this becomes large-scale financial surveillance.
PayJoin disrupts this pattern by making the receiver contribute an input to the transaction alongside the sender. The result is a payment that breaks the standard pattern without leaving any on-chain signal that a privacy technique was used.
-
Both heuristics fail at the same moment. The CIOH assumes all inputs in a transaction belong to the same entity. When the receiver adds an input, that assumption breaks: inputs now come from two separate parties, so an analyst applying CIOH incorrectly merges their identity clusters. Change output detection fails for the same reason, as the additional input means the total input value no longer fits the expected payment-plus-change pattern, and the analyst cannot reliably identify which output is which.
-
The transaction is ambiguous from the outside. If the analyst has profiles for both parties, they may suspect a PayJoin occurred but still cannot determine which output belongs to whom. If there are no profiles for either party, the transaction is indistinguishable from an ordinary two-input payment.
-
Receivers benefit too. A merchant running BTCPay Server contributes one of their own UTXOs as an input when receiving a payment. The resulting transaction breaks both heuristics for the receiver just as it does for the sender, and an analyst cannot determine which output is the incoming payment and which belongs to the merchant.
-
No coordinator required. PayJoin happens at the point of payment between two parties. There is no mixing pool, no waiting for other participants, and no third-party coordinator. This makes it invisible to network-level surveillance as a distinct mixing event.
How Does PayJoin Work?
Take as an example a regular Bitcoin payment. Alice wants to pay Bob 0.1 BTC, and she owns one UTXO worth 0.19 BTC. She creates a transaction with one input (0.19 BTC), a payment output of 0.1 BTC to Bob's address, and change returning to herself (0.08999 BTC after a 1,000 sat transaction fee).
Any analyst looking at this transaction can identify the 0.1 BTC output as the payment (round number, new address) and the 0.08999 BTC output as change (remainder, likely returning to Alice). They can trace Bob's address forward as a payment recipient and Alice's change address as a continued spend chain.
In a PayJoin, the transaction is constructed differently.
- Alice initiates a payment to Bob for 0.1 BTC and signals that she supports PayJoin.
- Bob's wallet contributes one of his own UTXOs as an additional input: 0.07341 BTC, a non-round amount from a previous transaction.
- The outputs are adjusted to preserve the original payment amount. Bob receives 0.17341 BTC (the 0.1 BTC payment plus his 0.07341 BTC input returned). Alice pays the 1,000 sat fee and receives 0.08999 BTC in change.
- Both parties sign and the transaction broadcasts normally.
From an on-chain perspective, the result is an ordinary-looking two-input, two-output transaction. Neither output is a round number. Neither maps to the actual 0.1 BTC payment amount. An analyst looking at outputs of 0.17341 BTC and 0.08999 BTC has no solid basis for identifying which is the payment and which is change.
The chain analysis heuristics fail on both counts. The CIOH incorrectly clusters Alice's and Bob's inputs as belonging to the same wallet. Change output detection fails because neither output fits the expected payment-plus-change pattern.
PayJoin vs. CoinJoin
PayJoin and CoinJoin address different parts of the on-chain privacy problem.
CoinJoin breaks historical UTXO links through mixing: by combining many inputs and producing equal-denomination outputs, it creates a large anonymity set where attribution probability drops with each participant. A CoinJoin round with 10 participants gives each output a 1-in-10 attribution probability.
PayJoin always involves exactly two parties, so there is no equivalent anonymity set. The privacy gain is structural rather than probabilistic: standard heuristics stop producing reliable outputs entirely.
The two techniques work at different points in the payment flow.
- CoinJoin is a step applied to UTXOs you already hold.
- PayJoin happens at the moment of payment, with no additional step and no coordinator.
Because PayJoin transactions are indistinguishable from ordinary multi-input payments, widespread adoption degrades chain analysis data quality across the full UTXO set, even for transactions that are not PayJoins at all. Used together, CoinJoin addresses historical UTXO exposure while PayJoin prevents new payment history from being built.
| PayJoin | CoinJoin | |
|---|---|---|
| Anonymity set | 2 parties (sender + receiver) | Many participants |
| Detectable on-chain? | No. Looks like a normal payment | Yes. Identifiable by structure |
| Requires coordinator? | No | Yes (or decentralised marketplace) |
| When does it work? | At the point of payment | As a separate mixing step |
| Defeats CIOH? | Yes | Yes |
| Defeats change detection? | Yes | Partially (change outputs are residual) |
What is the BIP-78 Protocol?
BIP-78 is the technical standard that defines how a PayJoin transaction is constructed between two parties without a coordinator.
The core challenge is that both parties need to contribute inputs to the same transaction, but they cannot share a single PSBT simultaneously. The receiver needs to see the sender's PSBT first, then add their own input. BIP-78 solves this through a structured, interactive PSBT exchange over HTTPS.
The receiver hosts a "payment endpoint," an HTTPS URL that acts as the coordination point. The sender's wallet knows to contact this endpoint because the receiver includes it as a pj= parameter inside a standard BIP-21 payment URI — the same URI format used for ordinary Bitcoin payments.
This makes PayJoin backward-compatible: a sender whose wallet does not support PayJoin simply ignores the pj= parameter and pays normally without any user intervention.
The protocol works as follows:
- The receiver publishes a BIP-21 payment URI that includes a
pj=parameter pointing to their PayJoin endpoint. This is how the receiver signals that they support and are willing to participate in PayJoin. - The sender's wallet detects the
pj=parameter and, if PayJoin-compatible, constructs a standard PSBT for the full payment amount and posts it to the endpoint via HTTPS. - The receiver's software receives the PSBT, adds one of their own UTXOs as an additional input, adjusts the output amounts so the original payment total is preserved, and returns the modified PSBT.
- The sender's wallet verifies that the original payment amount is intact and no unauthorized outputs have been added, then signs and broadcasts the final transaction.
The sender cannot be tricked into paying more than intended because the wallet checks output totals before signing. The receiver cannot steal the sender's funds because the sender must sign before the transaction is valid, and signing only happens after the wallet confirms the amounts are correct. HTTPS is required to prevent man-in-the-middle modification of the PSBT in transit.
The practical constraint of BIP-78 is the receiver-side server requirement. Hosting an HTTPS endpoint is straightforward for merchants running BTCPay Server, but can be cumbersome for most individuals. BIP-77 (Serverless PayJoin) addresses this by routing communication through relay infrastructure that neither party needs to operate, making PayJoin viable for peer-to-peer use without a server.
What Tools Support PayJoin?
PayJoin requires both the sender's wallet and the receiver's payment infrastructure to support the protocol. Sparrow Wallet supports PayJoin sending and BTCPay Server supports PayJoin receiving.
-
Sparrow Wallet (sender) detects the
pj=parameter in a BIP-21 payment URI automatically. When the parameter is present, Sparrow runs the interactive protocol without requiring any manual configuration. If the endpoint is unavailable, Sparrow falls back to broadcasting a normal transaction. Coldcard signs the resulting PSBT normally. From Coldcard's perspective it is signing a multi-input PSBT, which it handles the same way as any other transaction. -
BTCPay Server (receiver) has native BIP-78 support. PayJoin is enabled automatically for supported senders paying a BTCPay invoice. This means merchant payment infrastructure already supports PayJoin receiving wherever BTCPay is deployed, without any additional setup.
In practice, PayJoin is most accessible in the merchant context, where a BTCPay-powered payment page can receive PayJoin from any compatible wallet. Peer-to-peer use requires both parties to use compatible software and the receiver to run a BTCPay instance or equivalent.
Sending a PayJoin with Sparrow and Coldcard
Sparrow handles the PayJoin protocol automatically when the receiver's payment URI includes a pj= endpoint. Coldcard signs the resulting multi-input PSBT normally and does not require any PayJoin-specific configuration.
- Obtain the payment URI. The receiver provides a BIP-21 URI with a
pj=parameter pointing to their endpoint (typically a BTCPay Server payment page). This may be a clickable link, a QR code, or a pasted string. - Initiate payment in Sparrow. Paste the URI or scan the QR code. Sparrow detects the
pj=parameter and prepares to run the PayJoin protocol automatically. - Sparrow negotiates with the receiver's endpoint. Sparrow sends the initial PSBT to the endpoint. The receiver's software adds their input, adjusts the output amounts, and returns the modified PSBT. Sparrow verifies that your original payment amount is preserved and no unauthorized outputs have been added.
- Sign with Coldcard. Export the modified PSBT to Coldcard via your preferred air-gap channel (BBQr QR code, MicroSD, or NFC). The PSBT contains multiple inputs, including the receiver's. On Coldcard's screen, verify that the payment amount and destination address are correct, then approve and sign.
- Broadcast in Sparrow. Return the signed PSBT to Sparrow and broadcast. The transaction settles on-chain as an ordinary multi-input payment with no indicator that PayJoin was used.
If the receiver's endpoint is offline or unresponsive at step 3, Sparrow falls back to broadcasting a standard transaction automatically. The payment completes either way.
What is Serverless PayJoin (BIP-77)?
BIP-77 proposes to remove the server barrier through relay-based communication that neither party needs to operate.
BIP-77 uses Oblivious HTTP (OHTTP) relay nodes as intermediaries. The sender and receiver communicate through the relay, but the relay cannot read the content because communication is end-to-end encrypted. The relay knows only that two parties are exchanging data. It cannot see the PSBT contents or identify the participants.
The protocol is also asynchronous. Under BIP-78, the sender must wait for the receiver to be online and respond. Under BIP-77, the sender can post the PSBT to the relay and the receiver can pick it up later, enabling PayJoin even when both parties are not online simultaneously.
BIP-77 is a draft standard as of writing, not yet widely deployed in wallet software.
Bitcoin Address Reuse and Management covers the complementary on-chain privacy practice of using fresh addresses that prevents receive-side linkage, the foundation that PayJoin builds on.
Related articles
What is Bitcoin Privacy?
The privacy context PayJoin operates in and the three-layer framework it addresses.
What is CoinJoin?
The companion on-chain privacy technique for breaking historical UTXO links.
Bitcoin Address Reuse and Management
The address hygiene practice that forms the foundation PayJoin builds on.