Bitcoin Payment Protocols Compared: BIP21, BOLT11, BOLT12, LNURL

Bitcoin Payment Protocol Overview

Bitcoin payments rely on several distinct protocols for requesting and routing funds. On-chain transactions use BIP21 URIs. Lightning invoices use BOLT11 encoding. Newer standards like BOLT12 offers and LNURL add reusability, privacy, and richer interaction models. Understanding the differences between these protocols is essential for wallet developers, merchants, and anyone building on Bitcoin's payment infrastructure.

The following table provides a high-level comparison across all major Bitcoin payment protocols. Each is explored in detail throughout this guide.

BIP21: On-Chain Bitcoin URIs

BIP21 defines the standard URI scheme for Bitcoin payments. A BIP21 URI encodes a Bitcoin address along with optional parameters like amount, label, and message. The format is straightforward: bitcoin:bc1q...?amount=0.001&label=Payment. Nearly every Bitcoin wallet supports BIP21, making it the most universally compatible payment request format.

BIP21 has been formally superseded by BIP 321, which modernizes the URI scheme for current address types (bech32, bech32m/Taproot), makes query parameters case-insensitive, and critically allows an empty address field. This enables URIs that contain only Lightning parameters, serving as the foundation for unified QR codes.

The main limitation of standalone BIP21 is that it targets on-chain transactions: relatively slow (10+ minute confirmation) and expensive during high-fee periods. Privacy is also limited because on-chain addresses are publicly visible, and address reuse creates linkability across transactions.

BOLT11: Lightning Invoices

BOLT11 is the original Lightning Network invoice format, defined in the BOLT specification. An invoice is a bech32-encoded string prefixed with lnbc (mainnet) that contains the payment hash, amount, description, expiry time, route hints, and the payee's node public key. The default expiry is 3,600 seconds (one hour), though this is configurable by the invoice creator.

BOLT11 invoices are single-use by design. Each invoice contains a unique payment hash tied to a preimage that the recipient reveals upon payment. Once paid, the invoice cannot be reused. Zero-amount invoices are supported, allowing the sender to choose how much to pay, which is useful for donations and tips.

The primary limitations of BOLT11 are: the recipient's node must be online to generate invoices, the recipient's node public key is embedded in the invoice (leaking identity), and there is no native support for recurring payments. Despite these constraints, BOLT11 remains the most widely supported Lightning payment format. Virtually every Lightning wallet and service supports it, making it the baseline for interoperability. For a hands-on look at invoice structure, try the Lightning invoice decoder.

BOLT12: Lightning Offers

BOLT12 was officially merged into the Lightning specification in September 2024, the first new BOLT added since 2017. It introduces "offers": reusable payment codes (prefixed with lno) that act as templates rather than one-time invoices. When a sender scans a BOLT12 offer, their wallet contacts the recipient's node via onion messages to fetch a fresh, single-use invoice on demand. The offer itself does not expire unless explicitly configured to.

BOLT12 addresses the key weaknesses of BOLT11. Reusability eliminates the need to generate a new invoice for every payment. Blinded paths hide the recipient's node identity from the sender, significantly improving privacy. Native recurring payment support enables subscriptions with defined payment schedules. Payer proofs provide cryptographic evidence that a specific sender made a payment.

A key architectural advantage is that BOLT12 operates entirely within the Lightning Network using onion messages. No HTTP server or external infrastructure is required. This makes it more censorship-resistant and simpler to deploy than LNURL. BOLT12 offers also produce smaller QR codes than BOLT11 invoices because of the TLV-encoded format.

Implementation support is growing: Core Lightning and Eclair have full BOLT12 support. LDK provides full offer creation and payment capabilities. LND does not yet have native BOLT12 support but can use LNDK, a sidecar tool built on LDK, as a workaround. For more on the specification details, see our research on BOLT12 offers explained.

LNURL: HTTP-Based Lightning Protocol

LNURL is a set of open protocol standards that add HTTP-based interaction to Lightning payments. A bech32-encoded URL (prefixed with lnurl1) is scanned by a wallet, which then makes HTTPS requests to a server to negotiate payment details. The server responds with JSON containing payment parameters or a fresh BOLT11 invoice.

