Lightning Address

LUD-16 uses a username and domain, but limits the name to lowercase a-z, digits 0-9 and -_.; plus is allowed only if the service supports tags. Ordinary email syntax is broader. A mailbox therefore does not guarantee a Lightning Address, and the same name does not authenticate the recipient as a person. [Lightning Address — LUD-16] [Lightning Address — Project overview]

The wallet uses GET at /.well-known/lnurlp/username on the domain, over HTTPS or HTTP for an onion service. The response is a payRequest under LUD-06. The actual domain and its service matter; the part before the at sign is not a node’s public key. [Lightning Address — LUD-16]

The response provides callback, metadata and minSendable/maxSendable limits. The payer chooses amount in msat; 1000 msat is one satoshi. The callback returns an invoice in pr and the wallet checks the amount matches before paying. Address lookup and receipt of an invoice are not settlement. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]

Newer LUD-16 allows optional @domain shorthand for _@domain and a path ending /_. Neither service nor wallet must support it. Supported +tag is sent in the path; the service can use it as text/tag metadata. A tag is neither a new bitcoin key nor automatic privacy protection. [Lightning Address — LUD-16]

LUD-16 requires text/identifier or text/email in metadata; text/email is for an actual email address. LNURL-pay’s text/plain remains required too. Compare the displayed name and description with the domain and intended recipient. A service’s assertion is not independent verification of a human identity. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]

A service can issue invoices from its own wallet or use a bridge server connected to a node. The format itself therefore implies neither custody nor self-custody. A bridge needs permissions for its function, not automatically unrestricted wallet control. Whoever controls the endpoint can influence which invoice the payer receives. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]

A wallet can pay a Lightning Address without providing users with their own address. Receiving requires a functioning web service, invoice creation and the ability to receive the payment. A readable address creates no inbound liquidity by itself. Repeated lookups can disclose the recipient and timing to the provider. [Lightning Address — Implementation guide]

A personal domain lets you redirect the endpoint to another server; BTCPay documents HTTP 301, for example. With someone else’s domain, retaining the name depends on the provider. A seed does not restore DNS control, certificates or account mappings. After a service change, verify lookup, destination invoice and receipt again; do not assume old contacts update automatically. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]