Glossary

Lightning Service Provider (LSP)

A service that manages Lightning channels and liquidity on behalf of users, enabling seamless mobile wallet experiences.

Key Takeaways

  • A Lightning Service Provider (LSP) deploys inbound liquidity and manages payment channels on behalf of users, similar to how an ISP provides internet connectivity. Users retain full self-custody of their funds.
  • LSPs enable seamless mobile wallet experiences by handling channel opening, routing, zero-conf channels, and just-in-time (JIT) liquidity provisioning behind the scenes.
  • The LSP specification (LSPS) defines interoperable standards so wallets can switch between providers. These specs have been migrated to the bLIP process as of early 2025.

What Is a Lightning Service Provider?

A Lightning Service Provider (LSP) is an entity that operates Lightning Network infrastructure on behalf of end users. LSPs open payment channels, allocate liquidity, route payments, and handle the operational complexity of running a Lightning node: all while users retain custody of their own keys and funds.

The Lightning Network requires users to have open payment channels with sufficient inbound liquidity to receive payments. For most users, especially those on mobile devices, managing channels, monitoring the blockchain, and maintaining uptime is impractical. LSPs solve this by acting as always-on infrastructure partners that handle the plumbing behind easy-to-use Lightning wallets.

The concept draws a direct parallel to Internet Service Providers: you do not need to understand TCP/IP routing to browse the web, and you should not need to understand HTLCs or channel capacity to send a Lightning payment. For a deeper exploration, see the Lightning Service Providers explained research article.

How It Works

LSPs provide several interconnected services that abstract away Lightning's channel-based architecture from end users.

Channel Opening and Inbound Liquidity

The most fundamental LSP service is opening channels toward users and pre-allocating Bitcoin as inbound liquidity. Without this, a new user cannot receive any Lightning payments. The process works as follows:

  1. A user installs a wallet connected to an LSP
  2. The LSP opens a payment channel to the user, committing its own Bitcoin as capacity
  3. The user can immediately receive payments up to the channel capacity the LSP allocated
  4. As the user sends payments, their local balance decreases and their inbound capacity increases
  5. The LSP monitors channel health and may splice additional liquidity as needed

Just-in-Time (JIT) Channels

JIT channels are the innovation that makes Lightning wallets feel instant. When a payment arrives for a user who does not yet have a channel, the LSP intercepts the incoming HTLC, opens a zero-conf channel on the fly, and forwards the payment through the new channel: all in seconds. The channel opening fee is deducted from the incoming payment amount.

This approach means users never need to think about channels at all. Their first received payment triggers channel creation automatically.

Routing and Payment Forwarding

LSPs maintain well-connected nodes with many channels across the network, acting as routing hubs. When a user sends a payment, the LSP finds efficient routes using techniques like trampoline routing (offloading pathfinding from resource-constrained mobile devices) and multipath payments (splitting large payments across multiple routes). The LSP earns routing fees for forwarding payments through its channels.

The LSP Specification (LSPS)

To ensure wallets can work with any LSP rather than being locked into a single provider, the community developed the LSPS specification suite. Originally maintained in a dedicated repository, these specs migrated to the bLIP (Bitcoin Lightning Improvement Proposals) process in January 2025. The active specifications include:

SpecbLIPPurpose
LSPS0bLIP-50Transport layer: JSON-RPC 2.0 over BOLT8 peer messages (message ID 37913)
LSPS1bLIP-51Channel requests: clients order channels with specific parameters from an LSP
LSPS2bLIP-52JIT channel negotiation: on-demand channel opening when payments arrive
LSPS5bLIP-55Webhook registration: push notifications to wake mobile apps

LSPS2 defines the fee formula for JIT channel openings as: opening_fee = max(min_fee_msat, ceil(payment_size_msat * proportional / 10,000,000)). This allows LSPs to cover on-chain costs while keeping fees proportional to payment size.

Notable LSPs

Several LSPs serve the Lightning ecosystem, each with different approaches:

  • ACINQ (Phoenix): pioneered splicing-based channel management with a single dynamic channel per user that resizes on the fly, replacing their proprietary protocol with open BOLTs for dual funding, splicing, and liquidity ads
  • Breez: offers an embeddable SDK built on LDK that bundles LSP connectivity, allowing third-party developers to add Lightning support without building infrastructure
  • Voltage: enterprise SaaS platform with cloud-hosted nodes, APIs, and automated liquidity management for businesses
  • Lightspark: enterprise-grade infrastructure with AI-driven liquidity management and UMA (Universal Money Address) for compliance-aware cross-border payments

