Payjoin Privacy Transactions: How Cake Wallet Implements BIP78 Bitcoin Privacy

A Bitcoin user wants to send 0.5 BTC to a peer but recognizes a practical problem: standard Bitcoin transactions reveal the sender’s input address, recipient’s output address, and the amount in a permanent, transparent ledger. Blockchain analysis firms use simple heuristics to link these pieces—assuming that inputs belong to the same entity, that change goes to a newly generated address, and that transaction patterns predict ownership. For a user who values privacy, a single careless transaction can create a durable association between identity and funds. Payjoin (BIP78) is a protocol designed to weaken exactly those assumptions by changing how inputs are combined and how change is handled.

Cake Wallet, the non-custodial Bitcoin wallet trusted by over 1 million users, has integrated Payjoin support to let users break common chain analysis patterns without requiring the recipient to be technically sophisticated or to run specialized software. Understanding how Payjoin works, why it matters, and where its limitations remain is essential for users who want to move beyond basic privacy assumptions and actually reduce the information available to external observers. The privacy gain is real but conditional: it depends on both parties cooperating, on the transaction being structured correctly, and on the user recognizing that Payjoin changes the threat model without eliminating it entirely.

How standard Bitcoin transactions expose analysis points

Before Payjoin, a typical Bitcoin transaction had a recognizable structure. The sender combines one or more unspent outputs (UTXOs) as inputs, creates outputs to the recipient and to a change address, and broadcasts the result. Blockchain analysts rely on several assumptions to interpret this structure. The common input heuristic assumes that all inputs to a transaction belong to the same entity—a reasonable guess because a wallet normally combines its own UTXOs. The change assumption assumes that one output is the payment and the other is change returning to the sender, often inferred by looking for newly generated addresses or by timing and amount patterns.

These heuristics are imperfect but empirically useful. A user spending 0.5 BTC and generating 0.3 BTC in change creates a visible asymmetry. If the user reuses change addresses or generates them in a predictable pattern, the connection strengthens. If the wallet’s coin selection or address generation is observable—through timing, round amounts, or interaction with known services—analysts can make even stronger inferences. Over time, even a nominally anonymous wallet can accumulate a dossier: “This cluster of addresses is likely owned by the same entity” becomes “This entity regularly sends to merchant X” and eventually “This entity is probably person Y.”

Standard wallet software exacerbates the problem through predictability. Most wallets choose inputs in a deterministic order, select change addresses in sequence, and use round amounts. A user who spends 0.5 BTC always from the same group of inputs, always to addresses of a certain pattern, and always with change to the next address in their derivation path gives analysts multiple confirmation points. Cake Wallet addresses some of these issues through coin control and careful UTXO management, but the fundamental structure—inputs from one entity, outputs to a recipient and back to the sender—remains exposed.

What Payjoin changes in the transaction structure

Payjoin (BIP78) inverts the transaction structure by having the recipient contribute inputs to the transaction alongside the sender. Instead of a clean pattern of “sender inputs → recipient output + sender change,” a Payjoin creates “sender inputs + recipient inputs → recipient output + sender change.” The immediate effect is to break the common input heuristic: if an analyst sees inputs A and B going to outputs X and Y, they cannot simply assume A and B belong to the same entity. One input might be the sender’s, the other the recipient’s. The outputs might not correspond to the traditional payment-plus-change pattern.

A concrete example illustrates the difference. Suppose Alice wants to send 0.5 BTC to Bob using Cake Wallet’s Payjoin feature. In a standard transaction, Alice would combine her inputs (say, 0.6 BTC from two UTXOs) and create two outputs: 0.5 BTC to Bob’s address and 0.1 BTC to her change address. An analyst sees two inputs and two outputs and guesses that Alice owns both inputs, Bob receives the 0.5 BTC, and Alice receives the 0.1 BTC change. That assumption is usually correct.

In a Payjoin, Bob contributes one of his inputs to the transaction. Alice and Bob together create a transaction with three inputs: two from Alice and one from Bob. The outputs might be 0.8 BTC to Bob (his original payment request plus his change) and 0.3 BTC to Alice (her change). Now an analyst cannot easily determine which inputs belong to whom or which outputs correspond to payment versus change. The assumption “all inputs belong to one entity” is false by design. The transaction still reveals amounts and addresses, but the ownership inference becomes uncertain. That uncertainty is the privacy gain.

