BIP 353

BIP 353 defines human-readable Bitcoin payment instructions that live in DNS. A recipient publishes a DNS TXT record at name.user._bitcoin-payment.example.com 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 ₿name@example.com, the wallet fetches the TXT record over DNSSEC, and reads off the payment methods the recipient supports.

BIP 21 has since been superseded by BIP 321, which generalizes the URI format to support multiple payment methods in a single URI. BIP 353 still references BIP 21 directly, so wallets implementing BIP 353 today read the TXT record as a BIP 21 URI in practice.

DNSSEC matters because the sender does not want to trust the recipient's resolver. Every response is signed by the domain's DNSSEC key, so a middleman on an untrusted network cannot rewrite the payment address. Wallets that have announced support include LDK Node and Blink, along with research implementations driven by Matt Corallo.

The goal is a single identifier that looks like email and works across payment rails. The recipient can change or add payment methods without each sender's wallet hard-coding which one to use.

References

• BIP 353
• BIP 321
• BIP 21
• bips.dev: BIP 353 rendered