One Send, Three Recipients, One Fee

OCTOBER 4, 2026

Another follow-up on my Lightning in a Jar review, and the usual disclosure applies: the wallet's builder is a friend, and this started as a message, not a press release. Last night he posted a screenshot of a test spend with a one-line announcement: the wallet now supports multiple recipients in one send, silent payments included. His closing line was a rallying cry — get those transactions back onchain — which is a notable thing for the author of a Lightning wallet to say, and roughly what you'd expect a pizzeria to say if it started handing out salad coupons.

My rule with this project has been to go and check whatever I'm told. This time there was something unusually checkable: a transaction. A screenshot proves nothing, but a transaction either exists or it doesn't.

What the Blockchain Says

It exists. The screenshot gave a block height (969,791) and the first and last characters of a transaction id; I pulled that block and found exactly one transaction matching both ends. It confirmed on the evening of October 3, Pacific time. The raw facts, which agree with the wallet's own display to the satoshi:

• One input of 30,227 sats.
• Three payments of 1,001, 2,002 and 3,003 sats — the sort of numbers you choose when you want to read your own test transaction at a glance.
• One change output of 23,576 sats back to the wallet.
• One fee of 645 sats on a 214.5 vbyte transaction: three sats per vbyte, as displayed.

Those add up: 1,001 + 2,002 + 3,003 + 23,576 + 645 = 30,227, nothing missing, nothing spare. The second payment went to a taproot output (the kind whose addresses start bc1p), while the other two went to ordinary native-SegWit addresses. That's what you'd see if the second recipient were a silent-payment address, since a silent payment lands in a taproot output. The wallet's screen labels that recipient as one.

What the Repository Says

The public repository has the matching change. The October 2 sync of the project notes engine v305 as several recipients in one on-chain send (at most 20), one fee, one change output — which is precisely the shape of the transaction above. I didn't read the implementation line by line, as I did for the silent-payment recovery code last time; I'm reporting that the code's own description matches what the chain shows.

What Batching Buys You (and What It Costs)

The benefit is mostly arithmetic. Every transaction pays for its own overhead — a header, an input, a change output — and a batched send pays that once instead of three times. My back-of-envelope: three separate one-recipient spends of the same kind would come to roughly 430 vbytes against this transaction's 214.5, so about half the fee at the same rate. That's my estimate from standard transaction sizes, not something I measured, and it assumes each separate spend would have had its own change. The saving grows with the number of recipients and shrinks if you were going to sweep a whole coin anyway.

The cost is privacy, and it's the usual one: everyone you paid is now in the same transaction, visible together, with one change output pointing back at you. For paying three people you'd rather keep unlinked, three separate sends are still the more private choice, and a silent-payment address doesn't change that — it hides which address the recipient owns, not the fact that the payments share a transaction. Worth saying plainly, since "silent payments" and "batching" are both words people hear as "private."

Where I Could Be Wrong

• One transaction is one transaction. It shows the feature works once, for three recipients, on the builder's own device. It says nothing about twenty, about failure cases, or about what happens when a recipient's address is malformed.
• I can't confirm the silent payment from the outside. A taproot output looks the same whether it came from a silent-payment address or a plain one. Only the recipient's wallet can tell it found a payment. I haven't seen that end of it.
• I haven't run the wallet. Everything here comes from the chain, the public code's own notes, and the builder's word.

None of that moves the verdict in the original review, which was never about any one feature; the gates I named there are the same ones. What this adds to the pattern from the silent-payments post and its follow-up is another small data point: he says what he's building, the code and the chain show it, and the caveats come out before I ask for them. A Lightning wallet that keeps getting better at on-chain is an odd trajectory. I'll keep checking.