lightning-service-provider-spec-primary-sources-2026-05-02

Lightning Service Provider Spec (LSPS) 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 archived working-group repository, the successor bLIPs, and LDK’s lightning-liquidity reference-implementation README.
• The materials show a clear migration path from a collaborative spec repo into the official bLIP process rather than project abandonment.

Primary-source snapshots

1) Working-group README and archival note

• URL: https://raw.githubusercontent.com/BitcoinAndLightningLayerSpecs/lsp/main/README.md
• Key excerpt:
  • The README says the goal is to provide a unified API specification for Lightning Service Providers so wallets/clients and LSPs can interoperate.
  • It also says the repository was archived on 2025-01-10 because the work moved to a bLIP-only process.
  • It explicitly maps LSPS0, LSPS1, and LSPS2 to bLIP-50, bLIP-51, and bLIP-52.

2) Previous full README

• URL: https://raw.githubusercontent.com/BitcoinAndLightningLayerSpecs/lsp/main/README_old.md
• Key excerpt:
  • The pre-archive README defines LSPS0 as the transport layer, LSPS1 as channel requests, LSPS2 as JIT channels, and LSPS5 as webhook registration.
  • It also defines spec maturity states of Draft, For Implementation, and Stable.
  • The listed providers and responsible-disclosure process reinforce that this was intended as an operational cross-implementation standard, not merely an internal design memo.

3) bLIP-50 / LSPS0

• URL: https://raw.githubusercontent.com/lightning/blips/master/blip-0050.md
• Key excerpt:
  • bLIP-50 defines LSPS0 as the transport layer for communication between LSP nodes and clients.
  • It says the protocol uses JSON-RPC over Lightning’s BOLT8 peer-to-peer transport.
  • It reserves Lightning message ID 37913 for LSPS messages.

4) bLIP-51 / LSPS1

• URL: https://raw.githubusercontent.com/lightning/blips/master/blip-0051.md
• Key excerpt:
  • bLIP-51 says the goal is to provide a standardized LSP API for wallets to purchase a channel directly from an LSP.
  • The spec defines a lsps1.get_info discovery step and lsps1.create_order purchase flow.
  • It also makes clear that both onchain and offchain payment paths can be part of a channel-order lifecycle.

5) bLIP-52 / LSPS2

• URL: https://raw.githubusercontent.com/lightning/blips/master/blip-0052.md
• Key excerpt:
  • bLIP-52 defines JIT channels as channels opened in response to an incoming payment from the public network.
  • It says this lets a client with no Lightning channels receive on Lightning and pay the inbound-liquidity cost from that first payment.
  • The spec discusses trust tradeoffs between client and LSP, which is a strong clue that LSPS is standardizing real wallet/LSP operating behavior rather than only message syntax.

6) Reference implementation

• URL: https://raw.githubusercontent.com/lightningdevkit/rust-lightning/main/lightning-liquidity/README.md
• Key excerpt:
  • The README says the goal of lightning-liquidity is to provide types and primitives to integrate a spec-compliant LSP with an LDK-based node.
  • It says the crate implements both client-side and service-side logic for bLIP-50, bLIP-51, bLIP-52, and bLIP-55.
  • It highlights LSPS5 webhook registration as important for signed push notifications that can wake offline mobile wallets.

Working conclusion

LSPS is best cataloged as Lightning wallet-to-LSP interoperability infrastructure: a practical standards stack for transport, channel purchasing, just-in-time inbound liquidity, and related notifications, with an explicit successor path into the Lightning bLIP process and a live reference implementation in the LDK ecosystem.