The role of Cake Wallet in coordinating Payjoin setup

For Payjoin to work, the sender and recipient must coordinate. The sender (Alice, using cake wallet) needs to communicate the payment request to Bob. Bob needs to be ready to receive the request, respond with his inputs, and agree to the transaction structure. The recipient must have a Bitcoin wallet capable of accepting a Payjoin request, and that wallet must be running or at least checking for incoming requests. This coordination challenge is why Payjoin is not the default for every transaction: it requires both parties to be online and cooperating at the time of payment.

Cake Wallet’s implementation handles this through a Payjoin endpoint—typically a URI that Bob can share with Alice, either through a QR code, a lightning invoice with embedded Payjoin metadata, or a static endpoint published on a payment server. When Alice initiates the payment, she contacts Bob’s endpoint with her transaction proposal. Bob’s wallet receives the proposal, checks that the payment amount matches what he requested, prepares his inputs, and responds with the modified transaction. Alice then signs her portion, Bob signs his portion, and the combined transaction is broadcast.

The critical detail is that Cake Wallet (or any Payjoin-capable sender wallet) must trust the Payjoin endpoint to some degree. If Bob’s endpoint is compromised or if a malicious intermediary intercepts the communication, they could manipulate the transaction, substitute outputs, or attempt to double-spend. Most Payjoin implementations use HTTPS and additional validation to mitigate this. Cake Wallet enforces these checks and verifies that the final transaction matches the agreed structure before broadcasting. This does not eliminate endpoint risk entirely, but it raises the cost of a successful attack.

How Payjoin breaks specific heuristics and narrows analyst reach

The common input heuristic suffers the most obvious blow. A transaction with inputs from multiple unrelated parties makes the assumption unreliable. Even if an analyst suspects Payjoin, they cannot determine which inputs came from which entity without additional information. This has a cascading effect on address clustering: if an analyst cannot confidently link addresses through common inputs, their dossier becomes fragmented. An address that appeared to belong to Alice might actually belong to Bob, or to the transaction receiver, or to a participant still unknown.

The change assumption also weakens, though less dramatically. In a standard transaction, change often returns to a newly generated address that has never appeared on the ledger before. An analyst can look for such addresses and assume they are change. Payjoin makes this heuristic unreliable because change from either the sender or recipient might go to an existing address. Additionally, the output amounts become ambiguous: if a transaction has three outputs, which one is change? Which is payment? Without knowing the sender’s intent or the recipient’s address beforehand, the guess becomes speculative.

Round-amount heuristics also suffer. Analysts sometimes assume that round amounts (like exactly 0.5 BTC) represent user-initiated payments, while “odd” amounts represent change. Payjoin disrupts this by creating outputs that represent a combination of the sender’s payment and the recipient’s change, potentially producing amounts that do not match either entity’s original intent. A 0.73 BTC output might actually be 0.5 BTC (the payment) plus 0.23 BTC (Bob’s change), but an analyst cannot distinguish this from a single 0.73 BTC payment.

The value of these broken heuristics accumulates over time. A single Payjoin transaction does not retroactively obscure past transactions. However, it does create an uncertainty perimeter around the addresses involved. If Alice and Bob use Payjoin regularly, their transaction cluster becomes increasingly difficult to untangle. Analysts may fall back on alternative methods—transaction timing, IP address logging at the network level, or information from regulated exchanges—but Payjoin successfully raises the cost and reduces the confidence of on-chain analysis alone.

Limitations and remaining risks in Payjoin privacy

Payjoin is powerful but not a complete anonymity solution. The transaction amounts, addresses, and timing remain visible on the blockchain. If either Alice or Bob later consolidates their funds with other addresses, or if they send money to a regulated exchange where their identity is known, the Payjoin benefit can be partially unwound. An exchange-level transaction linking Alice to her Payjoin change address could compromise the heuristic-breaking value. Timing analysis is another concern: if Alice’s Payjoin transaction is broadcast immediately after she receives funds from a known source, the temporal connection can support inference.

The endpoint risk deserves emphasis. If Bob’s Payjoin endpoint is compromised, the attacker can substitute outputs, steal Bob’s inputs, or force Alice to sign a transaction she did not intend. Cake Wallet mitigates this through strict validation and HTTPS requirements, but the user must still verify that they are connecting to the correct endpoint. A phishing attack could redirect Alice to a fake Payjoin endpoint that appears to be Bob’s but actually belongs to an attacker. The wallet’s address-verification tools can help, but they cannot eliminate user error.

