BIP-353: A More Reliable, Protocol-Level Way to Share Bitcoin Payment Details
Written by Chuks Agbakuru
There’s a problem that’s been annoying bitcoin users for years, and it’s almost embarrassingly basic: receiving money shouldn’t feel this clunky. You end up copying and pasting a long string of random characters, then crossing your fingers that nothing gets messed up. It works, but it’s a terrible user experience — basically just a workaround we’ve learned to live with.
Lightning Addresses (you@yourdomain.com) were a real step forward. They finally gave us something that feels like an email address. But there’s a catch most people don’t talk about enough: they depend on a live web server. If the server goes down, payments stop. If the TLS certificate expires, it breaks. And if the operator feels like it, they can see who’s paying you or even change the details behind the scenes. On the surface it looks simple, but underneath it’s just another service you have to babysit.
BIP-353 tries something smarter. Instead of piling on more infrastructure that needs constant care, it strips one layer away and leans on something the internet has relied on for decades: plain old DNS.
Using DNS for Payment Instructions
Say someone wants to pay ₿satoshi@nakamoto.com. Their wallet doesn’t hit a web server with an HTTP request. It just does a normal DNS lookup on this subdomain:
satoshi.user._bitcoin-payment.nakamoto.com
What comes back is a TXT record with a BIP-321 bitcoin: URI inside. That one URI can carry several payment options at once:
- A BOLT 12 Lightning Offer
- A Silent Payment address (BIP-352)
- A regular on-chain fallback address
The wallet then picks the best one available. What used to need several systems talking to each other now collapses into one clean, verifiable lookup.
How Resolution Works
Privacy Benefits Without Sacrificing Simplicity
Static on-chain addresses have always been a privacy headache. Publishing one and every payment you receive becomes publicly linkable forever. Silent Payments (BIP-352) fixes this nicely: you share some cryptographic material once, and every sender can independently derive a fresh, one-time address just for their payment.
Combine that with BIP-353 and you get the best of both worlds — a simple, reusable name on the surface, but proper privacy underneath.
Addressing DNS Security Concerns
Plain DNS can be tampered with. BIP-353 fixes that by making DNSSEC validation mandatory. Your wallet checks the full cryptographic chain of trust instead of blindly trusting whatever comes back.
DNSSEC Chain of Trust
DNSSEC can even prove that a record doesn’t exist, so your wallet knows for sure when something is missing — no blind trust required.
The Last-Mile Challenge (and Ongoing Solutions)
Here’s the practical catch: most phones and wallets don’t do DNSSEC validation themselves. They lean on upstream resolvers, often run by ISPs, which means your lookup can leak information.
bLIP-32 tries to solve this by letting wallets route the DNS query (plus the DNSSEC proof) privately over Lightning onion messages. The resolver node is just a courier — it doesn’t need to be trusted. The wallet still does all the verification locally.
Private DNS Resolution via Lightning (bLIP-32)
Setup Is Straightforward
Setting up your own BIP-353 address is refreshingly simple. You only need three things:
- A domain name you actually control
- DNSSEC turned on for the zone
- One TXT record at username.user._bitcoin-payment.yourdomain.com that holds the BIP-321 URI
No server to run. No certificates to renew. No uptime monitoring. As long as the domain stays registered and DNSSEC stays valid, the address just works. That gap between “keep a server alive” and “add one DNS record” is huge — especially when power or internet isn’t reliable.
Comparison: LNURL vs BIP-353
In short: LNURL feels like a web service you have to keep alive. BIP-353 feels more like an actual protocol.
Important Trade-offs
Human-readable names are convenient, sure, but if you start plastering them everywhere publicly, they can still become identity anchors. You’re also trusting your domain registrar and DNS provider to some degree. And let’s be real, adoption still depends heavily on wallets actually implementing this well. Sparrow has made solid progress, and LDK-based tools are moving forward, but we’re not at “works everywhere by default” yet.
Current Status (as of August 2026)
BIP-353 is marked Complete on bips.dev. There are solid Rust libraries (bitcoin-payment-instructions, bip353-rs), and we’re seeing integration work in LDK stacks plus send/receive support in wallets like Phoenix, CakeWallet and Sparrow. bLIP-32 is still active. Momentum is building, but it’s early days. We’re still dealing with the usual chicken-and-egg problem.
Why This Matters, Especially in Emerging Markets
If you’ve ever tried keeping a Lightning node or web server running reliably in Lagos, you know the pain. NEPA takes light, generators fail, the internet drops, and suddenly your payment address is dead. Hosting costs add up fast too.
BIP-353 changes the equation. Instead of fighting to keep a service online, you just set a static DNS record once. It’s a quiet but important shift: moving Bitcoin infrastructure away from fragile services and back toward solid, protocol-level primitives that are actually practical to run in the real world.
It won’t make payment addresses unbreakable, but it does remove one very common point of failure. For those of us building tools that need to work even when infrastructure is flaky, that’s a meaningful win.
References
- BIP-353 — DNS Payment Instructions for Bitcoin
- BIP-321 — URI Scheme for Bitcoin Payments
- BIP-352 — Silent Payments
- bLIP-32 — DNS Resolution over Lightning (Onion Messages)
- Lightning Network BOLT 12 Offers
- DNSSEC (RFC 4033)
- LDK Node PR #666 — Sending to BIP-353 HRNs
- LDK Node PR #630 — Resolving BIP-353 HRNs for others on the network
