Payjoin Foundation has received approval from the Internal Revenue Service recognizing the Foundation as tax-exempt under Section 501(c)(3) of the Internal Revenue Code effective July 23, 2025. We announce it now because we have just received the determination letter from the IRS. We can now accept tax-deductible charitable contributions to support our mission to advance practical privacy in peer-to-peer digital transactions. We're finalizing our online donation flow; if you'd like to contribute now, please see our donate page.

Having an organized foundation with a dedicated budget enables us to recruit talent to solve specific problems rather than recommend an external org make a grant to each individual contributor whose talents may serve the mission more effectively on deep technical work than making it legible to an organization without a technical mission.

I'll highlight @chavic's work on Dart bindings as an example. Before we met Chavic, we had a controversial monthslong, fraught discussion about all the work needed to be done to make Dart bindings work for those implementations who were most interested in jumping on the chance to run production Async Payjoin pilots. Both Cake Wallet and Bull Bitcoin Mobile apps are built in the Dart programming language, while Payjoin Dev Kit is built in Rust. PDK's strategy is to maintain a strongly-typed, well-tested core in Rust that we bind to various downstream languages for end users.

We reached out to Chavic, a young developer from Zambia, because of his public experience building Dart bindings from Rust outside of the Bitcoin space. Since "make all the library bindings work" might be hard to convey to "make Freedom Money" donors, I'd wager his applications to outside orgs would spend half a year or more in Bitcoin Grant Purgatory. Instead, we recruited his help in the span of a week and updated our Dart bindings before that grant would get approved. Not only are we seeing the results of our teamwork with Chavic in Payjoin Dev Kit, even Bitcoin Dev Kit is using his work now. This kind of recruiting is only possible by the same team that's having the burning technical issues, and organization lets us move much faster in this regard.

Nonprofit structure also frees us from some limitations of for-profit orientation, aligning our incentives with users' most pressing but hard-to-monetize concerns. Our accountability is to the public interest, not to quarterly returns. This makes it easier for us to make hard decisions prioritizing a long term view. Formalizing responsibility and accountability of Foundation leadership helps donors and users know that decisions are not made lightly. It also gives contributors clear direction and makes establishing a culture a more explicit, deliberate endeavor based on a formal written mission and norms. The Foundation is overseen by our board and operated for public benefit. Donations do not provide control over technical direction. We'll publish periodic updates on our work and funding as our reporting practices mature.

Thanks to all of our supporters, without which this work would not be possible. OpenSats and Cake Wallet get a shoutout here for being the very first to fund the Foundation itself. Thank you.

Feedback from implementations fuels our growth, and we want to thank Cake Wallet for being their close collaboration and reporting which helped lead to our stable rust-payjoin 1.0 release candidate. Just now, they have offered generous material support to the Payjoin Foundation to continue operations.

Cake wallet has been leading the way on the cutting edge of Bitcoin privacy technology and user experience. Async Payjoin is now their default Bitcoin flow, and their early support helps us improve so that more wallets and software may interoperate with Cake's use of the BIP 77 standard.

Cake wallet also runs an OHTTP Relay which users can use to reach Payjoin Directories, making the Payjoin infrastructure more robust and decentralized.

Vik's incessant Payjoin evangelism has brought Payjoin to a new audience at conferences, online, and in my experience even on the fly at chance meetings in restaurants. His message is clear: the world needs more Payjoin, and the time to support it is now. Seth has been a pleasure to work with since the beginning of the project, nudging developers to use the tools, offering his hand to contribute edits to the upstream source to improve the developer experience, and of course convincing the Cake team Payjoin needs doing. Konstantin has been the most reliable implementing developer, getting up at odd hours to service requests from our team and user feedback, and contributing his feedback to inform the integration upstream. The Cake pilot integration brings Async Payjoin to hundreds of thousands of devices.

Their recent generous donation to Payjoin Foundation additionally bolsters our ability to recruit and improve the core protocol libraries.

Thank you Cake for your generous support. The future of Bitcoin depends on it.

Spiral Bitcoin Wizard and longtime Bitcoin privacy developer Yuval Kogman joins Payjoin Foundation as the first Advisory Board member. He draws on more than two decades of programming experience. Few others can boast Yuval's dedication to the Bitcoin privacy niche. He is perhaps best known for his work developing the WabiSabi DoS prevention protocol. His subsequent whistleblowing of privacy vulnerabilities in CoinJoin implementations, including those touting WabiSabi integration, demonstrates his commitment to the underlying principles.

Commercial attempts to solve Bitcoin’s privacy problems have faced tremendous barriers. Short-term profit motives have delivered partial and temporary solutions, but transacting privately on Bitcoin remains a challenge.

We formed Payjoin Foundation to pursue the long-term mission of addressing Bitcoin’s privacy problems. Our non-profit exists to develop open-source protocols that align economic incentives with network-wide privacy protection. We believe that users have a right to choose whether or not to reveal their on-chain activity, and that such protocols can even offer a more convenient and delightful experience than those that don't respect this choice.

Liana secures bitcoin such that after time passes, if and only if you haven't yet spent your coins, your heirs can spend them. This condition is called a "timelock" contract. To prevent unintentional activation of this inheritance policy, these timelocked coins require periodic refreshing by being spent into a new timelock. Liana's Payjoin integration automates timelock refresh as payments are received, boosting privacy and cutting costs.

Due to a docker misconfiguration, the payjo.in directory server had an open redis database, allowing unauthorized parties to observe exchanges between pairs of senders which only support BIP 78 and receivers which support BIP 77.

Some payjoins which used the backwards compatibility of BIP 77 receivers with BIP 78 senders during this period may thus not have the common input ownership heuristic protection they otherwise would, but the unauthorized access does not change the nature of the risk regarding the user custody of funds.

The following is a conclusive address of concerns around UTXO probing attacks on Payjoin, clarification of why current mitigations are effective, and definitive argument for Payjoin adoption. Payjoin, the fundamental interactive transaction batching protocol, saves fees by reducing the effective size of transfers and improves privacy by disrupting common blockchain surveillance heuristics. While probing attacks exist in theory, they're costly to pull off, mitigated in practice, and are not a meaningful barrier to adoption.

Payjoin is a transformative protocol that enables wallets to communicate and create collaborative, smarter, and more efficient Bitcoin transactions. It offers payment batching technology that exchanges and payment processors can use to save on fees and protect their own and their users' financial privacy while scaling Bitcoin.

Payjoin V1 coordinates transactions between two parties who communicate over a public server endpoint secured by either TLS or Tor hidden service hosted by the receiver. This requires setting up either an HTTPS proxy or a Tor proxy when testing payjoins across different implementations.

On July 27, HRF announced a 2 BTC bounty for a production deployment and specification of a version 2 payjoin spec to receive payjoin without hosting a server. This past week I proposed a new BIP and call for feedback in search of consensus on what that spec should be. Many new ideas were born. This is my attempt to make sense of them.