LNURL is a family of optional Lightning application flows described in LUD documents. It carries parameters and requests between wallet and service; it is neither a Bitcoin consensus rule nor one universal authorization.
LNURL includes payRequest for payments, withdrawRequest for withdrawals and login for authentication, alongside other extensions. Wallets implement different LUD subsets. “Supports LNURL” therefore does not mean every operation works or that approving them has the same effect. [LNURL — LUD index] [Lightning Labs — LNURL glossary]
Base LNURL under LUD-01 encodes an HTTPS or onion URL in Bech32. It is neither encryption nor a BOLT 11 invoice. The tag directly in the URL, or in the JSON response after GET, determines the type. The wallet must identify the domain and operation; QR appearance alone does not establish the recipient. [LNURL — LUD-01 encoding]
payRequest returns callback, minSendable, maxSendable and metadata. Limits and the chosen amount are in msat; 1000 msat is one satoshi. After conditions are approved, the wallet requests an invoice in pr and checks its amount before paying. A static link is not itself evidence of payment. [LNURL — LUD-06 payRequest]
Metadata is a string containing a JSON array with a required text/plain entry; other types are optional. Read the displayed description together with domain and amount. Base LNURL interprets the JSON body, not the HTTP code alone; ERROR or receipt of a pr invoice must not be confused with successful payment. [LNURL — LUD-01 encoding] [LNURL — LUD-06 payRequest]
withdrawRequest returns k1, callback and minWithdrawable/maxWithdrawable limits in msat. Your wallet creates a receiving invoice and submits it as pr to the service that should pay it. Status OK acknowledges the request; the wallet still waits for actual receipt. A withdrawal link can carry authorization, so do not treat it as a public payment contact. [LNURL — LUD-03 withdrawRequest]
LNURL-auth with tag login uses challenge k1 and a domain-specific linkingKey. After consent, the wallet signs using ECDSA on secp256k1; it does not send its seed to the service. Action can mean registration, login, linking or another authorization. Signing a challenge is neither a bitcoin payment nor automatic proof of a person’s identity. [LNURL — LUD-04 authentication]
HTTPS protects transport, but the service can know requests and their timing. Repeated uses may be linked. Auth derives a key from the full domain name; changing a subdomain changes linkingKey and can lead to a different account. Login portability between wallets is not guaranteed because derivation methods differ. LNURL itself does not determine bitcoin custody. [LNURL — LUD-01 encoding] [LNURL — LUD-04 authentication]
Optional LUD-21 adds a verify URL; its response distinguishes settled true/false and may return preimage. Status OK alone does not mean settled true. Check the association with the specific invoice and wallet state. After losing a response, do not blindly start another payment; service availability, receiving liquidity and consent scope remain separate conditions. [LNURL — LUD index] [LNURL — LUD-21 verification]
For the clearest picture, read this entry together with BOLT 11, BOLT 12, Lightning Network, Lightning Address, Bitcoin Privacy, Satoshi. The reverse links also lead from BOLT 12, Lightning Address.