Cowrie Research

lnurl

3 min read

LNURL

  • Name: LNURL
  • URL: https://github.com/lnurl/luds
  • Category: Lightning interoperability specification / payment-and-auth URL standard / wallet-to-service control-plane protocol
  • Tags: bitcoin-ecosystem
  • Summary: LNURL is Lightning wallet-to-service plumbing, not a wallet feature and not a company product. The useful point is the small-protocol family: encode a service URL, fetch policy and metadata, then let wallets handle pay, withdraw, auth, channel, and static-identifier flows through a shared callback pattern that many different wallets and services can implement.
  • What it does:
    • Defines base LNURL encoding/decoding and a modular family of Lightning URL-driven interaction specs under the LUD documents
    • Standardizes payRequest, where a wallet fetches metadata and a callback URL from a service, requests an invoice for a chosen amount, verifies the metadata hash in the invoice, and then pays
    • Standardizes withdrawRequest, auth, and channelRequest flows so wallets can interact with services for withdrawals, login/authentication, and channel-related actions
    • Defines payments to static internet identifiers such as user@domain by resolving /.well-known/lnurlp/<username> into the same LUD-06 pay flow
    • Documents optional extensions like comments, payer identity, reusable withdraw flows, and verification hooks through additional LUDs
    • Serves as the protocol substrate behind many familiar Lightning UX patterns, especially Lightning Address-style identifiers and static QR/link payment flows
  • Key claims:
    • The lnurl/luds README says the repository contains individual documents for “each small piece of protocol that can be implemented under the LNURL umbrella,” which is the clearest sign that LNURL is a modular standards family rather than one monolithic product
    • That same README explicitly notes that different wallets and services may implement different subsets of the protocol family, reinforcing that LNURL is interoperability infrastructure
    • The README’s implementation tables show adoption across a long list of 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 many others
    • LUD-06 defines a two-step payRequest flow where a wallet first fetches a JSON description containing callback, sendable range, metadata, and a payRequest tag, then requests an amount-specific invoice and verifies the invoice description_hash against the metadata before payment
    • LUD-16 defines static internet-identifier payments like satoshi@bitcoin.org via /.well-known/lnurlp/<username> resolution, which is the core mechanism behind the Lightning Address pattern
    • LUD-16 also allows +tag addressing and requires identifier-related metadata entries, showing LNURL is standardizing user-facing naming and discovery conventions in addition to raw invoice retrieval
  • Whitepaper: No canonical standalone LNURL whitepaper or litepaper surfaced in this pass. The clearest current source of truth was the lnurl/luds specification repository and specific LUD documents such as LUD-06 and LUD-16; see ../../whitepapers/lnurl-primary-sources-2026-05-02.md.
  • Sources:

Internal linkages

  • Reusable-request contrast once the authority object becomes an offer and invoice-request flow instead of a callback URL: bolt-12

  • Naming-layer descendant once static payment identifiers get restated in a narrower BIP format: bip-353

  • Merchant stack that helped turn LNURL into default Lightning UX instead of a niche wallet feature: btcpay-server

  • Last reviewed: 2026-05-28 UTC

Graph View

Backlinks