LNURL

Overview

LNURL is a family of Lightning Network protocols built around a single trick: a service's HTTPS (or Tor onion) URL is bech32-encoded into a compact lnurl1... string that a wallet can scan or follow automatically.[1] Because the encoded string is bech32-checksummed and uppercase-friendly, it is ideal for a qr-code.[1] After decoding, the wallet calls the URL and the JSON response's tag field tells it which sub-protocol applies — lnurl-pay, lnurl-withdraw, lnurl-auth, or lnurl-channel — each a small spec on top of the base encoding.[1][2] LNURL exists because a bolt11 invoice is typically single-use; LNURL adds a callback layer so one static QR can serve many payments or actions.[2]

History

LNURL was created by the developer known as fiatjaf and was originally maintained in the fiatjaf/lnurl-rfc repository.[5] The specifications were later reorganized into individually numbered documents — "LUDs" — and the canonical home is now the lnurl/luds repository (~656 stars, ~166 forks, active 2026).[1] The repository describes the protocols as "individual documents describing each small piece of protocol that can be implemented under the LNURL umbrella," and requires a new LUD to be implemented by at least two separate wallets before acceptance.[1] Foundational documents include LUD-01 (base encoding), LUD-02 (channelRequest), LUD-03 (withdrawRequest), LUD-04 (auth) and LUD-06 (payRequest); the dependency tree has LUD-01 as the root of most others.[1][3]

Technical specification

Base encoding (LUD-01)

LNURL is "a bech32-encoded HTTPS/Onion URL that can be interacted with automatically by a wallet in a standard way."[3] A service URL such as

https://service.com/api?q=3fc3645b439ce8e7f2553a69e5267081d96dcd340693afabe04be7b0ccd178df

bech32-encodes to a string with the human-readable prefix lnurl and a version character 1:

LNURL1DP68GURN8GHJ7UM9WFMXJCM99E3K7MF0V9CXJ0M385EKVCENXC6R2C35XVUKXEFCV5MKVV34X5EKZD3EV56NYD3HXQURZEPEXEJXXEPNXSCRVWFNV9NXZCN9XQ6XYEFHVGCXXCMYXYMNSERXFQ5FNS

Encoded LNURLs may be all-uppercase or all-lowercase (never mixed), and QR codes should use uppercase. Decoding reverses bech32 (5-bit → 8-bit) to recover the URL; only HTTPS (no self-signed certs) or HTTP-over-onion is valid.[3] After decoding, if a tag query parameter is present it determines behaviour directly; otherwise the wallet does a GET and reads the tag field of the returned JSON.[3]

Sub-protocols (tags)

• lnurl-pay (LUD-06) — GET to the LNURL returns JSON with callback, minSendable/maxSendable (in millisatoshi), metadata, and tag: "payRequest". The wallet shows the metadata, the user picks an amount, and a second GET to <callback>?amount=<milliSatoshi> returns {"pr": "<bolt11 invoice>", "routes": []}. The wallet checks the invoice amount and pays.[2] This makes one static code reusable for many payments.[2]
• lnurl-withdraw (LUD-03) — instead of asking the user for a bolt11 invoice, a service shows a "withdraw" QR; the wallet pulls funds to itself by generating an invoice that the service pays.[4]
• lnurl-auth (LUD-04) — a "login" QR; the wallet derives a service-specific linkingKey and signs a challenge (k1), authenticating the user without a password.[4]
• lnurl-channel (LUD-02) — a "channel" QR whose JSON carries a remote node uri, a callback, and a k1; the wallet connects and the service opens an inbound Lightning channel to it.[4]

Use cases

• Reusable static payment QR: one lnurl-pay code accepts many payments, unlike a single-use bolt11 invoice.[2]
• Withdrawals / faucets / ATMs: lnurl-withdraw lets a kiosk or service push sats to a scanning wallet.[4]
• Passwordless login: lnurl-auth turns a Lightning key into a login credential.[4]
• Inbound liquidity: lnurl-channel lets a service open a channel to a new user from a scanned code.[4]

Implementations

• lnurl/luds — the canonical specification set (Markdown); ~656 stars, active 2026.[1]
• lnbits/lnurl — a Python LNURL implementation library.[1]
• Per the repo, LNURL is supported across self-hosted services (BTCPayServer, LNbits) and libraries in Go, JavaScript, Rust, Python, C#, Dart and more.[1]

Comparison

• LNURL vs single-use bolt11: a bolt11 invoice fixes a payment hash and amount and is normally single-use; LNURL's callback layer lets a single static code (e.g. lnurl-pay) generate a fresh invoice per payment.[2]
• lnurl-pay vs lightning-address: a lightning-address (user@domain) is a human-readable shorthand that resolves to an lnurl-pay endpoint, so it inherits the same callback flow.[2]
• LNURL vs Solana Pay transaction request: both add a server callback over a scanned code, but LNURL targets the Lightning Network and returns a bolt11 invoice, whereas Solana Pay returns a serialized Solana transaction.[1][2]

Status

LNURL is an active, widely deployed family of Lightning protocols, implemented by major Lightning wallets and self-hosted services, with the spec set actively maintained in 2026.[1][2]

Sources

1 lnurl/luds — LNURL specifications — GitHub, 2026 2 LUD-06: payRequest base spec — lnurl/luds, 2026 3 LUD-01: Base LNURL encoding and decoding — lnurl/luds, 2026 4 How does LNURL work — Voltage, n.d. 5 fiatjaf/lnurl-rfc (original repo) — GitHub, n.d.

Deployments

No country reports mention this standard by name.

Regions / aggregations not mapped to a single country

• Universal