A Lightning address looks like an e-mail address — for example alice@wallet.example — and lets anyone pay you over Lightning without asking for a fresh invoice each time. Behind it is LNURL-pay: the payer's wallet asks the domain's server for an invoice of the chosen amount and pays that invoice. It is convenient, it is reusable, and it means whoever runs the domain stands between the payer and you. It is not a Bitcoin on-chain address and cannot be used where a bc1… address is required.
What happens when someone pays alice@wallet.example
- The payer's wallet converts the address into a URL:
https://wallet.example/.well-known/lnurlp/alice. - The server answers with JSON: a callback URL, the minimum and maximum amount in millisatoshis and a short description.
- The payer enters an amount within the limits; the wallet calls the callback with
?amount=in millisats. - The server returns a BOLT11 invoice for that amount, generated by the recipient's node or by the custodial provider.
- The wallet checks that the invoice amount and description hash match, then pays it over Lightning.
All of this is specified in the LNURL documents (LUD-06 for pay requests, LUD-16 for the name@domain form). The invoice at step 4 is an ordinary invoice; the Lightning invoice decoder shows its amount and expiry if you want to check what your wallet is about to pay.
LNURL strings: lnurl1…
Before the e-mail form became popular, LNURL links were shared as long bech32 strings starting with lnurl1 or as QR codes. Decoded, such a string is simply an HTTPS URL. The same mechanism also covers withdrawals (LNURL-withdraw, used by faucets and some exchanges to let you pull funds into your wallet) and login (LNURL-auth). Wallets decide what to do based on the tag in the server's answer.
| Format | Example start | Reusable | Needs a web server |
|---|---|---|---|
| BOLT11 invoice | lnbc… | No | No |
| LNURL-pay link | lnurl1… | Yes | Yes |
| Lightning address | name@domain | Yes | Yes |
| BOLT12 offer | lno1… | Yes | No — requested over Lightning itself |
| On-chain address (not Lightning) | bc1… | Technically | No |
Getting a Lightning address
Most people get a Lightning address from their wallet: custodial wallets and several self-custodial ones issue an address on their own domain when you create an account. Node operators can run their own LNURL server or use a self-hosted tool so that the address sits on a domain they control; the server then requests invoices from their node. A few services also let you point an address on your personal domain to a wallet by publishing the right redirect. Whichever route you choose, the address works only while the server answering for it is online.
Some LNURL-pay servers support extra features defined in other LUD documents: a comment field that the payer can fill, payer identity information, or a success action that shows a message or URL after payment. Wallets display these when the server offers them; none of them are needed for a simple payment.
Trust and privacy
- The domain owner controls the invoices. If the domain is compromised, an attacker can return invoices that pay them instead of you. Use addresses from wallets and domains you trust.
- Custodial addresses. Many Lightning addresses are issued by custodial wallets: payments land in an account the provider holds.
- The server sees the requests. It learns the payer's IP address (unless the wallet uses a proxy) and the amounts requested.
- Lookalike domains. wallet-example.com and wallet.example are different servers. The phishing link checker flags common lookalike tricks.
BOLT12 offers as an alternative
BOLT12 adds reusable payment codes to the Lightning protocol itself: an offer starting with lno1 can be paid many times, and the payer's wallet fetches a fresh invoice from the recipient's node over Lightning messages, with no web server and no domain. The specification was merged into the BOLTs in 2024 and is supported by Core Lightning, Eclair and Phoenix, among others; support in other implementations and wallets is still uneven. Some services publish both a Lightning address and a BOLT12 offer.
Common errors
- “Amount out of range”. The server's minSendable or maxSendable excludes your amount. Limits are in millisats, so 1,000,000 msat is 1,000 sats.
- “Could not fetch”. The server is down or the domain does not support LNURL. Ask for an invoice instead.
- Paying a Lightning address from an exchange. Many exchanges accept only invoices for withdrawals; generate an invoice in the recipient's wallet.
- Using a Lightning address for a swap payout. KOT.CASH pays BTC on-chain only; enter a bc1… address.
Before sharing your Lightning address publicly, send yourself a small test payment from another wallet. It confirms that the server answers, that the limits suit the amounts you expect and that payments land in the wallet you think they do.
FAQ
Is a Lightning address the same as an e-mail address?
It only looks like one. It points to an LNURL-pay server on that domain, not to a mailbox.
Can I receive on-chain BTC at a Lightning address?
No. It returns Lightning invoices. For on-chain BTC give a bc1… address.
What is the difference between LNURL and a Lightning address?
A Lightning address is a human-readable form of an LNURL-pay link; both resolve to an invoice via an HTTPS server.
What is a BOLT12 offer?
A reusable Lightning payment code (lno1…) that fetches invoices over Lightning itself, without a web server.
Can KOT.CASH pay out to my Lightning address?
No. KOT.CASH sends BTC on-chain only.