BIP-353 (DNS Payment Instructions)

What Is BIP-353?

BIP-353 (DNS Payment Instructions) is a Bitcoin standard that enables human-readable payment identifiers by storing payment instructions in DNS records. Instead of sharing a long Bitcoin address or scanning a QR code, a user can simply publish their payment details at a DNS name and tell others to pay "user@domain.com." The sender's wallet resolves that name through DNS, retrieves the payment instructions, and initiates the payment automatically.

Authored by Matt Corallo and Bastien Teinturier, BIP-353 was merged into the Bitcoin Improvement Proposals repository in June 2024. It addresses a long-standing usability problem: Bitcoin addresses and Lightning invoices are complex strings of characters that are nearly impossible to communicate verbally or remember. By leveraging DNS, the same infrastructure that maps domain names to IP addresses, BIP-353 creates a universal naming layer for Bitcoin payments.

The standard is protocol-agnostic. A single BIP-353 identifier can resolve to a BOLT-12 offer for Lightning payments, an on-chain address, a silent payment address, or any combination of payment methods. This flexibility means users only need one identifier regardless of how the sender chooses to pay.

How It Works

BIP-353 defines a specific DNS record format that wallets query to retrieve payment instructions. The process involves three components: a naming convention, a DNS TXT record containing a BIP-21 URI, and mandatory DNSSEC validation.

DNS Name Format

When a user wants to pay "alice@example.com," the wallet constructs a DNS query for:

alice.user._bitcoin-payment.example.com  TXT

The pattern is <user>.user._bitcoin-payment.<domain>. The _bitcoin-payment prefix follows DNS conventions for service discovery, and the user label separates human identifiers from other potential uses of the _bitcoin-payment namespace.

For display purposes, the standard recommends prefixing human-readable names with the Bitcoin symbol: ₿alice@example.com. This visually distinguishes payment addresses from email addresses.

TXT Record Contents

The DNS TXT record contains a BIP-21 URI specifying one or more payment methods. A typical record pointing to a BOLT-12 offer looks like:

bitcoin:?lno=lno1qsgr30k45jhvkfqx...

The URI can include multiple payment options simultaneously. For example, an on-chain fallback alongside a BOLT-12 offer:

bitcoin:bc1qexampleaddress?lno=lno1qsgr30k45...

Because DNS TXT records limit individual character-strings to 255 bytes, longer URIs (common with BOLT-12 offers) are split across multiple character-strings within a single TXT resource record. Clients concatenate them in order without separators to reconstruct the full URI.

Wildcard Records and Onion Message Lookup

Custodial services that manage many users can publish a wildcard DNS record at *.user._bitcoin-payment.<domain> instead of individual records. This wildcard record uses a special omlookup parameter containing a blinded path:

bitcoin:?omlookup=<hex_encoded_blinded_path>

When a wallet encounters this parameter, it sends a Lightning onion message through the blinded path to request a custom offer for the specific user. This enables providers to serve millions of users with a single DNS record while still generating unique payment instructions per request.

DNSSEC Validation

DNSSEC validation is mandatory, not optional. Without it, a man-in-the-middle attacker (such as a compromised DNS resolver or malicious ISP) could substitute payment instructions with their own address and steal funds. BIP-353 requires:

• Full DNSSEC signature validation from the DNS root to the TXT record
• Rejection of signatures using SHA-1 or RSA keys shorter than 1024 bits
• Independent validation by the client rather than trusting a remote resolver
• Validation of all CNAME and DNAME records in the resolution chain

Clients may also accept RFC 9102-formatted DNSSEC proofs from external devices, which allows hardware wallets to verify payment instructions through a companion application without performing DNS resolution themselves.

BIP-353 vs. Lightning Address

Before BIP-353, the most widely adopted human-readable payment solution was the Lightning Address, which uses the LNURL protocol to resolve names via HTTPS requests. While both solve the same usability problem, their architectures differ significantly:

The most significant advantage of BIP-353 is sender privacy. With a Lightning Address, every payment request goes directly to the recipient's web server, which can log the sender's IP address, request timestamps, and payment frequency. With BIP-353, DNS queries are proxied through recursive resolvers, and when combined with BOLT-12 offers, the recipient's infrastructure never learns who is paying them. For a deeper comparison of Lightning invoice formats, see the BOLT-11 vs. BOLT-12 research article.

Relationship to BOLT-12

BIP-353 and BOLT-12 are designed to work together. BOLT-12 provides static, reusable payment offers that support payer and payee privacy through onion message negotiation. BIP-353 provides the human-readable naming layer that maps identifiers to those offers via DNS.

Together they eliminate the need for HTTP servers entirely: DNS resolves the human-readable name to a BOLT-12 offer, and Lightning's native onion message protocol handles the private invoice negotiation. This is a complete departure from the LNURL model, where an HTTP server must be online to generate fresh invoices for each payment. For more on how BOLT-12 adoption is progressing, see the BOLT-12 offers explained research article.

