Lightning Address

Anna wants to receive contributions for her podcast. Instead of sending each listener a new, long invoice, she publishes a Lightning Address. The illustrative anna@example.com is easy to remember: the part before the at sign identifies a recipient at the service, and the part after it is the domain that answers the wallet. The resemblance to email is deliberate, but money does not travel through email. An existing email address is not automatically a Lightning Address, and the name alone does not establish who owns it. Check it with the creator you intend to support. [1] [6]

A listener enters the name in a compatible wallet. The wallet retrieves a description and the allowed amount range from the service. Once the user checks the domain, description and chosen amount, it requests a specific BOLT 11 invoice and checks its amount before paying. Obtaining an invoice is not a payment. This process is LNURL-pay. The service supplies a callback, the address used to request the invoice, metadata describing the payment, and minSendable and maxSendable limits. The amount is expressed in msat, thousandths of a satoshi: 1000 msat = 1 sat. The invoice arrives in the pr field. [2] [3]

Anna might use a service that manages a wallet for her, or connect the name to her own Lightning node, the software handling her payments. The address looks the same either way. A web endpoint, where the server answers the wallet, can use a bridge server to request an invoice from her node. This intermediary is not necessarily a custodian; that depends on the setup and permissions. Control over the server's responses still matters: someone who can replace them can present a different invoice to the payer. Owning a domain does not by itself guarantee self-custody, meaning control of your own keys. [3] [4]

A wallet can send to a Lightning Address without giving its user an address for receiving. Receiving also requires an available web service, invoice creation and the ability to receive the payment on the Lightning Network. Payments travel through channels: connections between participants in which the balance of funds on each side changes. That includes Inbound Liquidity: funds on the other side of channels that can move to the recipient during a payment. A memorable name does not create it. If the address loads but payment fails, the name need not be the problem. Distinguish a web response, an invoice obtained and confirmed receipt of funds. [3] [5]

With your own domain, you can change the server handling payments while keeping the same name for listeners. BTCPay documentation shows an endpoint redirect using HTTP 301: it sends the web request elsewhere, without moving any coins. You may lack that control over a name on someone else's domain. A Seed Phrase, the wallet’s recovery words, does not by itself guarantee that access to a service account can be restored. It does not back up domain administration or the settings of DNS, the system directing the domain to its destination. After a change, check the correct invoice and an actually received test payment, not just that the address opens. Old contacts do not learn a new name automatically. [5] [3]

LUD-16 describes turning the name into a GET web request, a request for data. The wallet contacts the domain at /.well-known/lnurlp/username, replacing username with the user's name. It uses HTTPS on the ordinary web and HTTP for an onion domain. The payRequest response continues with LUD-06. HTTPS protects the connection against tampering in transit; it does not prove the service itself is trustworthy. The service processes requests and knows which recipient an invoice is for, so the readable name does not add anonymity by itself. [1] [2]

LUD-16 permits lowercase a-z, digits 0-9 and -_. in usernames; ordinary email allows a wider set of characters. The optional @domain shorthand identifies the default recipient _@domain at the /.well-known/lnurlp/_ path, but a wallet or service need not support it. The +tag extension is not universal either. A supporting service can distinguish the purpose of a contribution and include it as text/tag. This is not a new private key or a privacy guarantee. For everyday use, copy the exact name published by the recipient. [1]

Metadata are accompanying details exchanged by wallet and service in the structured JSON format. In LNURL-pay they include text/plain, a short payment description. LUD-16 adds text/identifier to associate the payment with a name, or text/email when that name corresponds to an actual email address. This helps the wallet show what the payment relates to. These are still details supplied by the service, not independent verification of Anna's real-world identity. Checking the original address, domain and amount therefore remains part of paying carefully. [1] [2]