The LNURL family includes several sub-protocols: LNURL-pay (sender scans a static QR, server returns a fresh invoice), LNURL-withdraw (user pulls funds from a service), LNURL-auth (passwordless login using wallet keys), and LNURL-channel (automated channel opening). Lightning Address builds on LNURL-pay to provide human-readable identifiers in the format user@domain.com, resolved via a well-known HTTPS endpoint.

The main tradeoff is that every LNURL interaction requires an HTTPS server. If the server goes offline, payments cannot be completed. The sender's wallet makes HTTP requests directly to the recipient's server, exposing the sender's IP address and allowing the server to log payment metadata. This is a significant privacy concern compared to BOLT12's onion-routed approach. Despite these drawbacks, LNURL has broad wallet support and was the first widely adopted solution for reusable Lightning payment codes.

Unified QR Codes

Unified QR codes encode both an on-chain Bitcoin address and Lightning payment instructions in a single BIP21 URI. Lightning-capable wallets extract the Lightning parameter and pay instantly, while on-chain-only wallets fall back to the Bitcoin address. This solves a practical UX problem: merchants and payment processors no longer need to ask customers which payment method they prefer.

The format uses BIP 321's extended parameter keys. For BOLT11: bitcoin:bc1q...?lightning=lnbc.... For BOLT12 offers: bitcoin:bc1q...?lno=lno1.... BIP 321 allows an empty address field, so a Lightning-only URI is valid: bitcoin:?lno=lno1.... BTCPay Server, Phoenix, BlueWallet, Breez, and Zeus all decode unified BIP21 URIs.

BIP 353 extends this further by defining DNS-based human-readable payment instructions. A recipient publishes a DNSSEC-signed TXT record at user._bitcoin-payment.domain.com containing a BIP21 URI with on-chain, BOLT12, or Silent Payment parameters. Unlike Lightning Address, BIP 353 does not require a web server: it uses DNS directly. Phoenix, BitBanana, and Twelve Cash already support BIP 353 resolution.

Feature Comparison

The following table compares protocols across dimensions that matter most for wallet developers and payment integrators.

Wallet Support

Protocol support varies significantly across wallets. The following table reflects verified wallet capabilities. BOLT11 support is near-universal, while BOLT12 adoption is still expanding.

For a broader comparison of Lightning wallets and their feature sets, see the Lightning wallet comparison tool.

Privacy Comparison

Privacy characteristics differ substantially across protocols. For developers building payment flows, understanding what metadata each protocol leaks is critical.

BIP21 on-chain transactions are the least private: addresses and amounts are permanently recorded on the public blockchain. UTXO analysis can link addresses to identities over time. Techniques like coin control and Silent Payments can mitigate this, but require deliberate effort.

BOLT11 improves on-chain privacy through onion routing, but the invoice itself contains the recipient's node public key. Anyone who sees the invoice can identify which node is receiving payment. For a deeper analysis of Lightning privacy, see our research on Lightning Network privacy.

BOLT12 offers the strongest privacy among these protocols. Blinded paths hide the recipient's node identity from the sender. The offer-to-invoice negotiation happens over onion messages within the Lightning Network, avoiding any HTTP-layer metadata leaks.

LNURL has the weakest privacy in the Lightning category. The sender's wallet makes HTTPS requests directly to the recipient's server, exposing the sender's IP address. The server can log request frequency, amounts, and timing. Using Tor mitigates IP exposure but adds latency and complexity.

How to Choose a Protocol

The right protocol depends on your use case, infrastructure, and priorities:

For maximum compatibility with on-chain wallets: use BIP21 URIs. Every Bitcoin wallet supports them. Combine with a Lightning parameter in a unified QR code to serve both on-chain and Lightning users from a single payment request.

For one-time Lightning payments today: BOLT11 is the safe default. It works with every Lightning wallet and every Lightning Service Provider. Generate invoices with the Lightning invoice generator.

For reusable payment codes with strong privacy: BOLT12 is the forward-looking choice. If your recipient infrastructure runs Core Lightning, Eclair, or LDK, BOLT12 offers are production-ready. The lack of native LND support is the main gap, addressable via LNDK.

For reusable codes when BOLT12 is not available: LNURL-pay and Lightning Address provide similar reusability at the cost of requiring HTTPS server infrastructure and weaker privacy. They remain the pragmatic choice for services that need reusable codes with maximum wallet compatibility today.

For merchant and point-of-sale applications: unified QR codes (BIP21 + Lightning) provide the best user experience. A single QR code serves customers regardless of wallet type. BTCPay Server generates unified QR codes by default.

