An LSP is a counterparty and service provider, not part of Bitcoin consensus; a client can hold its own keys but must assess price, availability, channel terms, and the specific trust model of the LSPS protocol in use.
A Lightning Service Provider deploys its own or acquired liquidity for clients. Most often it opens a channel toward a non-custodial wallet to provide inbound capacity, or bridges on-chain and off-chain funds with a swap; it charges for block space, capital, operations, and risk. [1]
Lightning channel capacity is fixed and divided between local and remote balance. A new wallet without a channel therefore cannot receive an ordinary Lightning payment merely by creating an invoice; an LSP can supply inbound liquidity without making the user select a peer, UTXO, and funding transaction parameters manually. [1]
LSPS0, now bLIP 50, standardizes client-to-LSP communication as JSON-RPC 2.0 over Lightning BOLT8 peer-to-peer transport. Every LSPS message uses message ID 37913, and lsps0.list_protocols returns the exact list of supported extensions; the LSP label alone therefore does not guarantee every service. [2]
LSPS1, or bLIP 51, standardizes a direct channel order. The client reads the offer, creates an order, checks capacity, price, and expiry, then pays on-chain or over Lightning; the specification explicitly says the purchase is not atomic and the client trusts the LSP to deliver the promised channel after payment or issue the prescribed refund. [3]
LSPS2, or bLIP 52, covers a just-in-time channel. The client obtains parameters and puts a route hint carrying the request identifier into an invoice; when the incoming payment reaches the LSP, it opens a zero-confirmation channel, deducts the opening fee, and forwards the remainder. The client must be connected at that moment. [4]
A non-custodial LSP does not hold the client's private keys and leaves the client its side of the channel, yet an operational dependency remains. The provider sees the direct connection and part of the payment flow, may refuse new liquidity, change pricing within an offer, or be offline; a zero-confirmation channel and a prepaid order also have different risks. [1]
The LSPS0, LSPS1, and LSPS2 standards moved from the original repository into the bLIP process as active bLIP 50, 51, and 52. The lightning-liquidity reference library implements LSPS1 and LSPS2 client handlers and an LSPS2 service handler, but a particular wallet or node may support only a subset with its own commercial terms. [5]
Before use, verify the LSP node ID and connection string, the lsps0.list_protocols result, exact capacity and balance split, fee, expiry, confirmation count, and refund policy. After opening, check the funding transaction, channel state, and actual inbound capacity; a provider logo or successfully created invoice proves none of these properties. [2]
For the clearest picture, read this entry together with Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. The reverse links also lead from Just-in-Time Channels, Trampoline Routing, Bitlifi.
01Is a Lightning Service Provider automatically custodial?+
No. An LSP can open a channel to a wallet that holds its own keys and manages only its side of the channel. The client still depends on its availability, liquidity offer, and fulfillment of the specific order.
02Can an LSP receive a first payment without a previous channel?+
Yes, if both wallet and provider support LSPS2 and the payment covers the required opening fee. The LSP opens a JIT channel when the payment arrives and deducts the fee; this is neither free nor unconditional inbound capacity.