Relay-LSP: Non-Custodial Lightning on Nostr

We should all be operators. One day we will be.

Jared Logan

21. Mai 2026May 21, 2026 · 18 Min. Lesezeit18 min read

Relays as Lightning Service Providers

Identity announces. Infrastructure operates. Custody stays with the user.

This is a living document as I am drafting and crafting thoughts and ideas. It will change over time, or it may not. For now, it's purpose is to help me organize thoughts, in the open, and ideally spur discussion. LLMs are used in this journey.

Latest: 2026.05.20

Lightning onboarding on Nostr is bad enough that your Nostr identity keys are now being treated as Bitcoin spending keys. They shouldn't have to. The convenience that motivates "npub-derived on-chain wallets" is real but the trade is terrible, and the right alternative is buildable today out of pieces that are mostly already shipping.

This is a vision document for what I'm calling "Relay-LSP": a Nostr relay operator that also runs a Lightning Service Provider, exposed to clients over NIP-47 Nostr Wallet Connect, with the user's Lightning keys generated and held on the user's device. It is the Lightning sibling to NIP-SP, which solves the same problem on the on-chain rail using Silent Payments. Together they cover the full payment surface a Nostr user needs — easy public Lightning payments, private self-custodied on-chain payments, neither derived from your identity key, neither custodial by default.

The principles are the same as everything else I'm building toward. Identity announces a payment endpoint. The infrastructure to receive on that endpoint is operated by someone else. Custody of the keys that can spend stays with the user. The boundary between operational trust (acceptable) and custodial trust (not acceptable) is enforced by the protocol, not by the operator's promises.

The wrong-turn answer that needs replacing#

The npub-derived wallet pattern (generating a Bitcoin spending key deterministically from a Nostr identity key) emerges from a real and legitimate frustration: Lightning onboarding is annoying, custodial wallets are easy, and users will choose easy over correct every time they are forced to choose. The pattern ships a permanent, enumerable, identity-linked on-chain address. It reuses the social key as a spending key, the worst-case privacy and key-security pattern, in exchange for the convenience of zero setup.

The convenience is the only legitimate motivation. The convenience is also fully achievable without any of those tradeoffs, by delivering non-custodial Lightning on the rail it actually belongs to with a Nostr-native onboarding flow. The detour exists because nobody has shipped the polished version of the correct answer yet. Most of the pieces are deployed; what's missing is the integration and the policy expectations between user and operator.

This document specifies how those pieces compose.

Principles#

These are inherited from the broader trust-inversion thesis I'm building toward in nostr-station and nostrOS, applied to the payment layer:

Identity announces; never generates. The npub is the handle. It is never used to derive a payment endpoint, a wallet key, or a node identity. All payment endpoints are independently generated and published under the identity. The identity layer announces; the payment layer operates on its own keys.

Custody stays with the user. The user's client holds the Lightning signing keys. The Relay-LSP holds channels, liquidity, and uptime — never funds it cannot prove the user authorized. There is no scenario in which the operator can spend on the user's behalf.

Operational trust is acceptable; custodial trust is not. A Relay-LSP can refuse to route, force-close a channel, or go offline. It cannot steal, sign, or impersonate. That boundary is not a feature of any particular operator's morals; it is what the protocol allows and forbids.

Pluralism is structural. A user must be able to choose, switch, or self-host their Relay-LSP without losing their npub, contacts, or social graph. A single dominant operator is a failure mode, and the spec is responsible for ensuring it doesn't become one.

Public rails stay public; private rails stay private. Lightning zaps (NIP-57) are public-by-design — that is their entire point. NIP-SP on-chain payments are silent-by-design. Relay-LSP does not blur this line. A user's profile carries both endpoints; the sender chooses the rail with full knowledge of the privacy properties of each.

The user journey#

A new user installs a Nostr client. The client generates a Nostr keypair on-device and walks through profile setup. As part of that flow, it offers Lightning onboarding as a single optional step.

