LNURL

From Bitcoin Wiki
Jump to navigation Jump to search

LNURL is a family of HTTP protocols that let a Lightning wallet talk to a service without embedding a full BOLT 11 invoice in every QR code. A Bech32 string starting with lnurl1 decodes to an HTTPS (or onion) endpoint. The wallet GETs that endpoint, receives JSON, and then pays an invoice, withdraws, authenticates, or requests a channel. The documents are LNURL specifications (LUDs), not BIPs. Lightning address (LUD-16) is a human-readable alias for LNURL-pay.

Encoding

LUD-01 defines the Bech32 encoding. The human-readable part is lnurl. The data part is the UTF-8 URL as 5-bit groups. Mixed case is forbidden. QR codes should use uppercase. After decoding, if the URL already carries a tag query parameter the wallet uses that tag. Otherwise it GETs the URL and reads a JSON tag field.

Clearnet endpoints must be https:// with a publicly trusted certificate. Onion endpoints use http:// for Tor v2 or v3 addresses. LUD-01 tells clients to ignore HTTP status codes and headers for protocol meaning and to parse the body as JSON. Services that want browser wallets should send Access-Control-Allow-Origin: * on LNURL GETs.

An LNURL may appear as a lightning= parameter inside another URI so a webpage can offer both an ordinary link and a scannable LNURL fallback.

Common LUDs

Common LUDs include pay request (LUD-06), withdraw request (LUD-03), channel request, and authentication flows. The wallet presents a Bech32 lnurl1... string or a clear HTTPS URL. After decoding, it follows HTTP redirects only within limits defined by the LUD and expects JSON error objects when the service rejects the request.

LNURL-pay returns a callback that mints a fresh BOLT11 invoice for the chosen amount. That keeps QR codes short while still settling with ordinary Lightning HTLCs. The pay response advertises min and max sendable amounts in millisatoshis plus metadata the wallet must hash into the invoice description where the LUD requires it. BOLT12 offers pursue a similar reusable-receive goal over onion messages instead of HTTPS. Wallets may support both. A Lightning address is only a LUD-16 alias that resolves to LNURL-pay via /.well-known/lnurlp/<user>.

Withdraw flows (LUD-03 and related) return a callback, a one-time k1 challenge, and min/max withdrawable amounts. The wallet creates a BOLT11 invoice and returns it on the callback so the service can pay. Channel-request LUDs ask a node to open inbound capacity toward the wallet, which overlaps operationally with LSP tooling even when the wire format differs. Authentication LUDs prove control of a Lightning node key over HTTPS without creating a long-lived account password on the service.

Security

Because LNURL is HTTP, operators must protect endpoints against SSRF-style callback abuse, open redirects, and invoice substitution. Wallets should pin expected domains when following Lightning address well-known paths and should reject cleartext HTTP on non-onion hosts. A compromised web server can steal withdrawals or issue unpaid invoices even if the Lightning node itself remains honest. Withdraw endpoints should rate-limit k1 challenges and bind them to short lifetimes so stolen QR codes cannot drain funds indefinitely.

Services that mint invoices on behalf of users should authenticate callbacks and bind amounts so a malicious webpage cannot substitute a higher invoice after the wallet has shown a quote. Metadata in LNURL-pay must match what the wallet embeds when it verifies the returned invoice. Mismatched description hashes are a common phishing signal.

Status

LNURL remains widely deployed for Lightning addresses and withdraw kiosks even as BOLT12 offers spread. Many wallets implement a subset of LUDs rather than the full catalog. Operators should publish which LUDs they support and keep TLS certificates current, because expired HTTPS breaks receives independently of Lightning channel health.

BOLT12 does not obsolete LNURL overnight. HTTPS-based pay links remain useful where the receiver already runs a web server and the payer has no onion-message path. New deployments often expose both a Lightning address and a BOLT12 offer so payers can choose.

See also

External links