Dan Gould: Payjoin DevKit Ships and Breaks Common Input Ownership | SLP753 artwork

Dan Gould: Payjoin DevKit Ships and Breaks Common Input Ownership | SLP753

Stephan Livera Podcast

July 7, 2026

Payjoin delivers transaction batching driven by real economic activity rather than waiting for pool participants, while also cutting fees through direct net settlement between counterparties.
Speakers: Stephan Livera, Dan Gould
**Stephan Livera** (0:01)
Hi, everyone, and welcome back to Stephan Livera Podcast. Joining me today or rejoining me today is Dan Gould from Payjoin DevKit. He is a maintainer there and also from the Payjoin Foundation. Dan, welcome back. It's been a while.
Give us kind of the quick update. What are some of the big updates or high-level thoughts on Payjoin and Payjoin DevKit since then?

**Dan Gould** (0:21)
So since we last spoke, Stephan, thanks for having me, by the way, we've come a long way in terms of the actual API for Payjoin DevKit. So 1 is eminent, I'm talking, maybe by the time you're hearing this, it's out sometime this week, which means people can take the DevKit off the shelf and make the Payjoin coordinated transactions in the wild with some vibe coding. I wouldn't push to production, but with some vibe coding in the weekend.

**Stephan Livera** (0:50)
Gotcha, yeah. And just for listeners who aren't familiar, let's kind of take it back a bit. For people who don't know what a Payjoin is, what's like the elevator picture, the very short, few sentence explanation, what is a Payjoin?

**Dan Gould** (1:02)
Yeah, so Payjoin is the most fundamental way for two people, sender and receiver, to batch a transaction together.
So Satoshi, way back in the original white paper, said that transactions necessarily reveal all the inputs belong to the same owner. And Payjoin uses some interaction, meaning the sender and the receiver wallets talk to each other in order to both contribute inputs to the transaction, which has some benefits for cut through and scaling and breaks this one assumption that Satoshi left in the white paper as a little sort of treat of where to go to address the privacy problems.

**Stephan Livera** (1:46)
So what's the current state of adoption?

**Dan Gould** (1:49)
So right now, Bull Bitcoin, Mobile and Cake are the two big pilots with real users in the wild. You can go to the app stores, download their apps and try a Payjoin today. There's a reference implementation that we maintain, Payjoin CLI that connects to Bitcoin D. And there's another sort of reference implementation using BDK. That's the BDK CLI. But you'll see a lot more developments in the coming month. There's a BDC Pay plugin that's been a community effort.
Valera and Travik, particularly, are working on. And those will come out to support the new Async Payjoin spec.

**Stephan Livera** (2:34)
Yeah. So just quickly explain that also, the V1 versus V2 of Payjoin.

**Dan Gould** (2:39)
Sure. So like I said, Payjoin is when your sender and receiver both interact to create this transaction by cooperating. And there's been many different attempts to do this. The first one that took off was in BTC Pay server by the emperor and Mr. Cooks.
And it required that the receiver run a server. So the receiver was already running the BTC Pay server. So they had a website with a secure endpoint that the sender could connect to to do those messages.
This presented a couple of problems. One was the fact that you need to run this actual infrastructure. You need to get a TLS certificate, which means you need to approve that you own a domain, perhaps. And your server needed to be online with a hot wallet. You only had like a 30-second window, the way the protocol was working. So over the past two or three years, a team of us have developed BIP77 Async Payjoin, which has some backwards compatibility with the old one, still limited by the old constraints. But if both sender and receiver are using the new Async protocol, then they store and conduct their interaction, communication through a untrusted third-party mailbox server. So it's just like email, where you put your mail on someone else's computer and you go retrieve it later. And both parties do that. And the protocol specifies that the blobs that go in the mailbox, the mail, if you will, are of the same size and indistinguishable from randomness.

**Stephan Livera** (4:26)
Gotcha. So I presume there's like some batch payments going on here. Is there a default level of batches? Like every minute, every 10 minutes? Or how does that work?

**Dan Gould** (4:34)
So this is where Payjoin differs a lot from the old approaches to Bitcoin privacy or older alternative, like the ones that have been around longer. The reason Payjoin is new is because the batch just happens when the participants to a transaction want to take some economic action. So, Stephan, I want to send you some Bitcoin. And so rather than just post a Bitcoin transaction to the network, because you're accepting Payjoin, I can send you a proposal, which you could yourself broadcast to the network, or you could return to me a batch, where say you want to do a consolidation, or you know you want to send my coins to an exchange right away, or to pay someone right away.

12 more minutes of transcript below

Feed this to your agent

Try it now — copy, paste, done:

curl -H "x-api-key: pt_demo" \
  https://spoken.md/transcripts/1000651996090

Works with Claude, ChatGPT, Cursor, and any agent that makes HTTP calls.

From $0.10 per transcript. No subscription. Credits never expire.

Using your own key:

curl -H "x-api-key: YOUR_KEY" \
  https://spoken.md/transcripts/1000775839859