Dan Gould (Payjoin Dev Kit): “We aim to accelerate Payjoin a…

The lead developer of PDK spoke to Atlas21’s microphones explaining how Payjoin can raise the privacy level for all Bitcoin network users.

Dan Gould, lead developer of Payjoin Dev Kit, spoke to Atlas21’s microphones about Payjoin adoption, technical challenges, benefits, and the development status of the Payjoin Dev Kit library.

What is a Payjoin transaction?

“I think of Payjoin more as a coordination mechanism than as a transaction format. It’s the simplest way for two parties to group their inputs into a single transaction, essentially it allows batching between two parties. For example, a deposit to an exchange can directly fund withdrawals because the exchange can group its own inputs with the incoming deposit. The other use case is the classic one: you have a sender and a receiver, and the receiver generates an address with associated Payjoin metadata. When that QR code is scanned, the sender sends the transaction to the receiver through a side channel instead of on the Bitcoin network. The receiver can then automatically consolidate their own inputs by merging them with those of the sender.”

What incentives do exchanges have to implement Payjoin?

“There are two ways an exchange can save on fees. The first, if the sender directly funds withdrawals, the exchange never has to take a UTXO from its treasury to then spend it later, so it doesn’t pay fees on that input. Additionally, if a consolidation was going to happen anyway, normally the sender covers the cost of an extra input. All other operations that end up in the same batch share the fixed costs of the transaction. In other words, you’re putting more inputs within fewer bytes on the blockchain, obtaining a strong incentive for fee savings.”

In the future, do you think major exchanges will integrate Payjoin?

“Bull Bitcoin will be the first exchange to support it. It’s very easy for them because, at least with their self-custody mobile wallet, they can abstract everything behind the buy and sell button, so it happens automatically. I think it’s also in the interest of larger exchanges to support it, because it gives them better tools for UTXO management. This doesn’t hinder any type of KYC or compliance they need to do. They can still collect all the same information from their users. But the fact that Payjoin exists makes it more difficult for third parties to obtain the balance of an address cluster, who they’ve interacted with in the past, who they’ll interact with in the future, and how much volume regularly comes in and goes out.”

What are the concrete benefits of Payjoin in terms of privacy?

“The biggest benefit is for the network as a whole: if there’s sufficient Payjoin adoption, then surveillance heuristics are no longer reliable. The second benefit is the opportunity to save fees by packing more inputs into fewer bytes on-chain. The third benefit is the ability to communicate out-of-band when we do these batches, so sometimes we don’t even need to do two transactions when one is sufficient. An example is funding a Lightning channel: typically you send funds to a single-sig wallet, then the Lightning node sends another transaction that opens a channel. With Payjoin, a wallet that knows nothing about Lightning can contribute to a batch that directly opens a channel.”

Is there a specific percentage of users who need to use it for the network to benefit?

“If any user uses Payjoin, the network benefits because the heuristics of blockchain analysis companies are no longer 100% reliable. What is considered statistically significant by an analyst will vary depending on the precision they need to have confidence in their analysis. But the mere fact that the possibility of a Payjoin exists creates a potential counterexample for any transaction that has multiple inputs.”

Why has Payjoin adoption never taken off on a large scale?

“The biggest problem historically was that everyone had to implement their own version. Additionally, old versions required the receiver to manage an always-on and publicly accessible server. The first thing we did was fix the protocol. In the last two years we’ve developed an asynchronous Payjoin protocol that externalizes this responsibility of managing a server to a blind third party (directory) that doesn’t see the messages. We also use OHTTP (Oblivious HTTP) to protect metadata, similar to Apple’s iCloud Private Relay. Once we developed the asynchronous protocol, we no longer need the sender and recipient to be online simultaneously. This was merged into the BIPs repository last July as BIP77. In parallel, we developed the Payjoin Dev Kit, a highly tested Rust library that correctly implements the specification. Now anyone who wants to integrate it can use it and create a Payjoin implementation in less than 2,000 lines of code.”

With version 2, who can manage these directories?

“Anyone can manage the directories. There’s open-source software written in Rust. It’s a simple store-and-forward server, so it’s not expensive to manage. You’re just storing and forwarding packets of eight kilobytes of random data. If you have a server accessible on the Internet with a domain name and a TLS certificate, it can be used by anyone.”

Are there already wallets that have implemented PDK?

“Yes, there are several proof-of-concept implementations and pilot tests in production. We have two production tests in 2025 with Bull Bitcoin and Cake Wallet, where Payjoin is integrated into the default payment experience. We’ve also demonstrated that Payjoin Dev Kit works in Liana and in the Boltz exchange at this year’s MIT Bitcoin Expo Hackathon. Last week we released the Rust Payjoin 1.0 release candidate, so we think it’s stable and people can take it and integrate it themselves. One of the reasons it hasn’t been possible to integrate it everywhere is because the Dev Kit wasn’t stable enough. Now with this 1.0 release candidate, people have all the components they need.”

How likely is it that in the future there will be wallets that implement Payjoin by default, so that users don’t even notice they’re using it?

“I would say that already now people who use it probably don’t really know it. Their experience hasn’t changed significantly. The way Payjoin works allows it to happen automatically in the background with a default flow. And if the protocol fails, a typical standard transaction is carried out. It’s already possible for wallets to integrate it into their default flow and some have already done so. We’ll see more wallets do it and we’ll improve the user experience now that we’ve demonstrated the first tests.”

If you had to convince a developer to integrate PDK into their wallet, what would be your main argument?

“We’ve been fortunate that we haven’t had to convince so many developers. We’ve had more demand for Payjoin integration than we’ve actually been able to provide due to Dev Kit limitations. But if someone is undecided, I would first point to the benefits: the entire network benefits from it, so you’re doing good and your users especially have a better defense against these heuristic-based attacks. I would also say that it’s quite easy to have a working proof of concept in a weekend. You can look at the reference implementation and pilot tests to see that it’s possible to integrate it without disrupting the flow that your users already expect.”

What are you currently working on?

“Right now we’ve released the 1.0 release candidate and we’re making sure the API is stable. We’re updating our existing pilot tests to 1.0, we’re doing an integration with Liana, with Boltz, and we’re expanding our integration with Bull Bitcoin. Our plan is to accelerate adoption in 2026 toward many more wallets and services. We’re also starting to dedicate ourselves to researching a multi-party Payjoin protocol. We’ve demonstrated that the scan-send flow can be extended beyond two-party batching to multi-party batching. I believe this next generation, Payjoin v3, is something we can realize.”

The post Dan Gould (Payjoin Dev Kit): “We aim to accelerate Payjoin adoption in 2026” appeared first on Atlas21.

Generated by RSStT. The copyright belongs to the original author.

Source