Lightning address
A Lightning address is a static identifier of the form user@domain that a Lightning wallet resolves to an LNURL-pay endpoint. It is specified as LUD-16. The identifier is not a Bitcoin address and is not a BOLT 12 offer. Each payment still fetches a fresh BOLT 11 invoice over HTTPS.
Lightning invoices are long, usually single-use, and inconvenient to read aloud or print. LNURL-pay already allowed a reusable HTTPS URL. The mapping from that URL to an email-shaped string was published as LUD-16 in 2021 (authors akumaigorodski, André Neves, and fiatjaf). It requires a web server and a Lightning node that can mint invoices, not a change to Bitcoin or to the Lightning BOLTs.
Resolution
The wallet splits the string on the last @. The local part is restricted to a-z0-9-_., which is stricter than RFC 5322 email. A plus sign is allowed when the service supports tags. For satoshi@example.com the wallet GETs:
https://example.com/.well-known/lnurlp/satoshi
On an onion domain the scheme is HTTP rather than HTTPS. The JSON response is an LNURL-pay (LUD-06) document.
The LUD-06 document includes a callback URL, min and max sendable amounts, and metadata. The metadata must include a text/identifier or text/email entry for the address. The wallet then requests an invoice from the callback with the chosen amount in millisatoshis, checks that the invoice amount matches, and pays it.
Tags
A user+tag@domain form lets a service offer several identifiers for one user. The wallet requests /.well-known/lnurlp/user+tag. The server may strip the tag for routing and may put the tag into metadata.
Availability
Lightning address inherits LNURL-pay's properties. The receiver's server must be online. The payer's IP is visible to that server. Successive payments to the same address can be correlated by the server even though each invoice is unique. The address itself never appears on the Bitcoin chain.
Later work such as BIP 353 encodes a payment URI in a DNS TXT record under <user>.user._bitcoin-payment.<domain>. That record can point to BOLT 12 offers, on-chain addresses, or Silent Payment codes, and is authenticated with DNSSEC rather than with an HTTPS server. BIP 353 addresses may be displayed with a bitcoin symbol prefix. They are a different resolution mechanism that happens to use a similar user@domain display format. BIP 353 is intended to extend and subsume Lightning address. Wallets may fall back to LUD-16 if DNS resolution fails.
Servers may rate-limit invoice minting to reduce probing and denial-of-service load. Payers that fetch many quotes without paying can still learn the receiver's liquidity hints from returned invoices. Some deployments put the Lightning node behind a reverse proxy that only exposes the well-known LNURL paths.
Unlike a static on-chain address, a Lightning address never receives coins by itself. Every successful pay path ends in a BOLT11 (or occasionally BOLT12) invoice settlement. If the HTTPS endpoint is unavailable, payers cannot resolve the address even when the Lightning node is online. Operators therefore treat web uptime as part of receive availability. Services that publish Lightning addresses should keep the well-known path behind authenticated TLS and should not redirect payers to unrelated hosts. A hijacked DNS or certificate can replace the LNURL-pay document without touching the Lightning node.
See also
External links
- https://github.com/lnurl/luds/blob/luds/16.md — LUD-16: paying to static internet identifiers