Use Cases

Personal Payment Identifiers

Individuals can publish a BIP-353 record at their personal domain, creating a permanent, memorable payment address. A freelancer, content creator, or merchant can share a single identifier like ₿tips@example.com that works for both on-chain and Lightning payments without maintaining any server infrastructure.

Business and Merchant Payments

Businesses can set up payment identifiers for departments or purposes: ₿sales@company.com, ₿support@company.com. Because BIP-353 supports multiple payment methods in a single record, the sender's wallet can choose the optimal payment rail: an instant BOLT-12 payment for small amounts or an on-chain transaction for larger settlements.

Custodial Services and Exchanges

Exchanges and wallets serving millions of users can deploy a single wildcard DNS record with the omlookup parameter. When a sender pays ₿username@exchange.com, the wallet resolves the wildcard record and uses Lightning onion messages to request a unique offer for that specific user. This scales to any number of users without individual DNS records.

Cross-Protocol Interoperability

Because BIP-353 is built on the BIP-21 URI scheme, it naturally supports new payment protocols as they emerge. A record can include parameters for silent payments, Ark, or any future Bitcoin payment method. The sender's wallet selects the best available option, and the recipient does not need to update their identifier when new protocols launch.

Privacy Considerations

BIP-353 improves sender privacy compared to LNURL-based approaches, but it does not eliminate all privacy concerns:

• DNS resolvers (such as 1.1.1.1, 8.8.8.8, or ISP-provided resolvers) can observe which payment names are being looked up, even though they cannot see the payment details themselves
• DNSSEC authenticates DNS responses but does not encrypt queries: an observer on the network path can see what names are being resolved
• For maximum privacy, wallets should resolve DNS queries over Tor or use BLIP-32, a protocol for performing BIP-353 resolution entirely over Lightning's native onion message network
• On-chain addresses published in DNS records should be rotated after each confirmed transaction to avoid address reuse: short DNS TTLs help but limit rotation to roughly one address per block

The combination of BIP-353, BOLT-12, and BLIP-32 enables a fully private payment flow: the name resolution happens over onion messages, the invoice negotiation happens over onion messages, and the payment itself is routed through the Lightning Network. No HTTP server is involved at any stage.

Setting Up a BIP-353 Record

Publishing a BIP-353 payment instruction requires two things: a domain name with DNSSEC enabled and a DNS TXT record at the correct subdomain. Most domain registrars support DNSSEC signing, and DNS hosting providers like Cloudflare handle it automatically.

# DNS TXT record for alice@example.com
# Name:
alice.user._bitcoin-payment.example.com

# Type:
TXT

# Value (BOLT-12 offer):
"bitcoin:?lno=lno1qsgr30k45jhvkfqx..."

# Ensure DNSSEC is enabled for example.com

Services like Twelve Cash provide simplified interfaces for creating BIP-353 records without manually configuring DNS, making the standard accessible to users who are not comfortable managing DNS zones.

Current Adoption

As of 2026, BIP-353 support is growing across the Bitcoin ecosystem. Phoenix Wallet (by ACINQ), Zeus, BitBanana, and Misty Breez support sending to BIP-353 addresses. On the development side, the Lightning Dev Kit (LDK) added BIP-353 support in version 0.1 with a dedicated API for paying BOLT-12 offers resolved from human-readable names. The Breez SDK also supports paying to BIP-353 addresses. For wallet developers evaluating implementation options, the wallet SDK comparison research article covers the relevant libraries.

Risks and Considerations

DNSSEC Deployment Gaps

DNSSEC adoption across the global DNS infrastructure remains incomplete. While most major registrars support DNSSEC signing, not all domain owners have it enabled. A BIP-353 wallet must refuse to resolve records from unsigned zones, which means payments will fail if the recipient has not configured DNSSEC properly. This creates a usability hurdle during the adoption phase.

DNS Infrastructure Trust

Although DNSSEC prevents tampering with DNS responses, the DNS infrastructure itself introduces trust assumptions. Domain registrars can modify DNS records, and DNS hosting providers have administrative access to zones. A compromised registrar account could redirect payment instructions to an attacker's address. This risk is analogous to the TLS certificate authority model that Lightning Address relies on, but the attack surface differs.

On-Chain Address Staleness

If a BIP-353 record contains an on-chain Bitcoin address, that address can go stale. DNS caching means multiple senders might resolve the same address before the recipient can rotate it, leading to address reuse and reduced privacy. The specification recommends using silent payments or BOLT-12 offers instead of static on-chain addresses to avoid this problem entirely.

Centralization Pressure

The omlookup wildcard mechanism, while technically elegant, may concentrate naming authority at large custodial providers. If most users get their BIP-353 identifiers from a few major exchanges or wallet services, the naming layer becomes centralized even though DNS itself is distributed. This mirrors the email ecosystem where a handful of providers control most addresses.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.