If accepted:

  1. The client generates a Lightning wallet locally — LDK, Greenlight, Phoenix-style, whatever the client embeds. Keys held by the user.

  2. The client connects, over NIP-47, to a Relay-LSP. By default the relay the user already selected; alternatively any other operator the user picks.

  3. The Relay-LSP provisions inbound liquidity (a JIT channel or equivalent) and issues the user a Lightning address at its domain — handle@relay.example.com.

  4. The client writes the address into the user's kind:0 profile metadata as lud16, alongside any other payment fields the user has configured (NIP-SP's sp_address for on-chain, etc.).

  5. The user is now zappable, non-custodial, and ready. Elapsed time comparable to filling in a username and avatar.

Subsequent payments use the existing flows. A sender's client resolves the recipient's lud16 from profile metadata, requests a BOLT11 invoice from the Relay-LSP, and pays it. Zap receipts (kind 9735) are published as today.

Architecture#

+--------------------+      NIP-47 (NWC)     +---------------------+
|   User's Device    | <-------------------> |     Relay-LSP       |
| (holds LN keys)    |   encrypted RPC       | (channels, routing, |
|                    |                       |  uptime, liquidity) |
+--------------------+                       +---------------------+
        |                                              |
        | publishes lud16 in kind:0                    | issues lud16
        | publishes sp_address in kind:0 (NIP-SP)      | at its domain
        v                                              v
+--------------------------------------------------------------+
|                      Nostr Relays                            |
|       (profile metadata, zap receipts, NWC transport)        |
+--------------------------------------------------------------+
                              |
                              v
                     +-----------------+
                     | Lightning Network|
                     +-----------------+

The user's device holds the Lightning private keys (in the client today, in OS-managed hardware custody on nostrOS) and signs invoices and payments locally. The device is the source of truth for the user's balance.

The Relay-LSP runs Lightning node(s), provides inbound liquidity, routes payments, and serves the user's lud16 endpoint. It sees payment metadata (it is the recipient's entry point) but cannot move funds without the user's signature. NIP-47 is the transport between them — encrypted RPC, not custody.

Nostr relays carry the profile metadata, zap receipts, and the NWC transport. A Relay-LSP is also a Nostr relay in the canonical deployment, but the two roles can be separated: a relay operator may provide LSP service for users on other relays, and vice versa.

What's already deployed#

This is composition, not invention. Most of the pieces ship today:

Component Status
lud16 in kind:0 profile metadata Deployed, standard
NIP-47 (Nostr Wallet Connect) Deployed, in use
LSPs (Phoenix, Breez, Olympus, Alby Hub) Mature and growing
On-device LN wallets (LDK, Greenlight) Mature
NIP-SP (on-chain sibling) Draft/Proposed

The novel work is integration and policy. Making LSP service first-class to relay operators. Exposing it over NWC with consistent discovery. Standardizing the trust expectations between user and operator. Building the client UX so a new user genuinely experiences this as a single tap.

Trust boundaries — what the operator can and cannot do#

The Relay-LSP can:

The Relay-LSP cannot:

This is the non-custodial standard. It is the same trust model that Phoenix and Breez already deliver today. What this document standardizes is the expression of that model inside the Nostr ecosystem, with the relay layer as the natural deployment vector.

The honest tradeoffs#

Three things deserve more weight than a typical vision document gives them.

The Relay-LSP is a metadata surveillance point. It cannot steal your money, but it sees the payment graph keyed to your npub — every inbound zap, every sender, every amount, every timestamp. A self-hosted Lightning node avoids this; using any LSP, custodial or not, accepts it. Tor wiring on the user side hides location and ISP from the LSP; it does not hide the payment graph itself. Users who require payment-graph privacy should self-host. Users who don't can choose an operator whose privacy policy they trust, knowing that the trust is operational, not custodial.

Force-closure recovery is the actual UX cliff. The pitch of "non-custodial Lightning onboarding" sells a smooth experience. The day a Relay-LSP goes bad — shutdown, hostile force-close, data corruption — the user has to recover funds via on-chain transactions with a multi-day timelock. Clients shipping Relay-LSP support MUST ship explicit force-close recovery flows. The spec MUST define what backup data the user retains, where their on-chain UTXOs land, and how recovery proceeds. If this cliff is scary enough, users will rationally choose custodial wallets despite the trust cost, and the whole design fails. Solving force-closure UX is not a footnote.