Network-level privacy is also separate from ledger-level privacy. A Payjoin transaction does not hide Alice’s IP address from her ISP, her internet service provider, or passive network observers. If Alice connects to Bob’s endpoint over cleartext HTTP or without a VPN, her connection metadata reveals that she is making a payment. Cake Wallet does not force Tor or I2P routing for Payjoin setup, so users who require strong IP-level privacy must configure additional protections themselves. The transaction privacy gain is real, but it is limited to the blockchain level.

Finally, Payjoin requires trust in the recipient’s infrastructure. Bob must be running a compliant Payjoin endpoint, keeping his wallet online or checking for requests regularly, and protecting his private keys. If Bob’s endpoint is slow or unreliable, the payment experience suffers. If Bob’s wallet is compromised, his inputs could be misused. Cake Wallet handles the technical complexity on Alice’s side, but the entire protocol depends on both parties’ operational security. A payment that is easy to reverse or that allows the recipient to back out creates additional attack surfaces that pure technical solutions cannot fully address.

Real-world deployment considerations for Cake Wallet users

The practical value of Payjoin in Cake Wallet depends on adoption. For a user to send a Payjoin transaction, the recipient must support it. As of 2024, Payjoin adoption remains limited. Some merchants, payment processors, and wallets support BIP78, but the majority of Bitcoin recipients do not. A user trying to send a Payjoin to a friend who uses a standard wallet, or to an exchange or merchant that does not support the protocol, cannot complete the transaction using this method. The user would fall back to a standard transaction, losing the privacy benefit.

BTCPay Server has emerged as a hub for Payjoin support among merchants and self-hosted payment processors, making Payjoin viable for users who control their receiving infrastructure or who sell goods through Payjoin-aware platforms. For peer-to-peer payments, adoption depends on both friends or counterparties using compatible wallets. This creates a coordination problem: Cake Wallet enables Payjoin, but the recipient must also be prepared to cooperate. The feature is powerful precisely where adoption is weakest—among casual users and informal payments.

Cake Wallet’s free service and open-source code mean the implementation is available for inspection and testing. Users who want to verify that Payjoin is implemented correctly can review the codebase, test with compatible endpoints, and confirm that outputs and inputs are genuinely mixed rather than merely appearing to be mixed. The wallet’s support for coin control and UTXO selection also lets users choose which inputs to include in a Payjoin, adding another layer of intentionality and reducing reliance on automatic coin selection.

For users planning to use Payjoin regularly, learning the workflow is worthwhile. Understanding which counterparties support it, how to verify endpoints, and what transaction structure to expect will help avoid mistakes. Cake Wallet’s interface should make the process straightforward, but the underlying protocol has moving parts that differ from standard payments. A test transaction with a known counterpart before moving significant amounts is a reasonable precaution, as is confirming that the recipient’s endpoint is accessible and responsive.

How Payjoin fits into a broader privacy strategy

Payjoin is one tool among several that Cake Wallet provides for Bitcoin privacy. Silent Payments, which let recipients publish a static address and receive payments without address reuse, address a different problem: the leakage of information through address reuse. PayJoin addresses the structure of the transaction itself. Coin control and UTXO management address the aggregation of inputs. Tor routing and custom node selection address network-level privacy. Together, these tools let a user build a privacy strategy tailored to their threat model rather than relying on a single setting.

A user with moderate privacy needs might prioritize UTXO coin control and occasional Payjoin with trusted counterparties. A user with higher privacy needs might combine Silent Payments for receiving, Payjoin for sending, Tor routing for network access, and careful attention to consolidation patterns. A user concerned primarily about institutional surveillance might focus on avoiding exchange interactions and using Payjoin to weaken heuristic-based clustering.

The interaction between these tools matters. Payjoin works best when inputs are carefully selected—not random aggregations of old UTXOs that might reveal wallet history. Silent Payments work best when combined with Payjoin, preventing the recipient’s address from being exposed in future chain analysis. Coin control enables both of these by letting the user choose exactly which UTXOs participate in each transaction. Cake Wallet’s integration of these features, combined with the wallet’s open-source transparency and zero data collection policy, creates a platform where users can implement sophisticated privacy workflows without being forced to move to multiple applications.