Cowrie Research

lnurl-primary-sources-2026-05-02

3 min read

LNURL primary sources — 2026-05-02

Project status in this pass

  • No canonical standalone whitepaper or litepaper surfaced.
  • The clearest current source of truth was the lnurl/luds specification repository and the individual LUD markdown documents.
  • The materials consistently frame LNURL as a modular wallet-to-service interoperability family rather than as a single company product.

Primary-source snapshots

1) Canonical spec repository / README

  • URLs:
  • Key excerpts/signals:
    • The README says the repository contains all the individual documents describing “each small piece of protocol that can be implemented under the LNURL umbrella.”
    • It says different wallets and services may implement different sets of protocols.
    • It maintains broad implementation tables covering wallets, services, and which LUDs they support.
  • Why it mattered:
    • This is the clearest first-party evidence that LNURL is interoperability infrastructure and a modular standards family, not a single product brand.

2) Adoption footprint from the README tables

  • Source: https://raw.githubusercontent.com/lnurl/luds/luds/README.md
  • Key excerpts/signals:
    • The implementation matrix lists adoption across many wallets and services including Alby, Balance of Satoshis, BitBanana, Bitkit, BlueWallet, Breez, BTCPay Server, CoinCorner, CoinOS, Fountain, Geyser, LNbits, Machankura, Muun, Phoenix, Pouch.ph, River, Wallet of Satoshi, ZBD, Zeus, and others.
    • The service table maps real services to specific LUD support rather than simply naming “compatible” brands.
  • Why it mattered:
    • The breadth and granularity of the implementation table shows LNURL is operational ecosystem plumbing with real-world cross-wallet adoption.

3) LUD-06 / payRequest

  • Source: https://raw.githubusercontent.com/lnurl/luds/luds/06.md
  • Key excerpts/signals:
    • Describes a flow where the wallet decodes a static LNURL, requests JSON from the service, receives a callback URL plus maxSendable, minSendable, metadata, and tag: "payRequest", then requests an amount-specific invoice.
    • Requires the wallet to verify that the invoice description_hash matches the LNURL metadata.
    • Explicitly frames LNURL-pay as a way to scan a static QR code or click a static LNURL address and retrieve richer metadata than a regular invoice.
  • Why it mattered:
    • This document makes LNURL’s core wallet-to-service control-plane shape concrete and explains why the protocol became important for reusable QR codes and richer payment UX.

4) LUD-16 / static internet identifiers

  • Source: https://raw.githubusercontent.com/lnurl/luds/luds/16.md
  • Key excerpts/signals:
    • Defines human-readable identifiers in the form <username>@<domainname>.
    • Says wallets should resolve these identifiers through https://<domain>/.well-known/lnurlp/<username> (or http for onion domains).
    • Says the response must be the same as the LUD-06 pay flow and documents optional +tag addressing.
  • Why it mattered:
    • This is the clearest primary-source evidence that LNURL underlies the Lightning Address pattern and therefore a major user-facing discovery/payment convention.

Working conclusion

LNURL is best cataloged as Lightning wallet-to-service interoperability infrastructure. The decisive evidence in this pass was the spec repo’s modular “umbrella” framing, the broad wallet/service implementation matrix, the two-step callback-based payRequest flow in LUD-06, and the /.well-known/lnurlp/ human-readable identifier resolution flow in LUD-16.

Graph View