Lightning Address

A Lightning Address is an email-like identifier in the form username@domain.com that anyone can pay over the Lightning Network without first being handed a fresh invoice. It is defined by LNURL specification LUD-16, and it solved Lightning's most stubborn usability problem: BOLT11 invoices are single-use and amount-specific, so “just send me sats” used to require a live exchange of a long, expiring string. A Lightning Address is static, human-readable, and printable on a business card, while the actual invoices are generated fresh behind the scenes for every payment.

How resolution works

When a wallet is given satoshi@example.com, it splits the address at the @ into a name and a domain, then performs an HTTPS GET request to https://example.com/.well-known/lnurlp/satoshi. The server responds with a standard LNURL-pay payload containing a callback URL plus minSendable and maxSendable amounts in millisatoshis. The wallet asks the callback for an invoice at the chosen amount, receives a normal BOLT11 invoice, and pays it over Lightning as usual. Because the flow reuses the existing LNURL-pay machinery end to end, any LNURL-pay-capable wallet supports Lightning Addresses with essentially no extra code — which is why adoption spread so quickly across the ecosystem. Usernames are restricted to lowercase alphanumerics plus hyphen, underscore, and period, keeping addresses unambiguous across wallets.

The custody question

Read that flow again and the dependency jumps out: a Lightning Address requires a web server answering HTTPS on a domain. Most users get theirs from a custodial wallet or a hosted service, which means a third party generates their invoices and, in the fully custodial case, holds their sats. That is convenient and fine for pocket change, but it reintroduces exactly the intermediary Lightning was supposed to route around: the provider can censor payments, log every payer, or disappear with the balance.

Self-hosting your receiving identity

The sovereign version ties the address to a domain you control, backed by your own node. Run an LNURL server alongside your Lightning node — several node-in-a-box stacks and self-hosted packages bundle one — point you@yourdomain.com at it, and no third party sits between a payer and your channels. Even a middle path helps: some services let you keep your own domain while they handle invoice generation against your node, so you can migrate providers without changing the address you have published for years. The address is your receiving identity; owning the domain means owning the identity, the same way self-custody means owning the coins. For a miner selling repair services or a small shop taking bitcoin directly, a self-hosted Lightning Address is the difference between “pay my custodian” and “pay me.”

Beyond payments

The same address scheme underpins Nostr Zaps: a Nostr profile advertises a Lightning Address, and zap-capable clients resolve it through the identical LNURL-pay flow to tip notes with sats. One static identifier, published once, thus makes you payable from wallets and social clients alike — a small standard doing a lot of quiet work.