lightning-service-provider-spec

Lightning Service Provider Spec (LSPS)

• Name: Lightning Service Provider Spec (LSPS)
• URL: https://github.com/BitcoinAndLightningLayerSpecs/lsp
• Category: Lightning interoperability specification / wallet-to-LSP protocol / channel-liquidity standard
• Tags: bitcoin-ecosystem
• Summary: LSPS is the wallet-to-LSP handshake. The value is the narrow interoperability layer — JSON-RPC over BOLT8, channel-buy flows, JIT inbound setup, and wake-up/webhook plumbing — not a grand Lightning architecture.
• What it does:
  • Defines LSPS0, a transport layer for client-LSP communication using JSON-RPC over Lightning’s BOLT8 peer-to-peer transport
  • Defines LSPS1, a standard API for wallets or clients to purchase channels directly from an LSP
  • Defines LSPS2, a just-in-time channel flow that lets clients receive an inbound payment and have channel-opening fees deducted from that payment
  • Previously grouped LSPS5 webhook registration alongside the core specs in the working repository, covering signed push-style notifications for offline clients
  • Points implementers to current canonical bLIP versions and a real reference implementation in the lightning-liquidity crate for LDK-based nodes
• Key claims:
  • The working-group README says the goal of the repository is to provide a unified API specification for LSPs so different Lightning wallets/clients and LSPs can interoperate
  • The archival note says the repository was archived in January 2025 because the work continued as a bLIP-only process, and it maps LSPS0/1/2 to bLIP-50/51/52 respectively
  • The previous full README defines an explicit maturity ladder of Draft, For Implementation, and Stable, which is a clue that LSPS was built as a practical cross-implementation standard rather than just a discussion draft
  • bLIP-50 says LSPS0 uses JSON-RPC carried over BOLT8 peer-to-peer messages and reserves Lightning message ID 37913 for the transport tunnel
  • bLIP-51 says LSPS1 exists to provide a standardized LSP API for wallets to purchase a channel directly from an LSP
  • bLIP-52 says LSPS2 enables a client with no Lightning channels to receive its first payment by having the LSP open a just-in-time channel and deduct channel-opening fees from the incoming payment
  • The lightning-liquidity README says the crate provides both client-side and service-side logic for LSPS specs, supports bLIP-50/51/52/55, and is meant to integrate a spec-compliant LSP with an LDK-based node
  • That same reference-implementation README highlights LSPS5 webhook support as important for waking suspended mobile wallets, which shows LSPS is trying to standardize real operational behavior beyond a narrow purchase API
• Whitepaper: No canonical standalone LSPS whitepaper or litepaper surfaced in this pass. The specification repository, successor bLIPs, and the lightning-liquidity reference implementation were the clearest current primary sources; see ../whitepapers/lightning-service-provider-spec-primary-sources-2026-05-02.md.
• Sources:
  • https://raw.githubusercontent.com/BitcoinAndLightningLayerSpecs/lsp/main/README.md
  • https://raw.githubusercontent.com/BitcoinAndLightningLayerSpecs/lsp/main/README_old.md
  • https://raw.githubusercontent.com/lightning/blips/master/blip-0050.md
  • https://raw.githubusercontent.com/lightning/blips/master/blip-0051.md
  • https://raw.githubusercontent.com/lightning/blips/master/blip-0052.md
  • https://raw.githubusercontent.com/lightningdevkit/rust-lightning/main/lightning-liquidity/README.md

Internal linkages

• Reference implementation where the spec becomes running wallet logic: lightning-dev-kit
• Operator-facing packaging of the same handshake: blocktank and breez

Governance / control risk

• Standardized requests do not remove operator leverage. The chosen LSP still controls pricing, admission, webhook reliability, and the actual terms of inbound liquidity.

• Last reviewed: 2026-05-26 UTC