# LNURL

> Source: https://docs.barcoder.ai/docs/standards/lnurl
> research date 2026-06-04 · extracted at 2026-10-06
> Publisher: Barcoder — encyclopedia of QR, barcode and payment-code standards

Specifications:
- [lnurl/luds — LNURL specifications (LUDs)](https://github.com/lnurl/luds)
- [LUD-01: Base LNURL encoding and decoding](https://github.com/lnurl/luds/blob/luds/01.md)
- [LUD-06: payRequest base spec](https://github.com/lnurl/luds/blob/luds/06.md)

## 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.<sup>[1][1]</sup> Because the encoded string is bech32-checksummed and uppercase-friendly, it is ideal for a [QR Code](https://docs.barcoder.ai/docs/standards/qr-code).<sup>[1][1]</sup> 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.<sup>[1][1]</sup><sup>[2][2]</sup> LNURL exists because a [BOLT11](https://docs.barcoder.ai/docs/standards/bolt11) invoice is typically single-use; LNURL adds a callback layer so one static QR can serve many payments or actions.<sup>[2][2]</sup>

## History

LNURL was created by the developer known as **fiatjaf** and was originally maintained in the `fiatjaf/lnurl-rfc` repository.<sup>[5][5]</sup> 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).<sup>[1][1]</sup> 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.<sup>[1][1]</sup> 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.<sup>[1][1]</sup><sup>[3][3]</sup>

## 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."<sup>[3][3]</sup> 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.<sup>[3][3]</sup> 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.<sup>[3][3]</sup>

### 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.<sup>[2][2]</sup> This makes one static code reusable for many payments.<sup>[2][2]</sup>
- **lnurl-withdraw (LUD-03)** — instead of asking the user for a [BOLT11](https://docs.barcoder.ai/docs/standards/bolt11) invoice, a service shows a "withdraw" QR; the wallet pulls funds *to itself* by generating an invoice that the service pays.<sup>[4][4]</sup>
- **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.<sup>[4][4]</sup>
- **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.<sup>[4][4]</sup>

## Use cases

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

## Implementations

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

## Comparison

- **LNURL vs single-use [BOLT11](https://docs.barcoder.ai/docs/standards/bolt11)**: a [BOLT11](https://docs.barcoder.ai/docs/standards/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.<sup>[2][2]</sup>
- **lnurl-pay vs [Lightning Address](https://docs.barcoder.ai/docs/standards/lightning-address)**: a [Lightning Address](https://docs.barcoder.ai/docs/standards/lightning-address) (`user@domain`) is a human-readable shorthand that resolves to an lnurl-pay endpoint, so it inherits the same callback flow.<sup>[2][2]</sup>
- **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](https://docs.barcoder.ai/docs/standards/bolt11) invoice, whereas Solana Pay returns a serialized Solana transaction.<sup>[1][1]</sup><sup>[2][2]</sup>

## 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.<sup>[1][1]</sup><sup>[2][2]</sup>

## Sources

[1]: https://github.com/lnurl/luds
[2]: https://github.com/lnurl/luds/blob/luds/06.md
[3]: https://github.com/lnurl/luds/blob/luds/01.md
[4]: https://voltage.cloud/blog/how-does-lnurl-work-enhancing-lightnings-user-experience
[5]: https://github.com/fiatjaf/lnurl-rfc

[1] [lnurl/luds — LNURL specifications](https://github.com/lnurl/luds) — GitHub, 2026
[2] [LUD-06: payRequest base spec](https://github.com/lnurl/luds/blob/luds/06.md) — lnurl/luds, 2026
[3] [LUD-01: Base LNURL encoding and decoding](https://github.com/lnurl/luds/blob/luds/01.md) — lnurl/luds, 2026
[4] [How does LNURL work](https://voltage.cloud/blog/how-does-lnurl-work-enhancing-lightnings-user-experience) — Voltage, n.d.
[5] [fiatjaf/lnurl-rfc (original repo)](https://github.com/fiatjaf/lnurl-rfc) — GitHub, n.d.

## Deployments

_No country reports mention this standard by name._

## Regions / aggregations not mapped to a single country

- Universal