Liquidity economics matter. JIT channels cost money. A user receiving their first 5,000 sat zap might find the Relay-LSP took 1,000 sats in liquidity fees, which feels worse than a custodial service that hides the cost. Operators have to be honest about liquidity pricing, clients have to surface it without scaring new users, and the ecosystem has to find a sustainable economic model. This is a real product problem and the spec doesn't get to wave it away.

Pluralism only has teeth if migration is genuinely easy. Migration involves closing channels with the old operator, opening with a new one, and republishing lud16 — operationally non-trivial. If migration takes 30 minutes of attention and 3,000 sats of on-chain fees, pluralism in principle becomes lock-in in practice. Clients MUST ship guided migration flows; the spec SHOULD define the migration contract; ecosystems that grow around Relay-LSP SHOULD prioritize operator-portability tooling as much as they prioritize onboarding.

Relationship to other specs#

The shape mirrors [NIP-SP](Relays as Lightning Service Providers) deliberately: the identity layer announces the endpoint; the payment layer operates on its own keys.

How this fits with nostr-station and nostrOS#

This is a sibling document to nostrOS and nostr-station implementation work. nostrOS is the substrate (a sovereign nsite-native operating system, with hardware-rooted identity and OS-mediated capability brokering); Relay-LSP is one of the payment-layer services that sit on top.

The connection points are clean:

None of this is required for Relay-LSP to work. It can ship on stock devices via Phoenix-style mobile apps and any Nostr web client. nostrOS just happens to make it stronger.

What this is not#

To be specific about the boundaries:

Open questions#

These are the parts most worth arguing with:

  1. Discovery without centralization. How do clients enumerate available Relay-LSPs at onboarding without hard-coding a list? Likely answer: a NIP for self-advertisement events, with client-side filtering and reputation surfaces.

  2. Honest liquidity pricing. How is the cost surfaced without driving users back to custodial alternatives that hide it?

  3. Force-closure recovery UX. What does a tested, polished recovery flow look like? What backup data does the user retain?

  4. Reputation and accountability. How do users evaluate operators without that evaluation centralizing into a few "trusted" lists?

  5. Operator economics. What sustains a relay operator running an LSP? Channel fees alone? Optional subscriptions? Bundled with relay paid-relay models?

  6. Composition with NIP-SP. When a user has both lud16 and sp_address, how do sender clients present the rail choice? This is a UX question with privacy implications.

A Unique Standing#

Shocknet's Lightning.Pub is the nearest thing. It's a "Nostr Native Lightning node" that uses commodity Nostr relays as transport with NIP-44 encryption, and bundles a bootstrap liquidity provider that "provides initial channel funding as a service credit until you can afford your own channels". Critically — and this is where it differs from this concept — Lightning.Pub is the "Uncle Jim" model: a node-runner shares their node with friends/family. This concept is the inverse: the relay operator provides LSP service to many users whose keys live on-device. Different shape, overlapping primitives. They also pushed their own NIP-68 Lightning Debit Requests explicitly because "NWC UX is failing people bigly today" — worth a read, as thread is exactly the discourse this is entering.

Alby Hub is the most mature reference implementation of the user side of this stack. "A self-sovereign lightning wallet... powered by a full lightning node with 1-click channel management," running an embedded LDK node or remote LND, exposed over NWC. Alby Cloud hosts it for a monthly fee; Start9 and Umbrel let you self-host. They formally partnered with LQWD as their LSP. So the Alby Hub + LQWD pairing is essentially what Relay-LSP describes, minus the relay-operator role — LQWD is a pure-play LSP business, not a relay operator. Alby is also publicly thinking about L2s like Spark and Ark to bring NWC to "more casual, less technical and beginner users", which is the same wedge this is aiming at from a different angle.

Voltage sells managed self-custodial Lightning nodes wired to Nostr — same idea, classic SaaS posture, no relay integration story.

