Bitcoin PayJoin Implementations Compared
Compare Bitcoin PayJoin implementations by wallet support, protocol version, privacy gains, and user experience. BIP 78 vs BIP 77 support matrix.
PayJoin Implementation Overview
PayJoin is a privacy-preserving Bitcoin payment protocol where both sender and receiver contribute inputs to a single transaction. Unlike CoinJoin, which requires coordination among many participants and produces recognizable on-chain patterns, PayJoin transactions are steganographic: they look identical to ordinary payments. This property makes PayJoin one of the most effective tools for breaking the common-input-ownership heuristic that chain analysis firms rely on to cluster wallet addresses.
Two protocol versions exist. BIP 78, authored by Nicolas Dorier and deployed since 2020, defines a synchronous HTTP-based exchange where the receiver must host an always-online server. BIP 77 (PayJoin v2), co-authored by Dan Gould and Yuval Kogman, replaces the server requirement with an asynchronous relay architecture, opening PayJoin to mobile wallets and everyday users. The following table summarizes wallet support across both versions.
| Wallet / Service | PayJoin Since | Protocol | Send | Receive | Status |
|---|---|---|---|---|---|
| BTCPay Server | v1.0.4.0 (Apr 2020) | BIP 78 + BIP 77 | Yes | Yes | Active |
| JoinMarket | v0.7.0 (Sep 2020) | BIP 78 | Yes | Yes | Active |
| Wasabi Wallet | v1.1.12 (Aug 2020) | BIP 78 | Yes | No | Active |
| Sparrow Wallet | v0.9.7 (Nov 2020) | BIP 78 | Yes | No | Active |
| BlueWallet | v5.6.1 (Oct 2020) | BIP 78 | Yes | Planned | Active |
| Bull Bitcoin | v0.4.0 (Dec 2024) | BIP 78 + BIP 77 | Yes | Yes | Active |
| Cake Wallet | v4.28 (May 2025) | BIP 78 + BIP 77 | Yes | Yes | Active |
| Coldcard | FW v3.2.1 (Jan 2021) | BIP 78 (signing) | Signing only | No | Active |
| payjoin-cli | v0.0.1-alpha (Dec 2023) | BIP 78 + BIP 77 | Yes | Yes | Experimental |
For a broader view of Bitcoin privacy tools, see the Bitcoin privacy tools comparison and CoinJoin implementations guide.
BIP 78 vs BIP 77: Protocol Differences
BIP 78 and BIP 77 share the same core transaction structure: the sender creates a fully signed PSBT, the receiver adds their own inputs and returns a modified proposal, and the sender validates, re-signs, and broadcasts. The differences lie in how the two parties communicate.
| Dimension | BIP 78 (v1) | BIP 77 (v2) |
|---|---|---|
| Communication | Synchronous HTTPS | Asynchronous via relay directory |
| Receiver requirement | Always-online public HTTPS endpoint | HTTP client only (no server) |
| Online requirement | Both parties simultaneously | Parties can be offline; messages stored |
| Target environment | Merchant servers (BTCPay Server) | Mobile wallets, any environment |
| IP privacy | Direct connection (sender IP visible) | OHTTP relay hides IP from directory |
| Encryption | TLS only | HPKE end-to-end encryption |
| PSBT version | PSBT v0 (BIP 174) | PSBT v2 (BIP 370) |
| BIP status | Deployed | Draft (merged June 2025) |
| Backwards compatible | N/A | Yes (falls back to v1) |
BIP 78's server requirement made it practical only for merchants running BTCPay Server or similar infrastructure. BIP 77 eliminates this barrier by introducing the Payjoin Directory: an untrusted store-and-forward server that holds encrypted messages without learning their contents. The sender posts an encrypted Original PSBT to the directory, the receiver retrieves it at their convenience, adds inputs, and posts the Proposal PSBT back. An Oblivious HTTP (OHTTP) relay prevents the directory from correlating requests with IP addresses.
How PayJoin Breaks Chain Analysis
Blockchain surveillance relies on the common-input-ownership heuristic: the assumption that all inputs in a transaction belong to the same entity. This heuristic is the backbone of address clustering, which allows chain analysis firms to group addresses into wallet profiles and trace fund flows across the network.
PayJoin directly violates this assumption. When a sender pays a receiver, both contribute UTXOs as inputs. An observer cannot determine which inputs belong to which party. The transaction looks like a standard payment with multiple inputs, a pattern that occurs frequently in normal Bitcoin usage.
This steganographic property creates a network-wide benefit. If even a small percentage of Bitcoin transactions use PayJoin, the common-input-ownership heuristic becomes unreliable for all transactions, not just PayJoin ones. Every multi-input transaction becomes suspect. For a deeper analysis of these dynamics, see our Bitcoin privacy landscape overview and the PayJoin privacy research article.
PayJoin also obscures the true payment amount. Because the receiver adds their own input, the output values no longer directly reflect the payment size. Chain analysts cannot distinguish between the payment output and change outputs with the same confidence they apply to standard transactions.
PayJoin vs CoinJoin
PayJoin and CoinJoin both aim to improve Bitcoin fungibility and privacy, but they use fundamentally different approaches. Understanding the tradeoffs helps determine when each technique is appropriate.
| Property | PayJoin | CoinJoin |
|---|---|---|
| Participants | 2 (sender + receiver) | Many (3 to 150+) |
| On-chain appearance | Looks like a normal payment | Recognizable equal-output pattern |
| Fee overhead | Minimal (same as standard tx) | Higher (more inputs and outputs) |
| Coordination | Integrated into payment flow | Requires dedicated coordinator |
| Privacy model | Breaks input-ownership heuristic | Forward-looking anonymity set |
| Network effect | Benefits all transactions passively | Benefits participants directly |
| Regulatory perception | Indistinguishable from normal payments | Flagged by some exchanges |
CoinJoin provides a strong anonymity set for participants but creates recognizable transaction patterns that can trigger compliance flags. PayJoin provides a more subtle form of privacy that benefits the entire network without drawing attention. The two techniques are complementary: a user might CoinJoin to break the history of specific UTXOs, then use PayJoin for subsequent spending to avoid re-linking those UTXOs through the common-input heuristic. For implementation details, see our CoinJoin implementations comparison.
UTXO Consolidation Benefits
Beyond privacy, PayJoin provides practical UTXO management benefits for receivers. When a merchant accepts a PayJoin payment, they contribute one of their existing UTXOs as an input and receive the combined value (their original UTXO plus the payment) in a single output. This effectively consolidates UTXOs during normal business operations without paying additional fees for a separate consolidation transaction.
For merchants processing many small payments, UTXO fragmentation is a real cost problem. Each additional input in a future transaction adds bytes and fees. PayJoin allows receivers to continuously consolidate their UTXO set as payments arrive, reducing future transaction costs. This is particularly valuable during high-fee periods when consolidation transactions would otherwise be expensive. See our UTXO management guide for more on consolidation strategies.
Payjoin Dev Kit (PDK)
The Payjoin Dev Kit (PDK) is the reference Rust implementation of both BIP 78 and BIP 77. Maintained by Dan Gould and the Payjoin Foundation, it provides the core library that most wallet integrations build on. Bull Bitcoin and Cake Wallet both used PDK for their v2 implementations.
PDK follows a "does no IO" design pattern similar to LDK (Lightning Dev Kit): the library handles protocol state machines, coin selection, and security validation, while the integrating wallet handles networking and storage. Language bindings are available through UniFFI for Kotlin, Swift, Python, Dart/Flutter, JavaScript/WASM, and C#. The repository also includes payjoin-cli, a reference command-line client that works with Bitcoin Core, and payjoin-mailroom, a combined OHTTP relay and Payjoin Directory server.
The Payjoin Foundation, launched in August 2025 as a 501(c)(3) nonprofit, sustains PDK development with funding from OpenSats, Spiral, Human Rights Foundation, Maelstrom, Btrust, and Cake Wallet.
Implementation Details by Wallet
BTCPay Server
BTCPay Server was the first production PayJoin implementation, adding BIP 78 support in v1.0.4.0 (April 2020) with sponsorship from Blockstream. Merchants enable PayJoin in their store settings, and the feature works automatically when the store wallet has at least one available UTXO. PayJoin-compatible invoices have been the default for new hot wallets since June 2021. BTCPay Server has since added BIP 77 support, allowing asynchronous PayJoin without requiring direct sender connections.
Sparrow Wallet
Sparrow added BIP 78 send support in v0.9.7 (November 2020). When a user pastes a BIP 21 URI containing a pj= parameter, Sparrow detects PayJoin availability, submits the original transaction to the receiver's endpoint, and opens a new tab for the user to review and re-sign the PayJoin proposal. Sparrow does not support receiving PayJoin or the v2 protocol.
Wasabi Wallet
Wasabi added BIP 78 send support in v1.1.12 (August 2020). The feature survived the Wasabi 2.0 rewrite and remains functional. Wasabi's CoinJoin coordination service (zkSNACKs) was shut down in June 2024 due to regulatory pressure, but PayJoin is a separate feature that continues to work independently.
Bull Bitcoin and Cake Wallet
Bull Bitcoin (v0.4.0, December 2024) became the first commercially available mobile wallet to implement BIP 77, supporting both send and receive. It uses the payjoin-flutter bindings built on PDK. Cake Wallet followed with v4.28 (May 2025), adding BIP 77 send and receive support to its existing multi-asset wallet. Both implementations demonstrate that asynchronous PayJoin is practical on mobile devices where running a server is not an option.
Adoption and Current State
PayJoin adoption has followed two distinct phases. The first wave (2020) saw BIP 78 send support added to BTCPay Server, Sparrow, Wasabi, BlueWallet, and JoinMarket. Adoption stalled because v1's server requirement limited the receiver side to merchants running BTCPay Server, and few merchants enabled it.
The second wave began in late 2024 with BIP 77 implementations. Bull Bitcoin and Cake Wallet demonstrated that mobile-to-mobile PayJoin is now practical. BTCPay Server added v2 support. Several additional wallets are reportedly evaluating integration, including Blink, Envoy, Phoenix, Electrum, and Trezor Suite.
Precise usage statistics for PayJoin are inherently unmeasurable: the protocol is designed so that PayJoin transactions are indistinguishable from standard payments on-chain. This steganographic property is a feature, not a limitation. For context on how PayJoin fits into the broader Bitcoin privacy toolkit alongside silent payments, coin control, and CoinJoin, see our 2026 privacy landscape analysis.
Frequently Asked Questions
What is PayJoin and how does it improve Bitcoin privacy?
PayJoin is a protocol where both the sender and receiver contribute inputs to a payment transaction. This breaks the common-input-ownership heuristic that chain analysis firms use to cluster Bitcoin addresses. Because a PayJoin transaction looks identical to a normal multi-input payment, it provides privacy without drawing attention, unlike CoinJoin transactions which have recognizable patterns.
What is the difference between PayJoin v1 (BIP 78) and v2 (BIP 77)?
BIP 78 (v1) requires the receiver to host an always-online HTTPS server, making it practical only for merchants. BIP 77 (v2) replaces the server with an asynchronous relay directory, allowing any wallet (including mobile) to participate as both sender and receiver without running infrastructure. V2 also adds end-to-end HPKE encryption and OHTTP relays for IP privacy. V2 is backwards compatible with v1.
Which Bitcoin wallets support PayJoin?
For BIP 78 (v1) sending: BTCPay Server, Sparrow Wallet, Wasabi Wallet, BlueWallet, and JoinMarket. For BIP 77 (v2) with full send and receive: Bull Bitcoin (since December 2024), Cake Wallet (since May 2025), and BTCPay Server. Coldcard can sign PayJoin PSBTs as a hardware wallet. Several additional wallets are evaluating integration.
Does PayJoin cost extra fees compared to a normal Bitcoin transaction?
PayJoin adds minimal to zero fee overhead. The transaction is roughly the same size as a standard payment (the receiver adds one input but may consolidate outputs). In contrast, CoinJoin transactions are significantly larger because they involve many participants and equal-value outputs. PayJoin can actually save the receiver money over time by consolidating UTXOs during normal payment flows rather than requiring separate consolidation transactions.
Can chain analysis detect PayJoin transactions?
PayJoin transactions are designed to be indistinguishable from standard Bitcoin payments on-chain. There is no structural fingerprint that reliably identifies them. This steganographic quality means that as PayJoin adoption grows, chain analysis firms lose confidence in the common-input-ownership heuristic for all multi-input transactions, not just PayJoin ones.
How does the Payjoin Dev Kit (PDK) work?
PDK is a Rust library implementing both BIP 78 and BIP 77. It uses a typestate pattern where sender and receiver implementations progress through protocol states, and follows a "does no IO" design: the library handles protocol logic, coin selection, and security validation while the integrating wallet handles networking. Bindings exist for Kotlin, Swift, Python, Dart/Flutter, JavaScript/WASM, and C#.
How does PayJoin compare to silent payments for privacy?
Silent payments and PayJoin solve different privacy problems. Silent payments prevent address reuse by letting senders derive unique addresses from a single public identifier. PayJoin breaks input-ownership analysis by mixing sender and receiver inputs. The two techniques are complementary: silent payments protect the receiver's address graph, while PayJoin protects the input-output relationship. See our silent payments analysis for details.
This tool is for informational purposes only and does not constitute financial advice. Data is based on publicly available information from wallet documentation, BIP specifications, and official project announcements. Software versions and feature support change frequently. Always verify current wallet capabilities before relying on specific privacy features.
Build with Spark
Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.
Read the docs →
