Lightning service
A Lightning service provider (LSP) is an operator that supplies channel liquidity and connectivity to users of the Lightning Network. An LSP normally runs one or more Lightning nodes and opens or manages payment channels for clients that do not manage every operational step themselves. The term describes a service role, not the Lightning protocol or a particular node implementation.[1]
LSPs are often integrated into wallets, but an LSP and a wallet are not necessarily the same entity. A self-custodial wallet can use an LSP while the user retains control of the keys to the user's side of a channel. A custodial wallet or payment processor can also provide Lightning access, but in that model the provider controls customer balances. The label LSP alone therefore does not establish whether a product is custodial.[2]
Role in the Lightning Network
Lightning channels have directional liquidity. A user can send only from the balance on the user's side of a channel and can receive only when enough balance is available on the remote side. A new wallet may therefore hold bitcoin but lack the inbound liquidity needed to receive a Lightning payment.
An LSP can address this by allocating its own capital to a channel with the client. The provider becomes the client's direct Lightning peer and supplies inbound capacity; payments still depend on usable routes between the provider and the rest of the network. The provider may recover on-chain funding costs, the cost of committed capital, and operating expenses through channel-opening, service, or routing fees. An LSP does not remove the Lightning Network's broader liquidity and routing constraints.
LSPs should be distinguished from Lightning implementations. LND, Core Lightning, Eclair, and the Lightning Development Kit are software used to operate Lightning nodes or build wallets. An organization may use one of these implementations to offer an LSP service, but the software itself is not necessarily a service provider.
Service models
Purchased channels
A client can purchase a channel before receiving a payment. The active LSPS1 specification, published as bLIP 51, defines an API through which a wallet obtains an offer, creates and pays for an order, and asks the LSP to open a channel. The specification explicitly notes that the purchase is not atomic: a client must trust the provider to deliver the promised channel or refund a failed order.[3]
Just-in-time channels
A just-in-time (JIT) channel is opened in response to an incoming payment. Under LSPS2, published as bLIP 52, the payment is routed to the LSP, which opens a channel to the recipient and forwards the payment after deducting the agreed opening fee. This lets a client with no existing channel begin receiving over Lightning without purchasing inbound capacity in advance.[4][5]
JIT channels can use zero-confirmation channel techniques, so the first payment may be delivered before the funding transaction has confirmed. This improves onboarding speed but creates additional trust and funding-transaction risks that depend on the negotiated model. The LSPS2 offer includes fee limits, validity periods, and a promised minimum channel lifetime.
Swaps and liquidity management
Some providers exchange on-chain and off-chain bitcoin using submarine swaps. A swap can add outbound liquidity, release inbound liquidity, or move funds between Lightning and the Bitcoin blockchain without closing every affected channel. These services solve a different problem from purchasing a new channel and may be offered independently of an LSP relationship.
Wallet-server functions such as encrypted backups, payment notifications, reusable payment identifiers, hosted-node administration, and watchtower monitoring are also related services. They do not themselves make an operator an LSP, although a single provider may combine several functions.[6]
Interoperability
Early LSP integrations often used provider-specific APIs. The Lightning Service Provider Specifications were developed so wallets and service providers could implement common request and response formats. In January 2025, development moved from the original LSP specification repository to the Bitcoin Lightning Improvement Proposal process.[7]
The active specifications include:
- LSPS0 / bLIP 50, a transport and discovery layer that carries JSON-RPC messages over the Lightning peer-to-peer transport;[8]
- LSPS1 / bLIP 51, for purchasing a channel directly; and
- LSPS2 / bLIP 52, for negotiating a JIT channel when an incoming payment arrives.
Support for one specification does not imply support for every LSP service. Wallets and providers can also use proprietary APIs or other liquidity mechanisms.
Trust, privacy, and operational trade-offs
In a noncustodial arrangement, the client controls the keys needed to spend its channel balance, while the LSP controls its own side of the channel. This is different from depositing bitcoin with a custodian. Nevertheless, the client may depend on the provider to open a correctly sized channel, honor quoted terms, remain reachable, forward payments, and avoid closing the channel earlier than expected. The precise obligations differ between service protocols and implementations.
An LSP is also the client's immediate network peer. It can observe the client's node connection and information about payments it forwards, although Lightning's onion routing ordinarily prevents an intermediate node from learning an entire multi-hop route. Research on Lightning privacy has shown that public network information and routing behavior can reveal information intended to remain private, so neither Lightning nor an LSP should be described as guaranteeing anonymity.[9]
Using a service can simplify channel management while concentrating connectivity or liquidity around a small number of operators. Wallets that allow users to change providers, use more than one provider, or manage channels directly reduce dependence on a single service.[6]
Fees and reliability depend on the provider and current network conditions. A service fee may be charged in addition to Lightning routing fees and the on-chain cost of opening or closing a channel. A channel supplied by an LSP guarantees neither a complete route to every recipient nor permanent availability.
See also
External links
- Bitcoin Lightning Improvement Proposals
- Archived Lightning Service Provider Specifications repository
References
- ↑ Lightning Service Provider, Lightning Labs Builder's Guide, accessed 3 September 2026.
- ↑ Lightning services, Bitcoin Design Guide, accessed 3 September 2026.
- ↑ bLIP 51: LSPS1 Channel Requests, Lightning specifications repository, accessed 3 September 2026.
- ↑ bLIP 52: LSPS2 JIT Channel Negotiation, Lightning specifications repository, accessed 3 September 2026.
- ↑ Just-In-Time channels, Bitcoin Optech, accessed 3 September 2026.
- ↑ 6.0 6.1 Lightning services, Bitcoin Design Guide, accessed 3 September 2026.
- ↑ Lightning Service Provider Spec repository, archived 10 January 2025; accessed 3 September 2026.
- ↑ bLIP 50: LSPS0 LSP Spec Transport Layer, Lightning specifications repository, accessed 3 September 2026.
- ↑ An Empirical Analysis of Privacy in the Lightning Network, H. Yousaf et al., Financial Cryptography and Data Security, 2021.