Nobody has framed the relay operator as the natural LSP. Lightning.Pub assumes a node-runner. Alby/Voltage assume a cloud provider. This concept is the first I can find that says the operator who already runs your relay should also be the operator who provisions your liquidity. That's a real architectural claim with consequences (pluralism, censorship resistance, NIP-65 relay choice flowing into payment choice).

The "operational trust vs custodial trust" framing is sharper than what the field is using. Alby and Shocknet both say "self-custodial" and then ship complicated trust models around channel backups, recovery, and JIT trust.

The composition with NIP-SP is genuine. No one else is publishing a paired Lightning + on-chain-private-by-default spec under one identity-announces principle. That's the differentiator.

Closing#

The on-chain-zap detour is a symptom of unsolved Lightning onboarding. Solve onboarding correctly — non-custodially, with the Nostr identity layer doing only what identity layers should do — and the detour loses its reason to exist. Pair Relay-LSP with NIP-SP and the entire payment surface a Nostr user needs is covered: easy public payments on Lightning, private self-custodied payments on-chain, neither derived from the identity key, neither custodial by default.

The principle is worth saying twice, because it applies more places than just payments:

> Identity announces. Infrastructure operates. Custody stays with the user.

That is how the broader sovereign-Nostr stack should be built. Relay- LSP is one application of it. NIP-SP is another. The same shape will recur at the storage layer, the social-graph-backup layer, and anywhere else where the convenient-but-wrong pattern is "derive from npub."

If you operate a relay and are interested in adding LSP service to it, get in touch — the missing piece is operator commitment, and a small number of committed operators is enough to make this real.

A relay is a websocket server with a database. An LSP is a Lightning node with inbound liquidity and uptime. There's no protocol-level reason one operator can't be both, and these specs are explicitly designed for that composition. nostr-station already ships the relay half (in-process, SQLite, loopback-bound). Adding LSP service is "embed an LDK or CLN node, expose NWC, provision channels" — every component exists.

In practice, the gap between "I run a relay" and "I run an LSP for myself" is small. The gap between that and "I run an LSP for others" is large. The threshold matters because the pluralism principle depends on the latter being viable for many operators, not just the former.

Self-LSP (relay + LSP for your own npub only):

Relay-LSP for others (this document as written):

The interesting middle: self-hosted nostrOS device as its own Relay-LSP. This is where the spec gets philosophically clean. If nostrOS ships hardware-rooted Lightning keys (as the spec implies in the "Hardware-rooted custody extends naturally to Lightning keys" section), and the device runs its own relay (as nostr-station already does), then a single user device is its own everything: identity, relay, LSP, on-chain wallet, and other stuff. The operator/user distinction collapses. No metadata surveillance because nobody else is in the loop. The full trust-inversion thesis lands at one box.

The catch is that "be your own LSP" only works if you can be your own Lightning node — which means inbound liquidity (someone opens a channel to you), uptime (you need to be online to receive), and bootstrap capital. The Lightning network doesn't have a "just receive payments with no setup" mode without an LSP somewhere in the picture. So the truly sovereign nostrOS device is still going to bootstrap from someone else's LSP for its first inbound channel, even if it eventually runs its own.

Companion documents:

All of these (including this one) are related, living pieces of documentation and/or products. These articles and documents and project will shift as this multi-faceted effort continues.

#bitcoin#freedom tech#lightning#lsp#nip-47#nostr#nwc#payments#self-custody#sovereignty#zaps

Written by

Jared Logan

catholic. american. husband and father. here for the revolution. avid note taker. eternal optimist. photographer, videographer, and ux designer. self-taught fisherman and banjo player.

Comments

No comments yet. Start the conversation.

Contents

13 sections

  1. The wrong-turn answer that needs replacing
  2. Principles
  3. The user journey
  4. Architecture
  5. What's already deployed
  6. Trust boundaries — what the operator can and cannot do
  7. The honest tradeoffs
  8. Relationship to other specs
  9. How this fits with nostr-station and nostrOS
  10. What this is not
  11. Open questions
  12. A Unique Standing
  13. Closing