bip-353-primary-sources-2026-05-03

BIP 353 (DNS Payment Instructions) primary sources — 2026-05-03

Project status in this pass

• No separate standalone BIP 353 whitepaper or litepaper surfaced.
• The clearest current source of truth is the completed BIP itself, its raw source in the bitcoin/bips repository, and the linked bitcoin-dev discussion thread.
• The materials consistently frame BIP 353 as a verifiable DNSSEC-backed standard for mapping human-readable identifiers to Bitcoin payment instructions, not as a wallet-specific alias feature.

Primary-source snapshots

1) Canonical BIP page

• URL: https://bips.dev/353/
• Key excerpt:
  • The BIP defines itself as “DNS Payment Instructions” and says it proposes a standard format for encoding BIP 21 URI schemes in DNS TXT records.
  • It explains the motivation in terms of human-readable payment destinations, DNSSEC-backed verification, and relatively private DNS resolution.
  • It positions the standard above particular payment rails by encoding general bitcoin: URIs rather than only one invoice format.

2) Raw specification in bitcoin/bips

• URL: https://raw.githubusercontent.com/bitcoin/bips/master/bip-0353.mediawiki
• Key excerpt:
  • The spec says payment instructions for a given user and domain are stored at user.user._bitcoin-payment.domain in a single TXT record.
  • It says clients must reconstruct the bitcoin: URI from the TXT record’s character strings, ignore non-bitcoin: TXT records at the same label, and reject ambiguous multi-record situations.
  • It also says clients must fully validate DNSSEC signatures to the DNS root and must not trust a remote resolver to do DNSSEC validation on their behalf.

3) Display, rotation, and proof sections in the raw specification

• URL: https://raw.githubusercontent.com/bitcoin/bips/master/bip-0353.mediawiki
• Key excerpt:
  • The display rules say wallets should render verified names as ₿user@domain and should copy the underlying URI instead of the alias when possible.
  • 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 PSBT section defines PSBT_OUT_DNSSEC_PROOF = 0x35, showing BIP 353 also contemplates hardware-wallet or external-signer verification flows.

4) Backwards-compatibility section in the raw specification

• URL: https://raw.githubusercontent.com/bitcoin/bips/master/bip-0353.mediawiki
• Key excerpt:
  • The BIP says it is intended to extend and subsume the existing Lightning Address scheme.
  • It allows wallets to fall back to Lightning Address logic when DNS resolution fails, but warns that indefinite fallback can leak sender IP information.
  • This is a strong clue that BIP 353 should be cataloged as payment-instruction interoperability infrastructure, not merely as an alternative naming convention.

5) Linked bitcoin-dev discussion

• URL: https://groups.google.com/g/bitcoindev/c/uATaflkYglQ
• Key excerpt:
  • The BIP metadata links a bitcoin-dev discussion titled “Mapping Human-Readable Names to Payment Instructions.”
  • Even without treating the list discussion as more authoritative than the merged BIP, its existence helps confirm that the standard’s design goal is broad Bitcoin payment-instruction mapping rather than a single wallet implementation detail.

Working conclusion

BIP 353 is best cataloged as DNSSEC-backed human-readable payment-instruction infrastructure. The deciding evidence in this pass was the combination of BIP 21-in-DNS encoding, strict client-side DNSSEC validation, the ₿user@domain display convention, support for richer payloads like BOLT 12 offers, and PSBT proof fields that let external signers verify the resolved recipient.