For recurring payments and subscriptions: BOLT12 is the only protocol with native recurring payment support. LNURL can approximate this through repeated LNURL-pay calls, but without protocol-level guarantees.

The Role of Unified Standards

The fragmentation of Bitcoin payment protocols creates friction for both developers and users. A sender using a BOLT11-only wallet cannot pay a BOLT12 offer. A Lightning-only wallet cannot fall back to on-chain without a unified QR code. This is why the convergence toward BIP 321 unified URIs matters: they allow multiple payment methods to coexist in a single request.

BIP 353 pushes this further by enabling DNS-based resolution of human-readable names into BIP21 URIs. A single name like user@domain.com can resolve to an on-chain address, a BOLT12 offer, and a Silent Payment address simultaneously, without running a web server. This is a meaningful improvement over Lightning Address, which relies on HTTPS infrastructure. Platforms like Spark are building payment infrastructure that benefits from these unified standards, enabling seamless Bitcoin and Lightning transactions alongside stablecoin transfers on the same network.

Frequently Asked Questions

What is the difference between BOLT11 and BOLT12?

BOLT11 invoices are single-use, expire after a set time (default one hour), and expose the recipient's node public key. BOLT12 offers are reusable payment codes that hide the recipient behind blinded paths, support native recurring payments, and produce smaller QR codes. BOLT12 was merged into the Lightning spec in September 2024. The main tradeoff is wallet support: BOLT11 works everywhere, while BOLT12 is still being adopted across implementations.

Does LNURL require a web server?

Yes. Every LNURL interaction requires the recipient to run an HTTPS server that responds to wallet requests with JSON payloads. This includes LNURL-pay, LNURL-withdraw, LNURL-auth, and Lightning Address resolution. If the server goes offline, payments fail. This is a fundamental architectural difference from BOLT12, which operates entirely within the Lightning Network using onion messages and requires no HTTP infrastructure.

Which Bitcoin payment protocol is most private?

BOLT12 offers the strongest privacy. Blinded paths hide the recipient's node identity, and the offer-to-invoice negotiation uses onion messages rather than HTTP requests. BOLT11 exposes the recipient's node public key in the invoice. LNURL exposes the sender's IP address to the recipient's server. On-chain BIP21 transactions are publicly visible on the blockchain.

What is a unified QR code for Bitcoin?

A unified QR code encodes both an on-chain Bitcoin address and Lightning payment instructions in a single BIP21 URI. Lightning-capable wallets extract the Lightning parameter and pay instantly. On-chain-only wallets fall back to the Bitcoin address. The format uses BIP 321 parameters: lightning= for BOLT11 invoices or lno= for BOLT12 offers. BTCPay Server, Phoenix, BlueWallet, and Breez all support decoding unified QR codes.

Does LND support BOLT12?

LND does not have native BOLT12 support as of mid-2026. The LND team is working on onion messaging support (a prerequisite for BOLT12), tracked in their public issue tracker. In the meantime, LNDK provides a workaround by running alongside LND as a sidecar that uses LDK for BOLT12 functionality. Strike uses this approach for BOLT12 send support. Core Lightning, Eclair, and LDK all have full native BOLT12 support.

What is BIP 353 and how does it relate to Lightning Address?

BIP 353 defines DNS-based human-readable payment instructions. A recipient publishes a DNSSEC-signed TXT record containing a BIP21 URI at a specific DNS path. Unlike Lightning Address, which requires an HTTPS server, BIP 353 uses DNS directly and can resolve to multiple payment methods (on-chain, BOLT12, Silent Payments) simultaneously. Phoenix and BitBanana already support BIP 353 resolution. It is designed to complement or eventually replace LNURL-based Lightning Addresses.

Can I use BOLT12 for recurring payments?

Yes. BOLT12 includes native support for recurring payments with defined schedules. The offer can specify a recurrence period, and the payer's wallet can automate periodic payments against the same offer. This is a feature that BOLT11 lacks entirely. LNURL can approximate recurring payments through repeated LNURL-pay calls, but without the protocol-level structure that BOLT12 provides.

This tool is for informational purposes only and does not constitute financial advice. Protocol specifications, wallet support, and implementation status change frequently. Always verify current capabilities in the relevant specification documents and wallet release notes before building production payment flows.