LNURL

Lightning invoices expire and can only be paid once, which makes them awkward to print or publish. LNURL fixes that by putting an HTTPS request in front of the invoice: your wallet asks a server for the payment request at the moment you want to pay. The specifications live outside the BOLTs, numbered LUD-01 upward.

How it works

LNURL turns a static link into a live conversation between a wallet and a server.

The link itself is the whole trick. In its original form, LUD-01, an HTTPS URL is bech32 encoded with an lnurl prefix, which makes a blob that survives being printed as a QR code or typed into a chat window. The newer LUD-17 form drops the encoding and uses plain scheme prefixes such as lnurlp: in front of an ordinary URL, which is shorter and easier to debug. Either way, the wallet decodes it, performs a GET request, and receives JSON telling it what kind of interaction this is.

The tag field in that JSON decides everything that follows. LUD-06 defines payRequest, the pay flow: the server returns a callback URL plus minSendable and maxSendable, both in millisatoshis, and a metadata string that the wallet displays. You pick an amount, the wallet calls back with it, and the server returns a freshly minted BOLT11 invoice for exactly that sum. LUD-03 defines withdrawRequest, which runs the other direction: the server offers money and the wallet supplies an invoice to receive it. LUD-02 requests a channel from a peer. LUD-04 defines auth, where the wallet signs a challenge with a key derived per domain, which is how some Lightning sites log you in without a password.

The safety property worth understanding is narrow. LNURL guarantees that the invoice came from the domain in the link and that its amount matches what you approved, because the wallet checks the returned invoice before paying. It guarantees nothing about who controls that domain. Scanning an LNURL code taped over a real one at a market stall pays the attacker's server, and the payment succeeds exactly as designed.

Where you see it

Most people meet LNURL without ever seeing the word.

Tipping and donation pages use LNURL-pay behind a QR code, which is why the same printed code works for a hundred different customers at a hundred different amounts. Bitcoin conference giveaways and faucet cards use LNURL-withdraw: you scan, your wallet quietly generates an invoice, and the sats arrive with no visible invoice at all. Some Lightning wallets and web services use LNURL-auth as their entire login system.

The biggest deployment is indirect. A Lightning address, the user@domain form, is defined in LUD-16 and is built directly on LNURL-pay: the address is translated into a well-known HTTPS path and from there the flow is ordinary LUD-06. If your wallet supports Lightning addresses, it already speaks LNURL.

The main caveat is availability. Because there is a web server in the middle, an LNURL code is only as reliable as that server and its TLS certificate. A BOLT11 invoice, once generated, can be paid with the server offline; an LNURL link cannot.

LNURL vs BOLT11 invoice

LNURL is a way to obtain a payment request; a BOLT11 invoice is the payment request. That single difference explains their properties. An invoice is self-contained, signed by the recipient node, valid for a set time, and payable once. An LNURL link contains no amount, no payment hash and no signature, stays valid indefinitely, and works for any number of payers because each one triggers a new invoice. Print an invoice and it dies within the hour. Print an LNURL code and it keeps working until the domain does not.