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
• Summary: BIP 353 is best understood as DNSSEC-backed payment-instruction infrastructure rather than as a simple naming convention, wallet contact list, or Lightning Address clone. Its canonical BIP defines a standard way to encode bitcoin: / BIP 21 payment URIs in DNS TXT records for user@domain-style names, requires local DNSSEC validation to the root, specifies display and caching rules, and explicitly supports richer payloads such as BOLT 12 offers. The important categorization clue is that BIP 353 standardizes the namespace-resolution and proof layer above any specific payment rail: it tells wallets how to map a human-readable identifier into verifiable payment instructions, not how to settle the payment 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 and open-payments

• Last reviewed: 2026-06-02 UTC