Lightning Service Providers: How LSPs Enable Mobile Lightning

The Lightning Network enables fast, low-cost Bitcoin payments, but running a Lightning node is operationally demanding. Users need to open channels, allocate liquidity on both sides, stay online to receive payments, and monitor for fraud. For a mobile user who opens their wallet once a day, this is impractical. Lightning Service Providers (LSPs) emerged to bridge that gap: third-party services that handle the infrastructure complexity so end users can send and receive Lightning payments without managing channels themselves.

LSPs are not a single product or protocol. The term describes a role in the network: an entity that provides inbound liquidity, opens channels on behalf of users, optimizes routing, and generally abstracts away the operational mechanics of Lightning. Understanding how LSPs work, what they can and cannot do, and what trust assumptions they introduce is essential for anyone building or evaluating Lightning-based products.

Why Lightning Needs Service Providers

Lightning's core design assumes participants run always-online nodes with pre-funded payment channels. This works well for merchants processing high volumes or routing nodes operated by infrastructure companies. It does not work well for mobile wallets, where users connect intermittently and cannot dedicate capital to channel management.

The fundamental challenge is liquidity. To receive a payment on Lightning, someone must have already allocated funds toward you in a channel. A new user with no channels has zero inbound liquidity: nobody can pay them. Opening a channel requires an on-chain transaction with associated fees and confirmation time. Once open, the channel's capacity is fixed unless the user performs a splice or closes and reopens.

LSPs solve this by pre-positioning liquidity. They maintain well-connected nodes with large channel balances and open channels to users on demand. When a mobile wallet user needs to receive their first payment, the LSP opens a channel just in time, funded with enough inbound capacity for the payment to arrive.

Core LSP Functions

An LSP typically performs three distinct roles, though not every LSP offers all three.

Liquidity provider

The most basic LSP function: allocating capital in channels so users can receive payments. The LSP commits its own Bitcoin to the remote side of channels with users, creating inbound capacity. This is capital-intensive and represents the primary cost of running an LSP. The liquidity must be actively managed: if a user receives payments that fill their channel, the LSP needs to rebalance or open additional channels to restore capacity.

Channel manager

Beyond initial channel opens, LSPs handle ongoing channel lifecycle operations. This includes monitoring channel reserves, performing automated liquidity loops between on-chain and off-chain balances, executing splices to resize channels without closing them, and managing anchor outputs for fee bumping during high-fee periods. Mobile wallets delegate all of this to the LSP.

Routing optimizer

LSPs maintain connections to many nodes across the Lightning graph, positioning themselves as efficient routing hubs. They use probing to discover viable payment paths, implement multipath payment splitting for large transfers, and leverage trampoline routing to offload pathfinding from resource-constrained mobile devices.

Just-in-Time Channels

The technique that made LSPs practical for onboarding is the just-in-time (JIT) channel. When a new user receives their first Lightning payment, the LSP intercepts the incoming HTLC and opens a channel to the recipient on the fly, forwarding the payment through the newly created channel. From the user's perspective, they simply receive a payment. Behind the scenes, the LSP has funded and opened a channel, deducting the on-chain opening cost from the payment amount or absorbing it as a customer acquisition cost.

JIT channels rely on zero-conf channel opens: the recipient accepts the channel before the funding transaction confirms on-chain. This is safe only because the LSP is the one funding the channel. If the LSP double-spends its own funding transaction, it loses the capital it committed. The risk is entirely on the LSP, not the user.

Zero-conf trust model: Zero-conf channels require trusting the channel opener not to double-spend the funding transaction. In the LSP context this is acceptable because the LSP has an economic incentive to keep channels operational. The user never risks their own funds: they are receiving into the channel, not funding it.

The JIT channel flow

1. Sender initiates a Lightning payment to the recipient's invoice
2. The payment routes through the network and reaches the LSP
3. LSP detects that the recipient has no open channel (or insufficient inbound capacity)
4. LSP opens a new channel to the recipient with the payment amount as initial remote balance
5. LSP forwards the HTLC through the new channel
6. Recipient reveals the preimage to claim the payment
7. The funding transaction confirms in the background

This mechanism transformed Lightning onboarding. Before JIT channels, new users had to acquire inbound liquidity manually: requesting channel opens, using liquidity marketplaces, or performing loop-in operations. JIT channels made the process invisible.

The LSP Specification

Recognizing that LSPs were becoming critical infrastructure, the community began standardizing the LSP interface. The LSP specification (hosted under the Bitcoin and Lightning Layer Specs organization) defines a common API for wallet-to-LSP communication.

The specification covers two primary areas:

• LSPS1: channel ordering, where a client requests that the LSP open a channel with specific parameters (capacity, duration, fee limits)
• LSPS2: JIT channel negotiation, where the LSP and client coordinate just-in-time channel opens for incoming payments

