Payment Instructions Map

BOLT-11 Invoice

A BOLT-11 invoice is a standardized format used to request payments over the Lightning Network. It is created by the recipient and contains essential payment details such as the amount, a short UTF-8 description of the payment purpose (e.g., "1 cup of coffee"), and an optional expiry time. The invoice is encoded using the bech32 format, making it QR-code-friendly and human-readable, with support for extensions while maintaining backward compatibility.

Fallback Addresses

A fallback address in a BOLT-11 invoice is a backup on-chain Bitcoin address that allows funds to be sent directly on-chain if a Lightning Network payment cannot be completed.

Deprecation notice: fallback addresses might be deprecated in the near future in favor of using BIP-21 or BIP-353. See the comment from Bastien Teinturier.

BOLT-12 Offer

Defined in the BOLT-12 specification.

A BOLT-12 offer is a modern payment request format for the Lightning Network. It is designed as a successor to BOLT-11 invoices. It acts as a reusable blueprint that a payer can use to request a specific invoice, enhancing privacy and flexibility. Unlike one-time BOLT-11 invoices, BOLT-12 offers can be shared publicly and used multiple times, enabling features like dynamic pricing and refund metadata. The offer contains minimal data, making it smaller and more efficient for QR codes. It leverages onion messages and route blinding for secure, private communication between payer and payee. BOLT-12 shifts the invoice creation responsibility to the payer, improving receiver privacy.

BIP-21 URI Scheme

Defined in the BIP-21 specification and updated in the BIP-321 specification

BIP-21 defines a URI scheme for making Bitcoin payments, based on RFC 3986. It encodes a Bitcoin address in the path component and supports optional query parameters such as amount (specified in decimal BTC), label (for the recipient's name), and message (a note for the sender). The format enables standardized payment requests across wallets and services, and can also support extensions like Payjoin. This URI structure simplifies payment initiation by bundling all necessary data into a single link.

BIP-352 Silent Payments

Defined in the BIP-352 specification.

It is a wallet-level protocol that lets a receiver publish a single public identifier (a "silent address") while every incoming payment arrives at a unique, unlinkable on-chain address — with no extra on-chain notification transaction required.

More information on Bitcoin design guide.

BIP-353 DNS Payment Instructions

Defined in the BIP-353 specification.

BIP-353 defines a method for publishing Bitcoin payment instructions via DNS, enabling human-readable addresses like ₿user@domain. Payment instructions are stored in DNS TXT records at the subdomain user.user._bitcoin-payment.domain, and must be secured with DNSSEC to ensure authenticity. These instructions can specify various payment types, including on-chain Bitcoin addresses, BOLT-11 invoices, BOLT-12 offers. When resolving a payment address, the client performs a DNS lookup and validates the DNSSEC chain to securely retrieve the recipient's payment details.

On-Chain Addresses

More information on Bitcoin design guide.

LNURL

Defined in the LUD specifications.

LNURL is a set of conventions that let wallets fetch Lightning actions over HTTPS (such as withdraw, pay, or channel requests) via a simple URL, reducing the need for QR codes to contain all payment details.

Lightning Addresses let users share an email-like identifier (e.g., name@domain) that resolves to an LNURL-pay endpoint, so wallets can fetch metadata and request invoices.

Documentation