BIP 353: Bitcoin Finally Has Human-Readable Payment Addresses. Here Is Why It Matters for Africa.
Sharing a Bitcoin address has always been an awkward experience. Specifically, you either read out a 42-character string of random letters and numbers, show a QR code and hope the camera focuses, or paste something into a chat and pray nothing gets corrupted in transit.
BIP 353 fixes that. Furthermore, it does it in a way that is open, self-sovereign, and directly relevant to how Bitcoin is used across Africa today.
What BIP 353 actually is
BIP 353 defines human-readable Bitcoin payment instructions that live in DNS. A recipient publishes a DNS TXT record at a specific subdomain that contains a BIP 21 URI — an on-chain address, a BOLT 12 offer, a Lightning address, or any combination of those. A sender types a name like ₿megasley@bitcoin.africa, the wallet fetches the record over DNSSEC, and reads off the payment methods the recipient supports. OpenSats
In plain language: your Bitcoin payment address becomes something that looks like an email address. Specifically, instead of sharing bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4, you share ₿yourname@yourdomain.com. The wallet resolves the name automatically. The user just types it and pays.
BIP 353 was authored by Matt Corallo and Bastien Teinturier and is now marked as complete. Furthermore, it is already being used in production by real wallets with real users. Bitcoin Wiki
How the resolution works
The mechanics are straightforward, though the security design is careful. Payment instructions are indexed by both a user and a domain. Instructions for a given user and domain are stored at user.user._bitcoin-payment.domain in a single TXT record. All payment instructions must be DNSSEC-signed. GitHub
DNSSEC is the security layer that prevents anyone from tampering with the DNS record between the server and your wallet. Specifically, it uses cryptographic signatures to verify that the payment instructions you receive are exactly what the recipient published. Therefore, you are not just trusting a domain name. You are verifying a cryptographic proof.
The wallet does all of this automatically. The goal is to make Bitcoin payments significantly more user-friendly while maintaining strong security guarantees through DNSSEC and avoiding privacy pitfalls of other approaches. GitHub
Notably, Bitcoin wallets must not prefer DNS-based resolving when methods with explicit public keys or addresses are available. In other words, if a standard Bitcoin address or direct URI is available or would suffice, wallets must prefer that instead. Therefore, BIP 353 is an enhancement, not a replacement for the base layer. It sits on top, adding convenience without removing any existing capability. GitHub
What you can pay to
BIP 353 is payment-method agnostic. Specifically, the TXT record can contain any combination of the following:
- An on-chain Bitcoin address for base layer transactions
- A BOLT 12 offer for reusable, privacy-preserving Lightning payments
- A Lightning address for BOLT 11-compatible wallets
- Any combination of the above in a single BIP 21 URI
That flexibility matters. It means a recipient can expose multiple payment rails through a single human-readable name. Furthermore, the sender’s wallet picks the best option automatically based on what both sides support. Therefore, the user experience is identical regardless of which payment method is used under the hood.
Which wallets already support it
Zeus wallet supports paying to hybrid Lightning addresses using BIP 353 combined with BOLT 12 and LNURL-pay. Furthermore, Zeus v0.9.2 added enhanced BIP 353 support including on-chain addresses and BOLT 12 offers encoded in BIP 21 URIs.
Twelve Cash is an implementation of human-readable payments using BIP 353. It includes an API to create usernames in Lightning apps and a website for creating and validating addresses. Therefore, developers can already integrate BIP 353 resolution into their own apps using existing tools and services. Bolt12
Phoenix, Alby, and several other wallets are also in various stages of BIP 353 integration. The standard is young but moving fast.
Why this matters specifically in Africa
The African Bitcoin ecosystem has made extraordinary progress in the past two years. Circular economies are running in Kibera. MoneyBadger processes Bitcoin payments at hundreds of thousands of South African merchant locations. Tando has made 40 million M-Pesa phone numbers Lightning-addressable. Africa Free Routing has trained 200 developers across eight cities in 2026 alone.
However, one friction point remains persistent across all of these use cases: sharing payment information. Specifically, QR codes require a camera and decent lighting. Long addresses require careful copying. Lightning invoices expire. All of these create moments where a payment fails not because Bitcoin does not work, but because the human interface broke down.
BIP 353 directly addresses that friction. Consider what it enables in the African context:
For circular economy merchants, a market vendor in Kibera could share a name like ₿mama.wanjiru@kibera.btc instead of displaying a QR code. Any customer with a BIP 353-compatible wallet types the name and pays. No camera needed. No expiring invoice. No copy-paste error.
For bootcamp graduates, Africa Free Routing could give every graduate a payment name under its domain. Specifically, a developer who completed the Kisumu bootcamp could receive payments at ₿firstname@bitcoin.africa for life, attached to whatever payment method they use at any given time. The name stays the same even if the underlying address or Lightning node changes.
For remittances, a Zambian worker in Kenya could share a single name with family back home. Furthermore, that name works whether the recipient is using Lightning, on-chain, or any future payment rail that BIP 353 adds support for. The sender does not need to know which layer is being used.
For businesses, companies integrating Lightning payments through tools like Wavelength or BTCPay Server could expose a single BIP 353 name per product or service. Therefore, payment flows become as simple as any other online transaction.
The domain ownership model is self-sovereign
One of the most important aspects of BIP 353 is that it does not require a central registry or a trusted third party. Specifically, anyone who controls a domain can publish BIP 353 payment instructions for any name under that domain.
That means no company owns the namespace. No platform can revoke your payment name. No custodian holds your payment instructions. You publish the record to your own DNS. You update it whenever you want. You delete it if you choose. The whole system is as decentralised as the domain name system itself.
BIP 353 leverages existing DNS infrastructure, specifically DNSSEC-secured records, as a globally deployed naming and authentication system for Bitcoin payment instructions. Therefore, the infrastructure already exists globally, including in Africa. Any organisation with a domain — a school, a church, a community cooperative, a developer collective — can start issuing human-readable Bitcoin payment names to its members immediately.
The connection to BOLT 12
BIP 353 and BOLT 12 are natural partners. BOLT 12 is the Lightning Network’s offer format — a reusable, privacy-preserving way to receive Lightning payments that does not expire and does not require generating a new invoice for every transaction.
Together, they form a powerful combination. BOLT 12 provides a static, reusable payment destination. BIP 353 provides a human-readable name that points to it. As a result, a user can share a single name that resolves to a reusable Lightning offer, and anyone can pay them at any time without either party managing invoice generation.
Furthermore, because BOLT 12 offers are already reusable by design, the combination removes the last major usability gap in Lightning payments for everyday use. Specifically, merchants no longer need to generate new invoices per transaction, and customers no longer need to scan a new QR code each time.
The bigger picture
Bitcoin has always been technically sound. However, technical soundness has never been the adoption bottleneck. The bottleneck has always been user experience.
BIP 353 is one of the most important UX improvements Bitcoin has received in years. Specifically, it takes a process that required careful copying, QR scanning, or technical knowledge and reduces it to typing a name. That is the same shift that email made from IP addresses, and that phone contacts made from phone numbers.
In Africa, where Bitcoin is increasingly used as everyday money rather than a speculative asset, that kind of friction reduction compounds quickly. Every step removed from the payment process is one more reason for a merchant to accept it, one fewer reason for a customer to hesitate, and one more way that Bitcoin behaves like the money it was always designed to be.
BIP 353 is live. The wallets are shipping. The infrastructure exists. The only thing left is for African Bitcoin developers, merchants, and communities to start using it.
₿yourname@yourdomain. That is all it takes.
Sources
- BIP 353 Specification — https://bips.dev/353/
- Bitcoin Wiki — BIP 0353 — https://en.bitcoin.it/wiki/BIP_0353
- OpenSats — BIP 353 Topic — https://opensats.org/topics/bip-353
- Zeus Wallet — BIP 353 Support — https://zeusln.com/wallet
- Zeus v0.9.2 Release — No BS Bitcoin — https://www.nobsbitcoin.com/zeus-v0-9-2/
- Twelve Cash — BIP 353 Implementation — https://bolt12.org/
- SeedSigner and BIP 353 — http://alvroble.com/posts/2025-10-02/
- GitHub — BIP 353 PR — https://github.com/bitcoin/bips/pull/1551