Additional proposals address flow control (LSPS3) for managing webhook notifications and channel lifecycle events. The goal is interoperability: a wallet should be able to switch LSPs without code changes, similar to how email clients can switch between SMTP providers.

Standardization matters because without it, each LSP implements proprietary APIs, locking wallets into specific providers. The LSPS2 specification in particular defines how JIT channels should work across different implementations, enabling a competitive market for liquidity provision.

Major LSP Implementations

Several companies operate as LSPs or provide LSP tooling. Their approaches differ in architecture, target audience, and integration model.

ACINQ (Phoenix)

ACINQ operates the LSP behind Phoenix Wallet, one of the most polished non-custodial Lightning wallets. Phoenix uses ACINQ's node as its sole LSP, handling all channel management transparently. The wallet employs splicing extensively: rather than opening multiple channels, Phoenix maintains a single channel and resizes it dynamically. Users see a single balance without channel abstractions. ACINQ pioneered the on-the-fly channel open model and has refined it through multiple iterations.

Breez SDK

Breez SDK takes a different approach: rather than operating a wallet, Breez provides an SDK that other developers embed into their applications. The SDK bundles an LDK-based Lightning node with built-in LSP connectivity. The Breez LSP handles liquidity provisioning while the SDK manages the node lifecycle on the user's device. This allows third-party apps to offer Lightning payments without building LSP infrastructure from scratch.

Voltage (LDK-based)

Voltage provides cloud Lightning infrastructure including LSP services. Their platform targets businesses that need Lightning nodes and liquidity management without the operational burden. Voltage uses LDK (Lightning Dev Kit) as its underlying implementation, offering programmatic control over channel management and liquidity allocation.

Olympus (Zeus)

Zeus operates Olympus, an LSP integrated into the Zeus wallet. Olympus provides JIT channel opens using a wrapped invoice approach, where the wallet generates modified invoices that route through the LSP. Zeus also supports connecting to a user's own node, making the LSP optional for advanced users.

The Trust Model: What LSPs Can and Cannot Do

LSPs introduce a specific set of trust assumptions into Lightning. These are often misunderstood: an LSP is not a custodian, but it is not a trustless peer either.

What an LSP can do

• See payment metadata: amounts, timing, and sender/receiver information for payments routed through its channels
• Censor payments: refuse to route or forward specific transactions
• Delay payments: hold HTLCs up to their timeout period before forwarding or failing
• Close channels unilaterally: force-close a channel, pushing the state on-chain
• Charge fees: impose routing fees, channel opening fees, and liquidity premiums

What an LSP cannot do

• Steal funds: the user holds their own keys and can always force-close to recover on-chain
• Fabricate payments: the LSP cannot credit or debit the user's channel balance without valid HTLCs
• Prevent exit: the user can broadcast a commitment transaction to close the channel unilaterally
• Modify channel state: commitment transactions are co-signed, and old states are punishable via justice transactions

LSPs are not custodians: Unlike custodial wallets where the provider holds your private keys, an LSP never controls your funds. The trust is operational (availability, routing, pricing) rather than custodial. However, users of a single LSP face a single point of failure for payment routing: if the LSP goes offline, the user cannot send or receive Lightning payments until the channel is closed and new infrastructure is found.

Privacy considerations

A significant but often overlooked concern: LSPs have full visibility into all payments routed through their channels. For a mobile wallet using a single LSP, this means the LSP sees every incoming and outgoing payment amount, every payment hash, and the timing of all transactions. This is a substantial privacy reduction compared to the onion-routed design of Lightning, where intermediate nodes only see their adjacent hops. Blinded paths and PTLCs may improve this, but current LSP deployments largely operate with full payment visibility.

Economic Models: How LSPs Make Money

Running an LSP is capital-intensive. The provider must lock Bitcoin in channels, pay on-chain fees for channel operations, and maintain high-availability infrastructure. Several revenue models have emerged.

Fee-based models

• Routing fees: standard Lightning routing fees on payments forwarded through the LSP's channels (typically a base fee plus a proportional fee)
• Channel opening fees: a one-time fee deducted from the first payment to cover the on-chain cost of channel creation
• Liquidity lease fees: periodic charges for maintaining inbound capacity above a threshold

Subscription models

Some LSPs charge monthly fees for guaranteed liquidity levels. This is more common in B2B contexts where merchants need predictable inbound capacity. The merchant pays a fixed fee for a specific amount of always-available inbound liquidity.

Cross-subsidy models

Wallet companies operating their own LSPs may absorb liquidity costs as a customer acquisition expense, monetizing through other services such as fiat on-ramps, premium features, or transaction-based revenue. ACINQ's Phoenix, for example, charges a percentage fee on payments that covers both routing and liquidity costs.

