LSPS Specifications: How Lightning Service Providers Are Standardizing
A breakdown of LSPS0, LSPS1, and LSPS2 — the specs standardizing how Lightning wallets and service providers exchange channels and liquidity.
For years, every Lightning Service Provider (LSP) shipped its own proprietary API for channel opens, liquidity requests, and submarine swaps, forcing wallet developers to build and maintain separate clients and error-handling logic per integration. The LSPS (Lightning Service Provider Specifications) initiative aims to replace this fragmentation with a common protocol layer that any LSP can implement and any wallet can integrate against once.
As of July 2026, LSPS0, LSPS1, and LSPS2 are the active specs. LSPS0 defines the transport layer, carrying JSON-RPC 2.0 over Lightning's existing custom_message mechanism (type 37913), so no new connections or auth schemes are needed — peers are already authenticated via the Lightning key exchange. LSPS1 covers the straightforward case of a client actively purchasing a channel through a get_info, create_order, on-chain payment, and order-polling flow.
The real complexity sits in LSPS2, which handles Just-in-Time channel opens — creating a channel in real time when a payment arrives for a wallet that doesn't have one yet. Now published as bLIP-52 in the BOLT process, LSPS2 directly addresses the inbound liquidity problem that blocks every new Lightning user's first payment. Understanding these specs matters for anyone building Lightning wallets, LSPs, or the infrastructure connecting them.