Checked, not claimed
Which wallets
actually support this
Four separate abilities get treated as one thing, and they are not. A wallet can pay a silent payment address without being able to receive one. It can read a payment name without understanding Lightning. Most comparison tables collapse all of it into a tick.
Every yes below was checked against the project’s own release notes or its source code at a tagged release. Not checked means nobody checked, not “probably not”. Last gone through on ….
The finding
One implementation can do the whole journey
Resolve a name, read what is in it, and pay it: only Core Lightning managed all three when we tried it. Sparrow does the on-chain half and reads names. Phoenix does the Lightning half and reads names. Neither does the other one’s half.
That split is exactly why a payment name should carry both a silent payment address and a Lightning offer. Whoever pays you has half the picture, and which half depends on which wallet they happen to use.
The table
No hardware wallet can receive a silent payment. Not one.
This is the biggest gap in the whole field and it is barely mentioned anywhere. The standard that would let a signing device hold silent payment funds is implemented in no released firmware, by anybody. So receiving silent payments today means a hot wallet, which is exactly where privacy-minded people least want their savings.
Sending is better but still thin. One device has shipped it: …
Open, unmerged work exists at …. Nothing at all at ….
Community tables commonly show four devices as supporting this. That reading comes from misreading an amber icon as a green one: three of the four have open pull requests, not shipped firmware.
“Resolves payment names” hides three different things
BIP 353 turns entirely on a signature chain, and wallets treat that with very different seriousness. Sparrow, Core Lightning and Blockstream check the chain themselves, carrying the root key in their own code. phoenixd and Zeus ask a public resolver whether the answer was authentic and believe the reply, which the specification says clients must not do. Cake validates a proof but pays an address that came from somewhere else.
We have not seen another public comparison make this distinction, and it is the one that decides whether a payment name can be redirected by whoever controls the network between you and your resolver.
How this was checked, so you can disagree with it
A yes needed a primary source: the release notes, the changelog, or the source at a tagged release. Community comparison tables were used to decide what to go and look at, never as the evidence. Where we disagreed with one, the wallet’s own code won.
Three things we found that are widely repeated and wrong: a wallet supporting Lightning
Address does not support BIP 353, they are different mechanisms with
different trust models; a wallet detecting an lno1 string does not mean it
can pay one; and a changelog entry announcing a feature does not mean the feature is
switched on in the build being distributed today.
Nothing here is a recommendation. It is a record of what four specific capabilities looked like on one date, published because we could not find one and had to build it anyway.