Overview
A Lightning Service Provider (LSP) is an entity that operates Lightning Network infrastructure and provides channel management, liquidity, and connectivity services to end users. LSPs bridge the gap between the technical complexity of running a Lightning node and the simplicity that everyday users expect from a payment system. By handling channel opens, liquidity provisioning, and routing on behalf of users, LSPs make non-custodial Lightning wallets practical for people who cannot or do not want to manage their own node infrastructure.
The LSP model emerged as the Lightning Network matured and it became clear that expecting every user to run a full node, manage channels, and maintain liquidity was a barrier to adoption. Organizations like Lightning Labs and others have developed tools and protocols that enable the LSP ecosystem, allowing wallet developers to offer seamless Lightning experiences while preserving the self-custodial properties of the network.
How It Works
When a user opens a Lightning wallet backed by an LSP, the provider handles the heavy lifting of channel management behind the scenes. The typical flow looks like this:
User installs wallet
│
▼
LSP detects new user, opens a channel
(or uses an existing channel)
│
▼
LSP provides inbound liquidity
so the user can receive payments immediately
│
▼
User sends/receives payments
LSP routes and manages channels transparently
│
▼
If capacity runs low, LSP dynamically
opens new channels or splices existing ones
The LSP maintains well-connected nodes with substantial channel capacity, ensuring that payments to and from its users can be routed efficiently across the broader Lightning Network. When a user needs to receive a payment but lacks inbound liquidity, the LSP can open a just-in-time (JIT) channel or use channel splicing to add capacity without interrupting the user experience.
LSP vs. Custodial Services
A critical distinction is that LSPs are not custodians. The user's funds remain in Lightning channels secured by on-chain multisig transactions, and the user retains the ability to close channels and recover funds to their own on-chain wallet at any time. This differentiates LSPs from custodial Lightning wallets, where the provider holds the user's bitcoin and the user has only a promise, not a cryptographic guarantee, of access.
Custodial Wallet LSP-backed Wallet
┌──────────────┐ ┌──────────────────┐
│ Provider │ │ User holds keys │
│ holds keys │ │ in multisig │
│ │ │ channels │
│ User has IOU │ │ │
│ (trust req.) │ │ LSP provides │
│ │ │ liquidity & │
│ │ │ routing only │
└──────────────┘ └──────────────────┘
LSP Specification
The LSPS (Lightning Service Provider Specification) initiative aims to standardize how LSPs and wallets interact. These specifications define APIs for channel requests, liquidity purchases, and fee structures, enabling wallets to work with multiple LSPs interchangeably. Key specifications include LSPS0 (transport layer), LSPS1 (channel requests), and LSPS2 (just-in-time channels).
Trade-offs
While LSPs significantly improve usability, they introduce certain trade-offs. Users depend on the LSP being online and responsive for optimal payment routing. The LSP can observe payment metadata for channels it manages, which has privacy implications. Additionally, LSPs charge fees for their liquidity and channel management services, which are typically embedded in routing fees or charged as a one-time channel opening cost. Despite these trade-offs, the LSP model represents the most practical path toward non-custodial Lightning adoption at scale.
Related Concepts
- Lightning Network — the Layer 2 protocol that LSPs provide infrastructure for
- Lightning Channel — the payment channels that LSPs open and manage on behalf of users
- Liquidity — the key resource LSPs provision so users can send and receive payments
- Lightning Node — the software infrastructure LSPs operate at scale