Lightning service provider
A Lightning service provider (LSP) is a Lightning Network node operator that sells inbound liquidity and related services to wallets, most commonly by opening channels toward the wallet so the wallet can receive payments. The role is an application-layer business on top of the Lightning peer protocol, not a consensus change.
A Lightning payment can only be received on a channel that already has bitcoin on the remote side (inbound capacity). A new wallet has no channels until some peer opens toward it or the wallet opens outbound and later receives. LSPs perform that operational work (on-chain fees, UTXO management, and staying online). Early providers each exposed a proprietary API. A common specification effort (originally LSPS) was later published as Bitcoin Lightning Improvement Proposals (bLIPs) in the lightning/blips repository.
LSPS protocols
The LSP and the wallet are ordinary Lightning peers. Service requests ride on the encrypted BOLT 8 transport as JSON-RPC 2.0 payloads (message type 37913), defined as LSPS0 / bLIP 50. LSPS1 / bLIP 51 standardizes purchasing a channel (order, payment, open, refund on failure). LSPS2 / bLIP 52 standardizes Just-in-time channel opens: the LSP intercepts an incoming HTLC, opens toward the wallet (often zero-conf), and forwards the payment minus an opening fee. LSPS5 / bLIP 55 registers HTTPS webhooks so a usually offline mobile wallet can be notified of activity. Related tools for channel capacity include Dual funding and Splicing. An LSP is a liquidity counterparty, not a custodian of the wallet's channel keys when the wallet holds them. Receiving still depends on the LSP's willingness to extend inbound capacity and on the LSP's own outbound routes. Watchtower services are a separate always-on watcher role; some hosts combine both functions.
Wallets typically discover an LSP through an application default, a QR or deep link, or a manual node id. After LSPS0 negotiation the wallet can buy a channel with LSPS1, request JIT receives with LSPS2, or register push notifications with LSPS5. Fees may be quoted as a flat opening charge, a basis-point cut of the first payment, or a recurring liquidity lease, depending on the provider and the bLIP used.
bLIP documents evolve independently of BOLTs. Wallets should treat unknown LSPS methods as optional and fall back to manual channel opens when negotiation fails.
Counterparty role
An LSP that also routes payments for other users is still subject to ordinary Lightning channel risk, including jamming and unbalanced liquidity. Choosing among multiple LSPs can reduce dependence on a single inbound peer. Specifications do not require the LSP to custody the client's long-term keys. Custody products that hold keys for the user are a different trust model even when they market Lightning receive services.
Marketing that calls an LSP a bank or custodian is describing a different product. A non-custodial LSP still chooses whether to sell inbound liquidity and can close or refuse channels like any other peer.