BIP-353 vs LNURL: Human-Readable Bitcoin Payment Addresses

BIP-353 vs LNURL vs Lightning Address

Sending bitcoin to a long string of random characters is a terrible user experience. Three protocols attempt to solve this by enabling human-readable payment addresses: BIP-353 (DNS-based payment instructions), LNURL (HTTP-based Lightning URL protocol), and Lightning Address (a user@domain format built on top of LNURL-pay). Each takes a fundamentally different approach to resolving a readable name into payment information, and those differences affect trust, privacy, server requirements, and wallet compatibility.

The following table summarizes the core differences across all three protocols. Each row is explored in detail throughout this guide.

How Each Protocol Works

BIP-353: DNS Payment Instructions

BIP-353 stores payment information directly in DNS. The recipient publishes a TXT record at username.user._bitcoin-payment.example.com containing a BIP 21 URI. That URI can include an on-chain address, a BOLT 12 offer, a Silent Payment address, or any combination. The sender's wallet queries the DNS record, validates the full DNSSEC signature chain up to the DNS root, and extracts the payment method it supports.

Because BIP-353 relies on DNS rather than HTTP, no web server needs to be online to receive payments. The DNS record is static and can point to reusable payment methods like BOLT 12 offers, which avoids address reuse concerns associated with publishing a single on-chain address. The BIP was authored by Matt Corallo and Bastien Teinturier and reached "Complete" status in the BIP process.

LNURL-pay and Lightning Address

LNURL is a family of HTTP-based protocols defined across 21 numbered specifications called LUDs (LNURL Documents). LNURL-pay (LUD-06) creates static, reusable payment links: the payer's wallet makes an HTTPS GET request to the recipient's server, receives payment parameters (min/max amount, metadata), then POSTs the amount to get back a fresh BOLT 11 invoice.

Lightning Address (LUD-16) is a thin layer on top of LNURL-pay. It translates a human-readable address like alice@example.com into the correct HTTPS URL for the LNURL-pay flow: https://example.com/.well-known/lnurlp/alice. The recipient's server must be online and reachable to generate an invoice for each incoming payment.

Trust Model and Custodial Risk

The trust model is the most consequential difference between these protocols. Every approach requires at least one intermediary to serve payment information, but the nature of that intermediary varies significantly.

With BIP-353, the intermediary is a DNS registrar. The registrar hosts the TXT record and signs it with DNSSEC. The registrar cannot move the recipient's funds: at worst it can prevent the record from being served, or return incorrect payment information. DNSSEC signatures make tampering detectable, and the recipient retains full custody of their keys.

With Lightning Address, the intermediary is typically a Lightning service provider that runs both the HTTPS endpoint and the Lightning node. When someone pays alice@walletservice.com, the server at walletservice.com generates the invoice and routes the payment through its node. In custodial setups, the provider holds the funds until the recipient withdraws. Even in non-custodial configurations, the server operator sees all payment request metadata and must stay online to generate invoices.

The always-online requirement creates a practical problem for self-custodial mobile users. A phone wallet cannot reliably serve HTTPS requests when the app is backgrounded or the device is offline. The result: most Lightning Addresses are hosted by custodial providers, because they can maintain the always-on endpoint the protocol requires. Non-custodial alternatives exist (BTCPay Server, Alby Hub, LNbits) but require the user to manage their own server and domain.

Privacy Comparison

Both protocols leak metadata, but in different ways and to different parties.

When a sender resolves a Lightning Address, their wallet makes a direct HTTPS connection to the recipient's domain. The server operator learns the sender's IP address, the timing of the payment request, and any message attached via LUD-12. If the server is custodial, the operator also sees the payment amount and can correlate requests over time.

With BIP-353, the sender's wallet queries DNS. Standard DNS queries are visible to the user's DNS resolver and potentially to network observers, revealing that a payment lookup is happening for a specific name. However, the query goes to the DNS infrastructure rather than the recipient's server, so the recipient's hosting provider does not learn the sender's IP. When combined with DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), even the network observer angle is reduced.