Challenges and Limitations

Capital efficiency

LSPs must lock up Bitcoin in channels that may sit idle. A channel opened for a user who transacts once a month ties up capital that earns no return. This is fundamentally different from traditional payment processing where the processor does not need to pre-fund transactions. Capital efficiency is the primary constraint on LSP scalability: serving more users means locking more Bitcoin.

On-chain fee sensitivity

Every channel operation involves on-chain transactions. During high-fee periods, the cost of opening a JIT channel can exceed the payment amount itself. LSPs mitigate this with batched opens, CPFP fee bumping, and anchor outputs, but the fundamental dependency on L1 block space remains. A sustained period of high fees effectively prices small users out of Lightning onboarding.

Single point of failure

Most mobile wallets connect to a single LSP. If that LSP goes down, the user loses Lightning connectivity until they force-close channels and re-establish connections elsewhere. Multi-LSP architectures are technically possible but add complexity in channel management and balance distribution. The LSP specification aims to make switching easier, but in practice, moving liquidity between providers requires on-chain operations.

Regulatory ambiguity

LSPs occupy an unclear regulatory position. They do not custody funds, but they facilitate payments and have visibility into transaction flows. Some jurisdictions may classify LSPs as money transmitters or payment service providers. This uncertainty creates risk for LSP operators and may constrain who is willing to offer these services.

Channel Factories and Future Improvements

Several proposed improvements could reduce the burden on LSPs. Channel factories would allow opening many channels in a single on-chain transaction, dramatically reducing per-user onboarding costs. Eltoo (LN-Symmetry) would simplify channel state management by eliminating the need for justice transactions and revocation keys, reducing the storage and monitoring burden. PTLCs would improve privacy by breaking the correlation between payment hops.

These improvements address symptoms but not the fundamental architecture. Lightning's channel-based model inherently requires liquidity pre-allocation and active management. LSPs exist because the protocol demands infrastructure that individual users cannot reasonably operate.

Beyond LSPs: Channel-Free Alternatives

The challenges of the LSP model have motivated exploration of alternative Layer 2 architectures that do not rely on payment channels at all. Spark, for example, uses a statechain-based design where transfers happen by rotating key ownership rather than routing payments through channels.

In Spark's model, there are no channels to open, no liquidity to pre-allocate, and no routing paths to discover. Users hold their Bitcoin in leaves (off-chain representations backed by on-chain UTXOs) and transfer value by coordinating key rotations with a set of operators. The operational overhead that LSPs exist to manage simply does not arise.

This means mobile users on Spark get the same capabilities as any other participant: instant transfers, no minimum balance for receiving, and no dependency on a single service provider for liquidity. The tradeoff is a different trust model (1-of-n operator honesty rather than fully trustless channels), but the user experience gap that LSPs were designed to fill does not exist in a channel-free architecture.

Spark and Lightning are interoperable: Spark wallets can send and receive Lightning payments through Spark Service Providers, which execute atomic swaps between the two networks. The difference is that Spark users do not need an LSP relationship to participate: they can interact with the Lightning network without managing channels or liquidity.

Evaluating LSPs

For developers building on Lightning today, choosing an LSP involves evaluating several factors:

• Liquidity depth: how much inbound capacity can the LSP provide, and how quickly can it scale
• Fee structure: transparent pricing for channel opens, routing, and ongoing liquidity
• LSPS compliance: whether the LSP implements the standard specification for portability
• Uptime and reliability: historical availability and incident response
• Geographic coverage: routing connectivity to nodes in relevant regions
• Privacy posture: data retention policies and commitment to minimizing surveillance

The ideal scenario is an open market of interchangeable LSPs where wallets can dynamically select providers based on price and performance. The LSP specification lays the groundwork, but real interoperability remains limited. Most wallets still rely on a single, integrated LSP.

Conclusion

LSPs are the infrastructure layer that makes Lightning usable for ordinary people. Without them, Lightning would remain a protocol for technical operators willing to manage nodes, channels, and liquidity. JIT channels, standardized APIs, and transparent fee models have brought Lightning to mobile wallets used by millions.

At the same time, the need for LSPs reflects a real limitation of the channel-based architecture. Pre-allocating capital, managing on-chain fees, and maintaining always-on infrastructure creates operational complexity and cost that gets passed to users in some form. Newer Layer 2 designs that eliminate channels entirely sidestep these challenges, offering a different set of tradeoffs but removing the LSP dependency that defines Lightning's mobile experience.

Whether you build on Lightning with LSP support, on Spark without channels, or on both through their interoperability, the goal is the same: making Bitcoin payments fast, cheap, and accessible to everyone.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.