Business Models

LSPs monetize their services through several approaches, often combining multiple revenue streams:

  • Per-payment routing fees: standard Lightning routing fees (base fee plus a proportional rate per million satoshis forwarded)
  • Channel opening fees: one-time deduction covering on-chain mining costs and capital allocation, charged as a percentage or fixed amount
  • Liquidity leases: periodic charges for guaranteed inbound capacity over a defined period
  • Subscription and SaaS: fixed monthly fees for enterprise infrastructure access
  • SDK licensing: free SDK distribution with monetization through bundled LSP fees when developers use the provider's liquidity services

Why It Matters

LSPs are the critical infrastructure layer that makes Lightning accessible to everyday users. Without them, receiving a Lightning payment would require running a full node, opening channels with sufficient capacity, maintaining uptime for channel reserves, and monitoring the blockchain for potential fraud. This operational burden is unrealistic for mobile users or businesses that want to accept Lightning payments without becoming infrastructure operators.

As of 2025, the Lightning Network processed over $1 billion in monthly transaction volume, with public capacity exceeding 5,600 BTC. LSPs handle the majority of this activity, routing payments, managing liquidity, and onboarding new users through JIT channels. The growth of LSP infrastructure has been a key driver of Lightning adoption in mobile wallets and merchant payment solutions.

Use Cases

Mobile Wallets

The primary use case for LSPs is powering non-custodial mobile wallets. Phoenix, Breez, and Zeus all rely on LSPs to provide channel management, JIT liquidity, and payment routing while users maintain self-custody. The wallet communicates with the LSP over onion-routed Lightning messages, and the LSP handles everything from initial channel setup to ongoing liquidity rebalancing.

Developer SDKs

LSP-backed SDKs allow application developers to embed Lightning payments without running infrastructure. A fintech app or e-commerce platform integrates the SDK, and the LSP handles all channel operations. This model reduces the barrier for businesses exploring Bitcoin payment integration.

Enterprise Infrastructure

Businesses processing significant Lightning volume use enterprise LSPs for managed node hosting, automated channel management, compliance tooling, and API access. Some providers offer credit facilities backed by Lightning liquidity, converting static channel capital into working capital for businesses.

Risks and Considerations

Privacy Tradeoffs

Most mobile wallets connect to a single LSP, meaning that provider has visibility into all payments routed through its channels: amounts, timing, and counterparties. This reduces the privacy benefits of Lightning's onion routing design. Trampoline routing and blinded paths partially mitigate this by obscuring payment destinations from intermediate nodes.

Capital Efficiency

LSPs must lock significant Bitcoin in channels that may sit idle, tying up capital with no return during inactive periods. During high on-chain fee environments, channel opening costs can exceed the value of small payments, making it uneconomical to serve low-value users. Tools like Loop, splicing, and autoloop help manage this but cannot eliminate the fundamental capital requirement.

Single Point of Failure

When a wallet depends on one LSP, that provider's downtime means the user cannot send or receive payments. The LSPS specifications aim to enable multi-LSP wallets, but most current implementations rely on a single provider. LSPs can also censor specific payments by refusing to forward HTLCs, though users can always force-close their channels and recover funds on-chain.

Network Centralization

Lightning Network liquidity is highly concentrated: the top operators control a majority of public capacity, with node-capacity distribution showing a Gini coefficient near 0.97 as of 2025. This centralization pressure is partly driven by the capital requirements of running an LSP, which favor well-funded entities over smaller operators.

LSPs and Spark

Spark takes a fundamentally different approach to the problems LSPs solve. As a Layer 2 built on statechain technology rather than payment channels, Spark eliminates the need for channel management and pre-allocated liquidity entirely. There are no channels to open, no inbound liquidity to provision, and no on-chain fees for onboarding new users.

Spark introduces the concept of Spark Service Providers (SSPs), which serve a fundamentally different role than LSPs. SSPs facilitate deposits, withdrawals, and Lightning interoperability through atomic swaps between Spark and Lightning. Unlike LSPs, SSPs do not need to pre-allocate capital or manage channel liquidity, and anyone can operate as an SSP. Spark wallets can still send and receive Lightning payments through SSPs, maintaining full compatibility with the existing Lightning ecosystem. In May 2025, Spark partnered with Breez to build a new version of the Breez SDK on Spark's infrastructure.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.