bip-353

BIP 353 (DNS Payment Instructions)

• Name: BIP 353 (DNS Payment Instructions)
• URL: https://bips.dev/353/
• Category: human-readable Bitcoin payment namespace / DNSSEC-backed payment-instruction standard / wallet interoperability infrastructure
• Tags: bitcoin-ecosystem bitcoin-standards
• Summary: BIP 353 is DNSSEC-backed payment-instruction plumbing, not just another wallet alias. It maps user@domain names to verifiable bitcoin: / BIP 21 payloads and can carry richer objects like BOLT 12 offers. The point is human-readable resolution above the rail, not the rail itself.
• What it does:
  • Defines a DNS-based format for publishing Bitcoin payment instructions at user.user._bitcoin-payment.domain as DNS TXT records
  • Standardizes how wallets reconstruct a bitcoin: URI from TXT record character strings and reject ambiguous multi-record results
  • Requires clients to validate DNSSEC signatures to the DNS root instead of trusting a remote resolver’s validation result
  • Supports payment instructions that contain onchain addresses, empty URI paths, or Lightning BOLT 12 offers carried inside BIP 21 parameters
  • Specifies display conventions such as showing verified names as ₿user@domain and copying the underlying URI instead of the alias when possible
  • Defines PSBT fields for carrying DNSSEC proofs so external signers or hardware wallets can verify the human-readable recipient offline
• Key claims:
  • The canonical BIP says it proposes “a standard format for encoding BIP 21 URI schemes in DNS TXT records,” which makes the project much broader than a Lightning-only alias system
  • The specification says wallets MUST store instructions for a given user and domain at user.user._bitcoin-payment.domain in a single TXT RR and MUST ignore TXT records at the same label that do not begin with bitcoin:
  • The BIP says clients MUST fully validate DNSSEC signatures leading to the DNS root and MUST NOT trust a remote resolver to validate DNSSEC records on their behalf, which is the clearest signal that BIP 353 is a proof-oriented interoperability layer rather than a convenience alias
  • The display section says wallets SHOULD render verified names with a ₿ prefix, i.e. ₿user@domain, and SHOULD copy the underlying URI directly when users copy payment information
  • The examples and record rules explicitly contemplate Lightning BOLT 12 offers inside the resulting bitcoin: URI, which helps position BIP 353 as a multi-rail payment-instruction wrapper rather than only an onchain naming format
  • The address-reuse section says reusable onchain addresses should be rotated regularly and, where practical, payment instructions should avoid embedding a reusable onchain address at all
  • The backwards-compatibility section says this work is intended to extend and subsume the existing Lightning Address scheme, while recommending against indefinite HTTP fallback once DNS-based resolution is broadly deployed
  • The general-handling rules say wallets MUST NOT prefer DNS-based resolving when a direct address or direct BIP 21 URI is already available, which is an important nuance: BIP 353 is an interoperability layer for human-readable discovery, not a universal replacement for explicit payment instructions
• Whitepaper: No separate standalone BIP 353 whitepaper or litepaper surfaced in this pass. The canonical source of truth is the completed BIP itself plus its raw source and linked discussion thread; see ../../whitepapers/bip-353-primary-sources-2026-05-03.md.
• Sources:
  • https://bips.dev/353/
  • https://raw.githubusercontent.com/bitcoin/bips/master/bip-0353.mediawiki
  • https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki
  • https://groups.google.com/g/bitcoindev/c/uATaflkYglQ

Internal linkages

• Naming-layer predecessor it is partly trying to replace inside Lightning UX: lnurl
• Reusable payment object it can carry once resolution succeeds: bolt-12
• Web-native naming cousin outside Bitcoin: payment-pointers

Control surface

• The leverage sits with the domain operator publishing the TXT record, the DNSSEC trust chain that makes the record believable, and the wallet policy that decides whether to validate, display, cache, or reject the resolved instruction.

• Useful naming and delivery plumbing, still just plumbing above the actual payment rail.

• Last reviewed: 2026-06-11 UTC