LNURL

LNURL is a family of open standards (the LUD series) that wrap interactions with a Lightning service inside a bech32-encoded HTTPS URL, typically prefixed lnurl1 and presented as a QR code or a lightning: link. Instead of a one-shot BOLT11 invoice — which encodes a single fixed payment and expires — an LNURL points a wallet at a server endpoint it can query, so a single static code can drive a whole multi-step flow: fetch parameters, negotiate an amount, receive a fresh invoice, confirm. It is the plumbing that made the Lightning Network usable for tips, logins, and reusable payment codes rather than only one-off invoices.

The subprotocols

LNURL is split into tag-identified subprotocols, each solving one interaction pattern. LNURL-pay (LUD-06) returns a callback URL plus minimum and maximum sendable amounts, letting a static printed code accept arbitrary payments — the wallet requests a fresh invoice for whatever amount the payer chooses. LNURL-withdraw inverts the flow: a service authorises a wallet to pull funds, which is what powers faucets, refunds, and Lightning ATMs. LNURL-auth (LUD-04) provides password-free login by having the wallet sign a challenge with a key derived for that domain, so the same seed that holds your sats becomes a portable identity — no email, no password database to breach. LNURL-channel requests an inbound channel from a peer. Because the wallet decodes the URL and simply follows the tag, one scanning gesture covers every case.

Why it underpins so much

LNURL is the connective tissue beneath several higher-level conveniences. Lightning Address — the user@domain identifier that made receiving Lightning payments feel like email — is essentially LNURL-pay resolved through a well-known URL path. Nostr Zaps extend the LNURL-pay request with a Nostr event, so a tip carries a signed social receipt. Servers must return JSON payloads over HTTPS (or HTTP for onion services) and avoid redirects, keeping the trust boundary explicit: the wallet talks to exactly the endpoint the code named.

The flow behind the QR code is worth seeing once. The wallet decodes the bech32 string into an HTTPS URL and performs a GET; the server replies with JSON describing the interaction — tag, callback URL, limits, metadata. For a payment, the wallet then calls the callback with the chosen amount and receives a standard BOLT11 invoice to pay over Lightning as usual. Nothing about the payment itself changes; LNURL is purely a negotiation layer bolted on front, which is why it could spread wallet-by-wallet without touching the underlying protocol.

The trust trade-off

The honest caveat is that LNURL reintroduces a web server into a payment protocol. A static LNURL-pay code is only as available — and as honest — as the HTTPS endpoint behind it, and whoever operates that endpoint sees payment metadata and could substitute invoices. For most users that endpoint is a custodial wallet provider, which quietly recreates the intermediary Lightning was meant to route around. The sovereign answer is to self-host the endpoint: run your own LNURL server or use the one built into self-hosted node stacks, so the machine answering for your payment code is yours. That is the difference between a payment identity you rent and one you own — and it is why D-Central tracks these standards: so sovereign Bitcoiners can operate their own receiving infrastructure rather than lean on a custodian.

For the convenience layers built on top, start with Lightning Address; for the social-payments layer, see Nostr Zaps above. Together they show the pattern LNURL enables: static, shareable, human-friendly payment endpoints on top of a network that natively speaks only ephemeral invoices.