BIP 353 · Matt Corallo and Bastien Teinturier · Status: Complete
A name a human can type,
and a signature
a machine can check
Silent payments removed every privacy problem with publishing a bitcoin address and left one usability problem: the address is 116 characters long. Nobody reads that down a phone. Nobody puts it on a business card. BIP 353 is the fix, and it is deliberately unexciting.
A DNS TXT record, signed, holding a bitcoin: URI. That is the whole standard.
What makes it interesting is the second half: the signature chain can be handed to a device
with no network at all, and it will still know the name is genuine.
§ 01 · The record
Anatomy of a payment name
user sits between your name and the underscore prefix.
Half the write-ups on the internet drop it and produce a name that resolves to nothing.
The contents
One TXT record holding a bitcoin: URI. The address part can be empty when a
query parameter carries the instruction, which is exactly the case for a silent payment.
# what this service publishes for you alice.user._bitcoin-payment.silentpayments.net. IN TXT "bitcoin:?sp=sp1qq…" # a real one, live today, carrying both a lightning offer and a silent payment address # dig +short TXT tips.user._bitcoin-payment.sethforprivacy.com "bitcoin:?lno=lno1zrxq8pjw7qjlm68mtp7e3yvxee4y5xrgjhhyf2fxhlphpckrvevh50u0qgve8erq…" "…vsl7ndy&sp=sp1qqvtg6a26w7ddww5t4t87sm729xzpqndcfnve0fu4tthp35gllm62kq…"
More than 255 bytes
A TXT record is a list of strings, each capped at 255 bytes. A wallet joins them in order with no separator between them. Note the split above lands mid token, right before &sp=.
Never across records
Joining strings inside one record is required. Joining across two records is forbidden, because resolvers return them in whatever order they like and you would get a different URI depending on who answered.
Two is a hard failure
Other TXT records at the same name are ignored. But if two of them start with bitcoin:, a wallet must refuse the whole name. Not pick the first. Refuse. That is why this service will not create a second record over an existing one.
§ 02 · The chain of trust
Seven links, one anchor, about three kilobytes
DNS on its own is a plaintext string from a stranger over an unauthenticated channel. Anyone on the path, a cafe router, a hotel captive portal, a compromised home gateway, could swap the address and the money would simply be gone. DNSSEC turns that into one signature chain, checked against one key you already have.
dig DS silentpayments.net and you will get key tag 2371, algorithm 13,
digest type 2. Every other link in the chain is equally checkable from your own machine.
Live The root key changes on 11 October 2026
The root zone currently signs with KSK-2017, key tag 20326. KSK-2024, key tag 38696, is already published and takes over as the active signing key on 11 October 2026. Any wallet or library that hardcodes only the old anchor stops validating DNS on that day. If you are building on this, check that 38696 is in your trust anchor list now rather than in October.
§ 03 · The distinction that matters
“My resolver says it is fine” is not a proof
Hearsay Trusting the AD bit
You ask a public resolver, it returns a flag saying the answer was authentic, and you believe it. That flag is one bit of somebody else’s opinion, carried over plain UDP with a sixteen bit transaction ID.
What it leaves wide open:
- An on-path attacker forges the reply and sets the bit
- A hostile or legally compelled resolver simply answers differently
- Home routers and corporate DNS forward rather than validate, and pass through a bit they never earned
- Whoever controls DHCP controls which resolver you asked
- A stripped signature looks identical to a domain that was never signed, so an attacker can force a downgrade
Proof Validating it yourself
You fetch the keys, signatures and denials yourself and check them against the root anchor built into your software. Every intermediary collapses into dumb transport.
They can still refuse to answer you. They cannot lie to you, because a corrupted answer becomes an unambiguous signature failure rather than a wrong payment. And what you end up holding is transferable: you can hand it to a device that has no network at all.
BIP 353 is unusually direct about this. “Clients resolving Bitcoin payment instructions MUST NOT trust a remote resolver to validate DNSSEC records on their behalf.”
The same attacker, the same tampered answer, two different outcomes. Nothing in this picture requires the attacker to be sophisticated: a hotel captive portal, a rogue wireless access point or whoever hands out your DHCP settings is enough.
This is not theoretical, and one wallet got caught
Zeus resolved payment names for roughly twenty five months while reading the first answer from a public resolver and never checking whether it was signed. The fix landed on 13 August 2026 and shipped in version 13.2.0 on 22 August 2026, two days before this page was written. The commit message is the clearest statement of the problem anyone has published: without validation, “a forged, poisoned, or hijacked DNS response could silently redirect the payment to an attacker’s offer.”
Of the wallets that resolve payment names today, Cake Wallet is the one doing real client-side proof validation. Phoenix and Zeus both still lean on a remote resolver’s verdict. When you evaluate a wallet, the question is not “does it support BIP 353”, it is “does it validate”.
There is a practical reason so many implementations take the shortcut. Ask your operating system for a signed answer and it will very often refuse. On a stock Ubuntu server, the built-in stub resolver fails a payment name lookup three different ways at once: it errors on the root key query, it strips signatures out of the answer, and it returns success with no authenticity flag, so a wallet trusting that flag would treat a perfectly signed name as unsigned. On iOS and Android there is no supported way to ask for the signature records at all. Every serious implementation therefore opens its own connection on port 443 and does the work itself.
§ 04 · The proof travels
The feature that makes this different in kind
Every naming scheme before this one required the device showing you the name to be online and to trust something. This one does not.
The signature chain is packaged as a flat sequence of DNS records with no name compression, which means each record is self contained and the whole blob can be verified with no network, no surrounding DNS message and no state. It rides along inside the unsigned transaction, in a field defined by BIP 353 itself:
PSBT_OUT_DNSSEC_PROOF = 0x35
<1-byte length><the name, without the ₿>
<the RFC 9102 chain>
So an airgapped signing device with one hardcoded key, no clock beyond an hour of slack, and no connection to anything can display ₿alice@silentpayments.net on its screen instead of a taproot blob, and mean it.
The format is borrowed from RFC 9102, an experimental standard written in 2021 for stapling proofs into TLS handshakes. It essentially never deployed for that. Bitcoin picked up the part that was useful and dropped the rest.
Measured proof sizes
- matt@mattcorallo.com
- 3,104 bytes
- test@twelve.cash
- 3,331 bytes
- a test name with a cross-domain alias
- 5,607 bytes
- tips@sethforprivacy.com
- 5,497 bytes
Roughly three kilobytes for a simple name, five and a half for one carrying a lightning offer as well. Not tens of kilobytes. Small enough for a QR code sequence, which is the entire reason the format was chosen.
And yet
Not one hardware wallet has shipped it. Matt Corallo offered a thousand dollars in July 2025 to the first one that did, payable only to a payment name. Thirteen months later that bounty is unclaimed.
§ 05 · Honesty
Who could redirect your money, and have it validate perfectly
A signature proves who published a record. It says nothing about whether they should have. Here is the complete list of parties above you, ours included.
| Party | What they could do |
|---|---|
| Us, the domain operator | Total. It is our zone. This is the one you are trusting, and the reason for the change log |
| Cloudflare, our DNS host | Total. They hold the signing keys and sign on our behalf |
| Our registrar | Change the name servers or the delegation record, and point the name at a different signed zone |
| The .net registry | Change the delegation record in the parent. Same result |
| ICANN and the root operators | Change the delegation for the whole top level domain |
| Any government able to compel any of the above | Whatever that party can do |
That is the same trust set as a normal web certificate, minus the roughly one hundred and fifty certificate authorities any one of which can currently issue a certificate for any name on earth. BIP 353 narrows the set. It does not empty it, and the spec does not pretend otherwise: it openly concedes that blockchain based naming systems have better censorship resistance, and picks ordinary DNS because those systems have no short proofs, usually reintroduce a trusted resolver, and have no adoption outside their own silos.
There is one more thing the spec is careful about, and it is worth quoting because it runs against the sales pitch: “Bitcoin wallets MUST NOT prefer to use DNS-based resolving when methods with explicit public keys or addresses are available.” A name is a convenience for a first contact. If you already have the address, use the address.
The strongest argument against this whole approach, stated fairly
Coinkite, who make the Coldcard, rejected a community contribution adding payment name support on principle, and their reasoning is worth reading rather than dismissing: DNS is a permissioned, censorable namespace whose trust chain terminates at ICANN, and they would rather spend firmware effort on protocols that do not introduce a new trusted third party. They pointed the contributor at silent payments instead.
We think they are right about the trust and wrong about the tradeoff, because a private payment system nobody can use is not a private payment system. But we are not going to pretend the objection is weak. If you agree with them, use the 116 character address directly and lose nothing except convenience.
§ 06 · Reality check
Two years on, this is a wallet developer standard, not a market
Who publishes names
twelve.cash, run by ATL BitLab. ACINQ, for Phoenix users. Breez, on breez.fun. A handful of self hosters. And this site. That is close to the whole list.
Who can pay one
Sparrow since October 2025, Cake Wallet since February 2025, Phoenix and Zeus since mid 2024, Strike, Breez, and anything built on Core Lightning 25.02 or LDK 0.1.
Who does not
No exchange. Not one. We checked River, Kraken, Coinbase, Strike, Cash App, Swan and Bitfinex by DNS: none of them publish anything. No hardware wallet. BTCPay Server has no support, no plugin and no open work.
A claim you will see repeated: that Coinbase supports payment names through
cb.id. It does not. That is Ethereum Name Service, a completely different
system, and coinbase.com is not even DNSSEC signed, so it could not publish a valid record
today if it wanted to. We checked rather than repeated.
Sources
- BIP 353, the specification
- BIP 321, the URI format it carries
- RFC 9102, the proof format
- dnssec-prover, the reference validator
- satsto.me, a name checker that validates locally
- twelve.cash
- IANA root trust anchors
- RFC 4035, and why the AD bit is not a proof
- Zeus pull request 4361, the validation fix
- SeedSigner pull request 798
- Coinkite’s refusal, in full
- The unclaimed hardware wallet bounty