LNURL is a family of protocols built on top of the Lightning Network that bundle multi-step Lightning interactions into single URLs or addresses. The most widely deployed variants are LNURL-pay (allows anyone to send sats to a static endpoint), LNURL-withdraw (allows the holder of a code to pull sats from an issuer), LNURL-auth (cryptographic login without passwords), and LNURL-channel (request a Lightning channel from a service).

What is a Lightning address?

A Lightning address is a human-readable wrapper around LNURL-pay. It looks like an email address (you@yourdomain.com or you@wallet.com) and resolves under the hood to an LNURL-pay endpoint. Lightning addresses make it possible to receive Lightning payments without exchanging invoices each time.

How does LNURL-pay work technically?

The sender's wallet looks up the LNURL-pay endpoint, which returns metadata (callback URL, allowed amount range, optional commentAllowed). The sender's wallet then requests an invoice for a specific amount from the callback URL, receives a BOLT11 invoice, and pays it. The receiver's wallet generates the invoice on demand.

Why do most consumer Lightning wallets support LNURL?

Because the user experience is meaningfully better than raw BOLT11 invoices. With LNURL or a Lightning address, the receiver can publish a single static identifier and receive any number of payments. With raw BOLT11, every payment requires a fresh invoice exchange. The reduction in friction is what made LNURL the standard for receiving payments in modern Lightning wallets.

How does Rythm use LNURL?

Rythm uses LNURL-pay (typically wrapped as a Lightning address) as the destination for melt operations. When a user signs up, they configure their Lightning address. When a Cashu token arrives in their email, Rythm melts the token to that Lightning address, which routes the payment through the user's Lightning wallet of choice. The user controls the Lightning address and can change it at any time.

LNURL Standards: A Practical Reference

LNURL is a family of protocols built on top of Lightning. Here is the practical reference covering pay, withdraw, auth, channel, and how Rythm uses pay.

LNURL is a family of protocols built on top of Lightning that solves practical user-experience problems with raw Lightning invoices. The protocols are widely deployed in modern wallets and underpin most consumer-facing Lightning interactions in 2026. This post is the practical reference for what LNURL is, the variants you encounter, and how Rythm uses it.

Why LNURL Exists

Lightning’s native payment primitive is the BOLT11 invoice. A BOLT11 invoice is a string the receiver generates and gives to the sender. The sender pays the invoice. The invoice contains the amount, the recipient’s payment hash, an expiration time, and optional metadata.

The structural limitation: BOLT11 invoices are single-use. Each payment requires a fresh invoice. The receiver has to be online or to pre-generate invoices to give out. The invoice contains the amount, which means the receiver has to know what to charge before generating the invoice.

For interactive workflows where amount and timing are agreed in advance, BOLT11 works. For workflows where the sender wants to send any amount at any time without coordinating, BOLT11 is a poor fit. The receiver would have to generate an invoice every time they wanted to be paid, which does not scale to receive-money-from-the-internet use cases.

LNURL solves this by providing a static endpoint the sender can hit to dynamically request an invoice for a specific amount. The receiver publishes one URL; senders can pay any number of times.

The LNURL-pay Subset

LNURL-pay is the most widely used variant. It enables receive-money-by-URL workflows.

Static endpoint. The receiver publishes an LNURL-pay endpoint. The endpoint is a URL or a bech32-encoded version of one (the LNURL-encoded form).

Metadata response. When a sender hits the endpoint, the receiver responds with metadata: minimum and maximum payable amounts, a callback URL, optional fields like commentAllowed (whether the sender can include a text comment).

Invoice request. The sender’s wallet asks the callback URL for an invoice for a specific amount. The receiver generates a fresh BOLT11 invoice and returns it.

Payment. The sender’s wallet pays the invoice through normal Lightning routing.

The flow is two HTTPS requests plus the Lightning payment, which the wallet handles transparently. From the user’s perspective, they paste an LNURL or Lightning address, enter an amount, and hit send. The protocol handles everything else.

Lightning Addresses Are LNURL-pay With Better UX

A Lightning address is a wrapper around LNURL-pay using email-style notation.

Example. Suppose your Lightning address is you@example.com.

Resolution. A Lightning wallet seeing you@example.com knows to fetch https://example.com/.well-known/lnurlp/you to retrieve the LNURL-pay metadata.

Equivalent to LNURL-pay. Everything below the resolution layer is identical to raw LNURL-pay. The Lightning address is just a more memorable form.

The reason Lightning addresses became the dominant form is user-experience. People find email-like addresses easier to remember and share than long bech32 strings. Most consumer Lightning wallets (Wallet of Satoshi, Phoenix, Strike, Alby, Zeus, etc.) support Lightning addresses out of the box.

The Other LNURL Variants

LNURL-withdraw, LNURL-auth, and LNURL-channel are less common in consumer use but worth knowing about.

