Key Takeaways
- PayJoin is a collaborative transaction protocol where both the sender and receiver contribute inputs, breaking the common input ownership heuristic that chain analysis companies depend on.
- Unlike CoinJoin, PayJoin transactions are steganographic and look identical to normal Bitcoin payments on the blockchain, making them impossible to identify by external observers.
- BIP 78 defines the original PayJoin protocol using synchronous HTTPS communication, while BIP 77 (PayJoin v2) introduces an asynchronous relay based design that works for mobile wallets.
- PayJoin creates a network wide privacy benefit: even a small percentage of PayJoin transactions undermines the reliability of the CIOH heuristic across all Bitcoin transactions.
- BTCPay Server is the leading receiver implementation, with Sparrow Wallet, BlueWallet, and Wasabi Wallet supporting PayJoin sends. The Payjoin Dev Kit simplifies new integrations.
- For merchants, PayJoin provides automatic UTXO consolidation and revenue obfuscation at zero additional cost when used with BTCPay Server’s hot wallet mode.
- PayJoin is always gracefully degradable. If the protocol negotiation fails for any reason, the sender’s wallet falls back to a standard transaction and the payment still completes.
- PayJoin is complementary to other privacy tools like CoinJoin and Lightning Network. Each addresses different aspects of Bitcoin’s privacy challenges.
- From a regulatory perspective, PayJoin is the most compliance compatible privacy enhancement because it produces standard transactions with no special markers or mixing coordination.
- The future of PayJoin includes integration with Silent Payments (BIP 352), broader wallet adoption via BIP 77, and the potential to become the default payment construction method in privacy aware wallets.
Introduction to Bitcoin PayJoin
Bitcoin’s blockchain is often described as “pseudonymous” rather than anonymous. Every transaction is permanently recorded on a public ledger, and while wallet addresses are not directly tied to real world identities, sophisticated chain analysis firms have built multi billion dollar businesses around the art of deanonymizing Bitcoin users by tracing the flow of funds across the network. In this environment, PayJoin emerges as one of the most elegant and underappreciated privacy tools in the Bitcoin ecosystem.
PayJoin, also known as Pay to EndPoint (P2EP), is a collaborative transaction protocol where both the sender and the receiver contribute inputs to a single Bitcoin transaction. This seemingly simple modification has profound implications: it breaks the fundamental assumption that chain analysis companies rely on to trace payments, specifically the assumption that all inputs in a transaction belong to the same entity.
Unlike CoinJoin, which creates large, conspicuous multi party transactions that are easily identifiable on the blockchain, PayJoin transactions look indistinguishable from ordinary Bitcoin payments. An observer examining the blockchain cannot tell whether a transaction is a PayJoin or a standard payment. This stealth quality is what makes PayJoin so powerful: it does not just protect the privacy of its users, it poisons the data that chain analysis relies on for everyone, making the entire network more private.
In this advanced guide by Nadcab Labs, we explore the technical mechanics of the PayJoin protocol, its evolution from BIP 78 to the serverless BIP 77 specification, how it compares with other privacy techniques, wallet implementations, merchant use cases, security considerations, and the pivotal role PayJoin is poised to play in Bitcoin’s ongoing battle for transactional privacy.
Privacy Insight: If even 5% of all Bitcoin transactions used PayJoin, it would fundamentally undermine the reliability of the common input ownership heuristic, which is the single most important assumption used by every major blockchain surveillance company. PayJoin’s power lies not just in individual privacy but in its ability to create systemic uncertainty across the entire blockchain.
What Is PayJoin? Understanding the Core Concept
At its core, PayJoin is a modification to the standard Bitcoin payment flow where the receiver of a payment contributes one or more of their own unspent transaction outputs (UTXOs) as inputs to the transaction. In a normal Bitcoin payment, only the sender provides inputs. In a PayJoin, both parties contribute, and the resulting transaction is constructed so that it still looks like a typical payment when viewed on the blockchain.
To understand why this matters, consider how a normal Bitcoin transaction works. Alice wants to send 0.5 BTC to Bob. She constructs a transaction with one or more of her UTXOs as inputs (say, a 0.8 BTC UTXO), creates an output of 0.5 BTC to Bob’s address, and sends the remaining 0.3 BTC (minus fees) back to herself as change. A blockchain analyst looking at this transaction can reasonably assume that all inputs belong to Alice and that the 0.3 BTC change output also belongs to Alice.
In a PayJoin transaction, Bob also contributes an input, say a 0.2 BTC UTXO he already owns. The transaction now has inputs totaling 1.0 BTC (0.8 from Alice + 0.2 from Bob), and the outputs might be 0.7 BTC to Bob (his 0.5 BTC payment plus his 0.2 BTC input consolidated) and 0.3 BTC back to Alice as change. On the blockchain, this looks like a simple payment from someone who owned 1.0 BTC in inputs and sent 0.7 BTC to one address with 0.3 BTC in change. An analyst cannot determine which inputs belong to which party, and critically, they cannot determine the actual payment amount.
Normal Transaction vs PayJoin Transaction
Standard Bitcoin Payment
Only the sender provides inputs. Analyst can identify sender’s inputs, payment output, and change output with high confidence. The common input ownership heuristic applies cleanly. Payment amount is easily inferred.
PayJoin Transaction
Both sender and receiver provide inputs. Analyst cannot determine which inputs belong to whom. Payment amount is obscured. Looks identical to a normal transaction on the blockchain. The common input ownership heuristic is broken.
The Privacy Problem PayJoin Solves
To fully appreciate PayJoin, you need to understand the specific vulnerability in Bitcoin’s privacy model that it addresses. The entire blockchain surveillance industry rests on a set of heuristics, educated assumptions about transaction structure that allow analysts to cluster addresses, trace fund flows, and ultimately link transactions to real world identities.
The most powerful of these heuristics is the Common Input Ownership Heuristic (CIOH). This assumption states: if a transaction has multiple inputs, all of those inputs are owned by the same entity. The reasoning is straightforward. In a normal transaction, a single person gathers their own UTXOs to fund a payment. There is typically no reason for two unrelated parties to combine their coins into a single transaction. Chain analysis companies like Chainalysis, Elliptic, and CipherTrace use CIOH as a foundational building block to construct wallet clusters and map the flow of Bitcoin across the network.
PayJoin directly violates this assumption. When both sender and receiver contribute inputs, the CIOH no longer holds true for that transaction. But the brilliance of PayJoin goes further: even if only a small percentage of transactions are PayJoins, analysts can no longer confidently apply the CIOH to any transaction. Every multi input transaction becomes suspect. The mere existence of PayJoin creates doubt, and in blockchain analysis, doubt degrades the reliability of the entire analytical framework.
Key Concept: PayJoin creates a negative externality for surveillance. Unlike most privacy tools that only protect the user, PayJoin degrades the quality of chain analysis across the entire network. This is sometimes called “privacy by contamination” because every PayJoin transaction contaminates the dataset that surveillance companies depend on, benefiting even users who never use PayJoin themselves.
What is Proof of Burn in Bitcoin Mining?
How PayJoin Works: The Technical Deep Dive
The PayJoin protocol is an interactive process requiring communication between the sender and receiver during transaction construction. Here is a detailed breakdown of the mechanism under the hood.
The process begins when the receiver generates a BIP 21 payment URI that includes a special pj= parameter pointing to their PayJoin endpoint (an HTTP/HTTPS URL). This endpoint is a server (or in v2, a relay) that the sender’s wallet can communicate with to negotiate the collaborative transaction.
PayJoin Transaction Construction Process
1
Original PSBT Creation: The sender’s wallet constructs a standard transaction (as a Partially Signed Bitcoin Transaction, or PSBT) paying the receiver the requested amount. This is a fully valid transaction that could be broadcast as is
2
PSBT Sent to Receiver: The sender’s wallet sends this unsigned PSBT to the receiver’s PayJoin endpoint via an HTTPS POST request. This communicates the sender’s inputs and the transaction structure
3
Receiver Modifies PSBT: The receiver’s server adds one or more of its own UTXOs as additional inputs and adjusts the outputs accordingly (increasing the receiver’s output by the value of the added inputs). The receiver signs only their own inputs
4
Modified PSBT Returned: The receiver sends the modified PSBT back to the sender. The sender’s wallet validates that the payment amount has not been tampered with and that no additional fees have been imposed
5
Sender Signs and Broadcasts: After validation, the sender signs their own inputs on the modified PSBT. The now fully signed transaction is broadcast to the Bitcoin network as a single transaction
6
Fallback Mechanism: If the PayJoin negotiation fails at any step (server offline, timeout, incompatible wallet), the sender’s wallet falls back to broadcasting the original standard transaction. The payment still goes through, just without the privacy benefit
The critical design principle here is that PayJoin is always gracefully degradable. If anything goes wrong during the interactive negotiation, the sender can always fall back to a normal payment. This means PayJoin never prevents a payment from completing. It either enhances privacy or degrades to a standard transaction, but the payment always succeeds.
PayJoin vs Regular Bitcoin Transactions: What Changes On Chain
One of PayJoin’s most powerful properties is its steganographic nature. Unlike CoinJoin transactions that have distinctive, recognizable patterns on the blockchain (equal value outputs, many participants), PayJoin transactions are designed to be indistinguishable from normal payments. Let us walk through a concrete example to see the difference.
Normal Transaction
Alice pays Bob 0.5 BTC. Alice uses her 0.8 BTC UTXO.
- Inputs: 0.8 BTC (Alice)
- Output 1: 0.5 BTC → Bob
- Output 2: 0.2998 BTC → Alice (change)
- Fee: 0.0002 BTC
- Analyst sees: Clear payment of 0.5 BTC, clear change of ~0.3 BTC
PayJoin Transaction
Alice pays Bob 0.5 BTC. Bob adds his 0.3 BTC UTXO.
- Inputs: 0.8 BTC (Alice) + 0.3 BTC (Bob)
- Output 1: 0.8 BTC → Bob (payment + his input)
- Output 2: 0.2998 BTC → Alice (change)
- Fee: 0.0002 BTC
- Analyst sees: Ambiguous, could be 0.8 BTC payment, 0.3 payment, or consolidation
On the blockchain, both transactions look structurally identical: multiple inputs, two outputs. There is no cryptographic marker, no special script, no metadata that identifies a PayJoin. An analyst examining the second transaction might guess it is a standard payment of 0.8 BTC with ~0.3 BTC change, which would be entirely wrong. The actual payment was only 0.5 BTC. This ambiguity is precisely the point.
The BIP 78 Protocol: PayJoin’s Technical Standard
BIP 78 (Bitcoin Improvement Proposal 78) is the formal specification that defines the PayJoin protocol. Authored by Nicolas Dorier (the creator of BTCPay Server), BIP 78 was designed as an upgrade to the earlier BIP 79 (Bustapay) proposal, providing a more robust and standardized framework for PayJoin transactions.
Communication Protocol: BIP 78 defines a synchronous HTTP based protocol. The sender makes an HTTPS POST request to the receiver’s PayJoin endpoint, sending the original PSBT in the request body. The receiver processes it, adds their inputs, and returns the modified PSBT in the HTTP response. This is a single round trip communication model.
PSBT Format: All transaction data is exchanged using the Partially Signed Bitcoin Transaction format (BIP 174). PSBTs are a standard way to represent unsigned or partially signed transactions, making them ideal for multi party transaction construction where different participants need to add their signatures at different stages.
Sender Validation Rules: BIP 78 specifies strict validation rules that the sender must enforce after receiving the modified PSBT from the receiver. The sender must verify that the receiver has not reduced the payment amount, has not added excessive fees, has not removed the sender’s inputs, and that the transaction is otherwise valid. These rules prevent the receiver from using the protocol to steal funds.
Output Substitution: One powerful feature of BIP 78 is output substitution. The receiver may replace their original payment output with a different output (for example, using a different address or splitting the payment into multiple outputs). This adds additional privacy by preventing the sender from knowing which output belongs to the receiver in the final transaction.
Technical Note: BIP 78’s primary limitation is that it requires the receiver to run an always on HTTPS endpoint to negotiate the PayJoin. This makes it well suited for merchants running BTCPay Server but impractical for peer to peer payments between mobile wallets. This limitation is what motivated the development of BIP 77 (PayJoin v2), which we cover in Section 11.
Step by Step: How a PayJoin Transaction Executes in Practice
Let us walk through a real world PayJoin scenario step by step, from a user perspective, using a merchant payment as the example.
Step 1: Merchant Generates Invoice. A merchant running BTCPay Server creates an invoice for 0.01 BTC. The invoice generates a BIP 21 URI like bitcoin:bc1q...?amount=0.01&pj=https://merchant.com/pj. The pj= parameter signals PayJoin support.
Step 2: Sender’s Wallet Detects PayJoin. The customer opens this URI in their PayJoin compatible wallet (such as Sparrow Wallet or BlueWallet). The wallet detects the pj= parameter and initiates the PayJoin flow automatically. If the wallet does not support PayJoin, it simply ignores the parameter and makes a standard payment.
Step 3: Wallet Constructs Original PSBT. The sender’s wallet builds a standard transaction paying 0.01 BTC to the merchant. This original PSBT is the “fallback” transaction that would work as a normal payment.
Step 4: PSBT Sent to Merchant’s Endpoint. The wallet sends the PSBT via HTTPS to the merchant’s PayJoin endpoint URL. The merchant’s BTCPay Server receives it and processes the request.
Step 5: Merchant Adds Their Input. BTCPay Server selects one of the merchant’s existing UTXOs (say, 0.05 BTC from a previous sale) and adds it as an additional input. The merchant’s output is increased from 0.01 BTC to 0.06 BTC (the 0.01 BTC payment plus the 0.05 BTC input being consolidated). The merchant signs their added input and returns the modified PSBT.
Step 6: Sender Validates and Signs. The customer’s wallet validates the returned PSBT (checking that the payment amount is correct and no funds were stolen), signs the sender’s inputs, and broadcasts the final transaction to the Bitcoin network.
Step 7: Transaction Confirmed. The transaction is mined into a block. On chain, it looks like a normal payment. Neither the actual payment amount (0.01 BTC) nor the ownership of inputs is apparent to outside observers.
Breaking the Common Input Ownership Heuristic: Why It Matters
The Common Input Ownership Heuristic (CIOH) is the backbone of blockchain surveillance. Without it, chain analysis companies would lose the ability to reliably cluster wallet addresses and trace the flow of funds across transactions. PayJoin attacks this heuristic directly and systematically.
Here is why the CIOH is so powerful under normal conditions. When a user spends Bitcoin, they often need to combine multiple UTXOs to reach the desired payment amount. For example, if you have three UTXOs of 0.1, 0.2, and 0.3 BTC and want to send 0.5 BTC, your wallet combines the 0.2 and 0.3 BTC UTXOs as inputs. An analyst sees two inputs in the same transaction and concludes they belong to the same wallet. By chaining this inference across thousands of transactions, they build a complete picture of your wallet’s holdings, spending patterns, and connected addresses.
PayJoin injects false data into this analytical process. When a PayJoin transaction includes inputs from both Alice and Bob, any analyst applying the CIOH will incorrectly conclude that Alice and Bob’s inputs belong to the same entity. This not only protects the current transaction but can poison the analyst’s entire cluster model. If the analyst has been building a profile of Alice’s wallet, the false link to Bob’s UTXO can merge two completely separate wallet clusters, creating a cascade of incorrect inferences.
Direct Privacy Benefit
For the two participants in the PayJoin, the actual payment amount is obscured, the ownership of inputs is ambiguous, and the change output cannot be reliably identified. Both sender and receiver gain improved privacy.
Network Wide Privacy Benefit
The mere existence of PayJoin transactions means the CIOH can no longer be applied with full confidence to any transaction on the network. This systemic uncertainty benefits all Bitcoin users, even those who never use PayJoin.
Wallets and Software That Support PayJoin
PayJoin adoption depends on wallet support on both the sender and receiver sides. As of 2025, support has grown steadily but remains concentrated among privacy focused wallets and merchant solutions. Here is the current landscape.
The ecosystem is still in its growth phase. The biggest challenge is the chicken and egg problem: senders need receivers who support PayJoin, and receivers need senders who support it. BTCPay Server’s integration has been critical because it provides a large base of merchant receivers, creating an incentive for wallet developers to add sender support.
PayJoin vs CoinJoin vs Other Privacy Techniques
Bitcoin has several privacy enhancing techniques, each with different tradeoffs. Understanding how PayJoin compares to alternatives like CoinJoin, coin mixing, and Lightning Network helps users choose the right tool for their situation.
The key insight is that these techniques are complementary, not competing. A sophisticated Bitcoin user might use CoinJoin to break the history of their coins, PayJoin to make payments with stealth privacy, and Lightning Network for small everyday transactions. Each tool addresses a different aspect of the privacy challenge, and using them in combination provides the strongest protection.
PayJoin v2 (BIP 77): The Serverless Evolution
The original BIP 78 PayJoin protocol has a significant practical limitation: the receiver must operate an always on HTTPS server to negotiate the transaction. This works for merchants running BTCPay Server but creates a barrier for peer to peer payments, mobile wallets, and scenarios where the receiver cannot host infrastructure. BIP 77, also known as PayJoin v2, solves this problem with an asynchronous, serverless design.
BIP 77 introduces a relay based architecture. Instead of the sender communicating directly with the receiver’s server, both parties communicate through an untrusted relay directory. The relay stores encrypted messages temporarily, acting as a mailbox that both parties can check asynchronously. Crucially, the relay cannot see the contents of the messages because all communication is end to end encrypted using the Hybrid Public Key Encryption (HPKE) standard.
The asynchronous nature means that the sender and receiver do not need to be online simultaneously. The sender can post an encrypted PSBT to the relay and go offline. The receiver checks the relay later, retrieves the message, adds their inputs, encrypts the modified PSBT, and posts it back to the relay. The sender then retrieves it, signs, and broadcasts. This entire flow can happen over minutes, hours, or even days, making PayJoin practical for any payment scenario.
BIP 78 (PayJoin v1)
Synchronous HTTPS protocol. Receiver must run a server. Single round trip. Best for merchants with always on infrastructure. Sender and receiver must be online simultaneously.
BIP 77 (PayJoin v2)
Asynchronous relay based protocol. No server required. End to end encrypted via HPKE. Works for mobile wallets and P2P payments. Parties can be offline at different times.
Development Update: As of 2025, the Payjoin Dev Kit (PDK) library provides a Rust implementation of both BIP 78 and BIP 77, making it significantly easier for wallet developers to integrate PayJoin v2 support. BTCPay Server has also added BIP 77 support, meaning it can now function as a PayJoin receiver without requiring the sender to connect directly to the server.
Security Considerations and Attack Vectors
While PayJoin is designed with security in mind, understanding the potential attack vectors and mitigation strategies is essential for both users and implementers.
Output Amount Manipulation
A malicious receiver could attempt to modify the PSBT to reduce the payment amount or redirect funds. BIP 78 mandates strict sender validation: the sender must verify the payment amount has not decreased and that fee increases are within acceptable bounds before signing.
UTXO Probing Attacks
A malicious receiver could run a PayJoin endpoint solely to learn which UTXOs the sender owns by observing the inputs in the original PSBT. Mitigation: senders should use coin control to limit exposure and be aware that PayJoin reveals their selected inputs to the receiver.
Timing Correlation
An observer monitoring network traffic might correlate the HTTPS request to the PayJoin endpoint with the subsequent transaction broadcast. Using Tor for the PayJoin communication significantly reduces this risk by hiding the sender’s IP address.
Relay Compromise (v2)
In BIP 77, a compromised relay could perform metadata analysis (timing, message sizes) even though it cannot read encrypted contents. Using multiple relays or Tor hidden services mitigates this. The relay cannot tamper with encrypted payloads without detection.
Nadcab Labs Security Note: The most important security property of PayJoin is the graceful fallback. If the receiver attempts anything malicious, the sender’s wallet detects it during PSBT validation and refuses to sign. The original, unmodified transaction is broadcast instead. Users never lose funds due to a PayJoin failure; the worst case is simply losing the privacy benefit.
PayJoin for Merchants and Businesses
PayJoin offers unique advantages for businesses accepting Bitcoin payments, beyond just privacy. The protocol’s design naturally solves several operational challenges that merchants face when managing Bitcoin treasury.
Automatic UTXO Consolidation: Every PayJoin transaction gives the merchant an opportunity to consolidate existing UTXOs by adding them as inputs. Without PayJoin, merchants accumulate many small UTXOs from individual customer payments and must periodically run consolidation transactions (which cost fees). PayJoin makes consolidation happen organically with each payment received, saving on fees and reducing future transaction costs.
Revenue Obfuscation: For businesses, blockchain transparency creates competitive intelligence risks. Competitors can monitor your payment addresses and estimate your revenue, customer volume, and business patterns. PayJoin obscures the actual payment amount in each transaction, making it significantly harder for competitors to build an accurate picture of your business operations from on chain data.
BTCPay Server Integration: For merchants running BTCPay Server, PayJoin support is built in and can be enabled with a single configuration toggle. The hot wallet mode automatically handles UTXO selection, input contribution, PSBT modification, and all the cryptographic operations. The merchant does not need to understand the underlying protocol; they simply enable the feature and benefit from improved privacy on every compatible transaction.
Customer Privacy as a Service: Merchants who enable PayJoin are providing a privacy service to their customers at no additional cost. This can be a competitive differentiator, particularly for businesses serving privacy conscious customers in sectors like VPN services, domain registration, hosting providers, and digital goods marketplaces.
The Regulatory Perspective on PayJoin
PayJoin occupies an interesting position in the regulatory landscape. Unlike dedicated mixing services or privacy coins (such as Monero or Zcash) which have attracted significant regulatory scrutiny, PayJoin transactions look identical to normal Bitcoin payments on the blockchain. This makes it fundamentally different from a regulatory analysis perspective.
Not a Mixing Service: PayJoin is not a mixing or tumbling service. There is no coordinator, no pool of funds, and no third party handling users’ Bitcoin. It is simply a way for two parties to a legitimate payment to structure their transaction differently. The payment still flows from sender to receiver as intended, the amount is still correct, and both parties are identifiable to each other.
Compliance Compatibility: Because PayJoin transactions are standard Bitcoin transactions, they are fully compatible with existing compliance frameworks. Exchanges, businesses, and financial institutions can receive and send PayJoin transactions without any special handling. The transaction ID, inputs, outputs, and amounts are all visible and auditable by the parties involved, even if third party observers cannot interpret them as easily.
Regulatory Challenges: However, the fact that PayJoin degrades the effectiveness of chain analysis tools does create tension with the Travel Rule and other regulations that rely on transaction traceability. Regulators focused on AML/KYC may view privacy enhancing technologies with suspicion, regardless of their technical legitimacy. The key regulatory argument in PayJoin’s favor is that it protects legitimate commercial privacy (trade secrets, competitive information) without facilitating money laundering any more than using cash does.
At Nadcab Labs, we advise clients to approach Bitcoin privacy tools within a compliance framework. PayJoin’s design as a standard payment protocol (rather than a separate privacy service) makes it the most regulatory compatible privacy enhancement available for on chain Bitcoin transactions.
Common Misconceptions About PayJoin
Despite its elegant design, PayJoin is frequently misunderstood. Clearing up these misconceptions is important for anyone evaluating Bitcoin privacy tools.
1
“PayJoin is a type of CoinJoin”
While both involve multiple parties contributing inputs, they are fundamentally different. CoinJoin is a dedicated mixing round with many participants and equal value outputs. PayJoin is a payment between two parties that happens to include inputs from both sides. CoinJoin is conspicuous on chain; PayJoin is invisible.
2
“PayJoin provides complete anonymity”
PayJoin is not a silver bullet for anonymity. It obscures the payment amount and breaks the CIOH for the specific transaction, but it does not erase transaction history or hide the fact that a transaction occurred. It is one privacy tool among many and works best as part of a broader privacy strategy.
3
“PayJoin costs extra in fees”
A PayJoin transaction is only marginally larger than a standard transaction (due to the receiver’s additional input). The fee increase is typically negligible. For merchants, the UTXO consolidation benefit actually saves money over time by reducing future transaction costs.
4
“PayJoin requires both parties to use the same wallet”
PayJoin is a protocol standard (BIP 78/77), not a wallet specific feature. Any sender wallet that supports the standard can PayJoin with any receiver that supports it, regardless of the software being used. Interoperability is a core design goal.
5
“PayJoin only benefits the sender”
Both parties benefit. The sender gets payment amount obfuscation and CIOH disruption. The receiver gets UTXO consolidation, revenue obfuscation, and the same CIOH disruption. Additionally, every PayJoin improves the privacy of the entire network by undermining surveillance heuristics.
Implementing PayJoin: A Developer’s Perspective
For developers looking to integrate PayJoin into wallets or applications, the technical implementation involves several key components. Nadcab Labs provides blockchain development services that include PayJoin integration for custom wallet and payment solutions.
Sender Implementation: The sender side requires the ability to parse BIP 21 URIs with the pj= parameter, construct valid PSBTs, make HTTPS requests to the PayJoin endpoint, validate the returned modified PSBT against strict safety rules, sign and broadcast the final transaction, and fall back to the original transaction if negotiation fails.
Receiver Implementation: The receiver side is more complex. It requires running an HTTPS endpoint (or relay client for v2), maintaining a hot wallet with available UTXOs, implementing the UTXO selection logic for input contribution, properly modifying the PSBT (adding inputs, adjusting outputs), signing the receiver’s added inputs, and handling edge cases like concurrent requests and UTXO locking.
Using the Payjoin Dev Kit (PDK): The recommended approach for new implementations is to use the open source PDK library, available at payjoin/rust-payjoin on GitHub. PDK provides both sender and receiver implementations for BIP 78 and BIP 77, handling all the cryptographic operations, PSBT manipulation, and protocol communication. It is written in Rust with bindings available for other languages.
Testing: Developers should test PayJoin implementations on Bitcoin’s signet or testnet before deploying to mainnet. The PDK repository includes integration tests and example applications that demonstrate proper implementation patterns. Edge cases to test include: network timeouts, invalid PSBTs from the receiver, fee manipulation attempts, and concurrent PayJoin negotiations.
The Future of PayJoin and Bitcoin Privacy
PayJoin stands at a pivotal moment in its development. The technical foundations are solid, the protocol specifications are mature, and the tooling ecosystem is growing. Several trends suggest that PayJoin adoption could accelerate significantly in the coming years.
BIP 77 as a Catalyst: The serverless PayJoin v2 protocol removes the biggest barrier to adoption. When mobile wallets can receive PayJoins through relay servers without running their own infrastructure, the number of potential PayJoin participants expands from merchants with BTCPay Server to every Bitcoin wallet user. This could be the tipping point for mainstream adoption.
Silent Payments Integration: Silent Payments (BIP 352) is a complementary protocol that allows users to receive Bitcoin without reusing addresses, using a single static identifier. Combining Silent Payments with PayJoin would create a powerful privacy stack: no address reuse (Silent Payments) plus ambiguous input ownership (PayJoin). Researchers are actively exploring how these protocols can work together.
Wallet Adoption Momentum: As more wallets integrate PayJoin support, the network effect strengthens. Each new sender wallet increases the value of receiver support, and vice versa. The PDK library significantly lowers the integration barrier, making it feasible for even small wallet development teams to add PayJoin.
Growing Privacy Awareness: As blockchain surveillance tools become more sophisticated and widespread, the demand for practical privacy solutions grows. PayJoin’s unique advantage of being invisible on chain and requiring no additional cost or complexity for the user positions it as the privacy upgrade most likely to achieve mass adoption.
Final Thoughts on Bitcoin PayJoin
PayJoin represents a fundamentally different approach to Bitcoin privacy. Rather than creating special, identifiable privacy transactions that stand out on the blockchain, PayJoin quietly embeds privacy into ordinary payments. It does not shout “this is a private transaction.” It whispers doubt into every chain analysis model by making regular looking transactions ambiguous.
The protocol’s elegance lies in its simplicity and its externalities. A PayJoin transaction protects its participants, but it also degrades the reliability of surveillance heuristics for the entire network. It is the rare privacy tool that gets more effective as more people use it, creating a virtuous cycle where each adoption lowers the confidence of chain analysis across all transactions.
With the advent of BIP 77 removing the server requirement, the integration of PayJoin into major wallet software through the Payjoin Dev Kit, and growing merchant adoption via BTCPay Server, the pieces are falling into place for PayJoin to transition from a niche privacy tool to a fundamental component of how Bitcoin payments work.
At Nadcab Labs, we believe that privacy is not a feature but a fundamental right, and PayJoin is one of the most practical and effective tools available to exercise that right on the Bitcoin network. Whether you are a user, a merchant, or a developer, understanding and supporting PayJoin is an investment in Bitcoin’s long term viability as a permissionless, censorship resistant monetary system.
Frequently Asked Questions
CoinJoin is a multi party mixing protocol where many users combine their coins in a large transaction with equal value outputs, and it is clearly identifiable on the blockchain. PayJoin is a two party payment protocol where the sender and receiver both contribute inputs to a transaction that looks like a normal payment. PayJoin is invisible on chain while CoinJoin is conspicuous.
The cost difference is minimal. A PayJoin transaction has one additional input (from the receiver), which adds approximately 68 virtual bytes to the transaction size. At typical fee rates, this translates to a fraction of a cent in additional mining fees. For merchants, the UTXO consolidation benefit typically outweighs this marginal cost.
Yes, both the sender and receiver need wallets that support the PayJoin protocol (BIP 78 or BIP 77). On the sender side, wallets like Sparrow, BlueWallet, and Wasabi support PayJoin. On the receiver side, BTCPay Server is the primary implementation. If either party’s wallet does not support PayJoin, the payment still goes through as a normal transaction.
No. This is PayJoin’s core strength. A PayJoin transaction looks structurally identical to a regular Bitcoin payment with multiple inputs and two outputs. There is no on chain marker, no special script type, and no metadata that identifies it as a PayJoin. This steganographic property is what makes it fundamentally different from CoinJoin.
PayJoin creates standard Bitcoin transactions and does not involve any mixing service, coordinator, or third party. It is simply a method of constructing a payment transaction collaboratively. There are no known jurisdictions where using PayJoin specifically is illegal. However, users should always be aware of their local regulations regarding cryptocurrency transactions and privacy tools in general.
Reviewed & Edited By
Aman Vaths
Founder of Nadcab Labs
Aman Vaths is the Founder & CTO of Nadcab Labs, a global digital engineering company delivering enterprise-grade solutions across AI, Web3, Blockchain, Big Data, Cloud, Cybersecurity, and Modern Application Development. With deep technical leadership and product innovation experience, Aman has positioned Nadcab Labs as one of the most advanced engineering companies driving the next era of intelligent, secure, and scalable software systems. Under his leadership, Nadcab Labs has built 2,000+ global projects across sectors including fintech, banking, healthcare, real estate, logistics, gaming, manufacturing, and next-generation DePIN networks. Aman’s strength lies in architecting high-performance systems, end-to-end platform engineering, and designing enterprise solutions that operate at global scale.