The privacy story improves further when BIP-353 points to a BOLT 12 offer rather than a static on-chain address. BOLT 12 uses onion routing to fetch the invoice, hiding sender and receiver IP addresses from each other. By contrast, LNURL-pay always requires a direct HTTPS connection to the server.

Server Requirements and Offline Capability

For developers building payment flows, the operational difference is significant. BIP-353 lets a recipient set a DNS record once and receive payments indefinitely without maintaining infrastructure. LNURL and Lightning Address require a persistent server that responds to every incoming payment request in real time.

Wallet Support

LNURL and Lightning Address have a multi-year head start. LNURL-pay and LUD-16 Lightning Addresses are supported by the majority of Lightning wallets, including Phoenix, Zeus, Breez, Mutiny (now community-forked), BlueWallet, Wallet of Satoshi, Alby, and dozens of others. This broad compatibility makes Lightning Address the default for user-friendly Lightning payments today.

BIP-353 adoption is growing but still in earlier stages. As of late 2025, confirmed implementations include Phoenix (v2.3.3+), Zeus (v0.9.2+), Cake Wallet, Sparrow, and Core Lightning. LDK and Breez SDK have added support, enabling any wallet built on those toolkits to integrate BIP-353 resolution. A proof-of-concept pull request for Bitcoin Core (PR #33069) has been opened but not yet merged.

Nostr Wallet Connect as an Alternative

Nostr Wallet Connect (NWC), defined in NIP-47, takes a different approach to the payment address problem. Instead of resolving a name to payment information, NWC lets any application request a payment from the user's wallet through encrypted messages relayed over Nostr. The user pairs an app to their wallet once, granting a limited budget or specific permissions, and the wallet executes payments on behalf of the app.

NWC does not replace BIP-353 or LNURL directly. It solves a related but different problem: giving apps the ability to trigger payments from a user-controlled wallet without the app holding funds. It is supported by Alby, Phoenix, Zeus, and LNbits, and used by Nostr clients like Damus, Amethyst, and Primal for one-tap zap payments. For a deeper look at how NWC works, see our Nostr Wallet Connect research article.

BIP-353 and BOLT 12: The Emerging Stack

BIP-353 and BOLT 12 offers are designed to work together. A BIP-353 DNS record typically contains a BIP 21 URI that includes a BOLT 12 offer. When a sender resolves the name, they get the offer and can pay using Lightning's native onion message protocol, with no HTTPS server involved at any point. BOLT 12 was officially merged into the Lightning specification in September 2024, and is supported by Core Lightning, LDK, and Eclair (which powers Phoenix).

This combination addresses the two main weaknesses of the LNURL approach: the HTTPS server dependency and the privacy cost of direct connections to the recipient's domain. With BIP-353 plus BOLT 12, the entire payment flow from name resolution to invoice retrieval to payment routing can happen without either party revealing their IP address to the other. For more details on how offers work, see our BOLT 12 Offers explainer.

How to Choose

If you need maximum wallet compatibility today: use a Lightning Address. It works with nearly every Lightning wallet and is the most recognized format among users.

If you prioritize privacy and self-sovereignty: use BIP-353 with a BOLT 12 offer. No server to maintain, better sender privacy, and no custodial dependency beyond your DNS registrar. The tradeoff is that fewer wallets support BIP-353 resolution today.

If you want both: BIP-353 supports including multiple payment methods in a single DNS record. You can publish a BOLT 12 offer alongside an LNURL fallback or an on-chain address, letting each sender's wallet use whichever method it supports.

If you are building a payments product on Bitcoin: consider supporting BIP-353 resolution alongside LNURL. The Bitcoin payment protocol comparison tool covers the full landscape of payment standards. Platforms like Spark are building Bitcoin layer-2 infrastructure that supports modern payment standards, making it easier to offer human-readable addresses without the custodial tradeoffs of traditional Lightning Address hosting.

Workarounds for Lightning Address Custody

Several projects have attempted to solve the custodial problem inherent in Lightning Addresses without abandoning the format:

• Amboss Ghost Addresses route payments directly to the user's own node via route hints, bypassing the need for a separate Lightning Address server. The node must still be reachable and have sufficient inbound capacity.
• Zaplocker provides a non-custodial address server that holds payments in a locked state until the recipient's wallet comes online to claim them.
• Fedimint-based approaches (as used by the former Mutiny Wallet) lock ecash tokens to the user's pubkey. The server holds the tokens, but only the user can unlock and spend them.
• Self-hosted setups using BTCPay Server, Alby Hub, or LNbits keep custody with the user but require running and maintaining server infrastructure.

These workarounds improve the trust model but add complexity. BIP-353 sidesteps the problem entirely by removing the server requirement from the address resolution layer. For more on how Lightning service providers handle these tradeoffs, see our Lightning DNS address adoption analysis.

Frequently Asked Questions

What is BIP-353 and how does it differ from a Lightning Address?

BIP-353 stores payment instructions in a DNSSEC-signed DNS TXT record, while a Lightning Address resolves over HTTPS to an LNURL-pay endpoint. The key difference: BIP-353 requires no web server and works with multiple payment rails (on-chain, BOLT 12, Silent Payments), while a Lightning Address requires an always-online server and only supports Lightning payments.

Is a Lightning Address custodial?

It depends on who operates the server. Most Lightning Addresses are custodial because the hosting provider runs the Lightning node that generates invoices and receives payments. Non-custodial setups are possible with self-hosted software like BTCPay Server or Alby Hub, but these require the user to maintain their own server infrastructure. BIP-353 avoids this problem by not requiring a server at all.

Can I use BIP-353 and Lightning Address at the same time?

Yes. A BIP-353 DNS record can contain a BIP 21 URI with multiple payment methods, including an LNURL fallback. Wallets that support BIP-353 will resolve via DNS, while older wallets can fall back to the LNURL endpoint. This lets recipients transition gradually without losing compatibility with existing wallets.

Which wallets support BIP-353?

As of late 2025, Phoenix (v2.3.3+), Zeus (v0.9.2+), Cake Wallet, Sparrow, and Core Lightning have confirmed BIP-353 support. LDK and Breez SDK also support resolution, enabling any wallet built on those frameworks to integrate it. Lightning Address support is far more widespread, with dozens of wallets supporting it.

What is the privacy difference between BIP-353 and LNURL?

When using LNURL or Lightning Address, the sender's wallet connects directly to the recipient's HTTPS server, exposing the sender's IP address and request timing. With BIP-353, the sender queries DNS infrastructure instead, so the recipient's hosting provider never sees the sender's IP. When BIP-353 is combined with BOLT 12 offers, the entire payment flow can use onion routing, hiding both parties' network identities.

What is Nostr Wallet Connect and how does it relate?

Nostr Wallet Connect (NWC) is a protocol defined in NIP-47 that lets applications trigger Lightning payments from a user-controlled wallet via encrypted Nostr relay messages. It solves a different problem than BIP-353 or LNURL: rather than resolving a payment address, NWC provides remote wallet control with permission budgets. It is commonly used for Nostr zap payments and streaming sats in podcasting apps.

Does BIP-353 work for on-chain Bitcoin payments?

Yes. Unlike LNURL, which only supports Lightning, BIP-353 can include any payment method in its BIP 21 URI: on-chain addresses, Silent Payment addresses, BOLT 12 offers, or combinations of all three. This makes it the only human-readable address protocol that works across all Bitcoin payment rails.

This tool is for informational purposes only and does not constitute financial advice. Protocol specifications, wallet support, and implementation details change frequently. Always verify current wallet compatibility and security properties before choosing a payment address protocol. Data is based on publicly available information as of late 2025.