LNURL-withdraw. The opposite direction. Instead of the sender paying the receiver, the receiver presents a code that the holder can scan to withdraw a specific amount. Common use cases: faucets, withdrawals from custodial services, gift codes. The flow inverts who initiates the payment.

LNURL-auth. A cryptographic login system. The user’s Lightning wallet signs a challenge with a key derived from the wallet’s seed. The service verifies the signature. The user logs in without a password and without revealing their wallet’s actual identity. Limited adoption but elegant.

LNURL-channel. A request for the recipient to open a Lightning channel to the requester. Used by services that automate channel provisioning. Niche but useful for specific workflows.

For Rythm’s use case, only LNURL-pay matters. The other variants are not part of the email payment flow.

How Rythm Uses LNURL-pay

The Rythm payment flow:

User signup. The user configures their Lightning address. This is typically a Lightning address from any consumer Lightning wallet (wallet of satoshi, phoenix, strike, alby, etc.). Rythm stores the address; the wallet stays with the user.

Sender sends email. The sender includes a Cashu token in the email body (acquired from a public Cashu mint). The token is a bearer instrument.

Rythm parses the email. The token is detected in the email body during in-memory processing.

Rythm melts the token. The melt operation produces a Lightning payment. Rythm initiates a payment to the user’s configured Lightning address using LNURL-pay. The mint executes the underlying Lightning settlement.

Payment lands at the user’s wallet. The sats arrive at whatever wallet the user has the Lightning address connected to. The user controls the wallet and the address; Rythm only holds the address string used for delivery.

The user can change the Lightning address at any time. Rythm is not in the payment path; the LNURL-pay flow runs from mint to user wallet.

The Privacy Properties of LNURL-pay

LNURL-pay has specific privacy considerations.

The receiver sees the IP of the sender’s wallet. When a sender’s wallet hits the LNURL-pay endpoint, the receiver’s server sees the source IP. For privacy-sensitive senders, using a wallet that supports Tor or a privacy-focused proxy mitigates this.

The receiver does not see the sender’s identity. Only the IP. The Lightning payment itself is routed through the network and does not reveal the sender to the recipient.

The receiver can correlate multiple payments to the same Lightning address. The receiver knows that all payments to that address are for the same recipient. The sender may or may not be the same across payments.

The mint sees the melt operation but not who originally received the email. Rythm’s flow uses Cashu blinded signatures, so the mint does not see which token is being melted in the privacy-preserving sense. The mint sees a Lightning invoice it pays.

For most users, the privacy properties of LNURL-pay are sufficient. For users with stronger privacy requirements, additional measures (Tor, separate addresses per use case) are appropriate.

LNURL Wallet Support in 2026

Mainstream Lightning wallets support LNURL-pay. Examples:

Wallet of Satoshi. Custodial. Easy onboarding. Generates Lightning addresses for users. Common entry point.

Phoenix. Non-custodial. Strong privacy. Supports LNURL-pay and Lightning addresses.

Strike. Custodial. Fiat on-ramp. Lightning addresses available for paid accounts.

Alby. Browser-based. Custodial or non-custodial options. Strong support for LNURL.

Zeus. Wraps a self-hosted node (LND or other). Power user. Full LNURL support.

Mutiny. Browser-based, non-custodial. Modern interface. Full LNURL support.

The interoperability is good. A Lightning address generated by one wallet can receive from any wallet that supports LNURL-pay, which is most modern wallets.

What This Means for Rythm Users

Rythm users do not need to understand LNURL deeply. The practical implications:

Choose any Lightning wallet that gives you a Lightning address. Most consumer wallets do. The choice is about the wallet’s other properties (custodial vs non-custodial, fiat conversion, fees, UX), not about LNURL itself.

Configure the Lightning address in Rythm. One-time setup during onboarding.

Receive sats automatically when senders pay cover charges. The melt operation lands payments at the configured address.

Change the address whenever you want. If you switch wallets or generate a new address, update the Rythm setting and the new address starts receiving.

The user is in control. Rythm holds the address string for delivery; the wallet and the actual sats are the user’s own.

A Specific Honest Note

LNURL is the practical infrastructure that makes Lightning addresses work. Most Lightning users interact with LNURL-pay every time they send to a Lightning address, even if they do not know they are using it.

For Rythm users, the LNURL layer is the mechanism that lets cover-charge payments arrive at the user’s wallet without coordination per payment. The user picks the wallet, the wallet generates the address, Rythm melts to the address. Each payment routes through the user’s chosen Lightning infrastructure.

This is the non-custodial property in practice. Rythm never holds funds; the user’s wallet does. LNURL is what makes that delivery work without per-payment invoice exchange.

For the related guides, see the cashu protocol explained for email use cases, how Lightning Network solves the micropayment problem, why bearer tokens are the right primitive for email payments, and the non-custodial email stack. For the broader frame, see non-custodial architecture and what non-custodial means in 2026. Rythm is $1.65 per month, cancel anytime.