LSPS: How Lightning Service Provider Standards Are Shaping Mobile Wallets

Lightning wallets face a persistent integration problem: every LSP speaks a different protocol. A wallet built to work with one provider's channel-opening API cannot simply switch to another without rewriting its liquidity logic. The Lightning Service Provider Specification (LSPS) is an effort to fix this by defining a common language for how wallets request channels, receive just-in-time liquidity, and manage their relationship with service providers.

The LSPS working group formed in late 2022, bringing together developers from Breez, Synonym, ZEUS, and other Lightning infrastructure teams. By December 2024, the core specifications were formalized as bLIPs (Bitcoin Lightning Improvement Proposals) and the original LSPS repository was archived in January 2025, with the process moving entirely under the lightning/blips repository.

Why Lightning Wallets Need Standardized LSP Protocols

Lightning's user experience depends heavily on Lightning Service Providers. Mobile wallets cannot run full routing nodes, so they rely on LSPs for inbound liquidity, channel opens, and payment forwarding. The problem is that each LSP has historically implemented its own proprietary API for these operations.

This creates vendor lock-in at the infrastructure level. A wallet team that integrates with Breez's LSP cannot easily migrate to Olympus or Blocktank without significant engineering work. Users are affected too: if their LSP raises fees, degrades service, or shuts down (as Voltage did when it deprecated Flow 2.0 in September 2025), the wallet's liquidity pipeline breaks.

The email analogy: LSPS aims to do for Lightning liquidity what SMTP did for email. A wallet should be able to switch LSPs without code changes, just as an email client can switch between mail servers without rewriting its send logic.

Breez is credited with coining the term "LSP" and was an early advocate for standardization. In May 2023, Severin Buhler posted the initial channel-purchase and JIT-channel proposals to the Lightning-Dev mailing list, prompting broad community discussion. The working group eventually grew to nearly 130 members with bi-weekly calls.

The LSPS Specification Suite

LSPS is not a single protocol but a numbered suite of specifications, each addressing a distinct aspect of the wallet-LSP relationship. The specifications build on each other: LSPS0 defines the transport layer, and higher-numbered specs define specific service APIs that run on top of it.

LSPS0: Transport Layer (bLIP-50)

LSPS0 defines how wallets and LSPs communicate. Rather than introducing new network connections, LSPS0 piggybacks on existing BOLT 8 peer-to-peer connections. All LSPS messages use BOLT 8 message ID 37913, carrying UTF-8-encoded JSON-RPC 2.0 payloads.

This design is deliberate: wallets already maintain a peer connection to their LSP for channel operations. LSPS0 reuses that connection rather than requiring a separate HTTP or gRPC endpoint, reducing complexity and avoiding additional authentication layers. LSPs advertise LSPS support via feature bit 729 (option_supports_lsps) in their init and node_announcement messages.

LSPS1: Channel Requests (bLIP-51)

LSPS1 standardizes how a wallet purchases a Lightning channel from an LSP. The flow is straightforward:

1. The client calls lsps1.get_info to discover LSP parameters: minimum and maximum channel sizes, required confirmations, and supported payment methods.
2. The client calls lsps1.create_order specifying its desired channel size, balance split, and expiration.
3. The client pays via a BOLT 11 invoice, BOLT 12 offer, or on-chain transaction.
4. The LSP opens the channel once payment is confirmed.

The trust model is explicitly non-atomic: the client pays first and trusts the LSP to deliver the channel. This mirrors how existing LSPs operate in practice but standardizes the interface. Zero-confirmation channels are supported with fee-rate safeguards to protect against fee-sniping.

LSPS2: JIT Channel Negotiation (bLIP-52)

LSPS2 is arguably the most impactful specification for mobile wallet UX. It enables just-in-time channel opens: when a payment arrives for a client that has no existing channel, the LSP opens a zero-conf channel on the fly and forwards the payment through it.

The flow works as follows:

1. The client calls lsps2.get_info to learn the LSP's fee structure and validity window.
2. The client calls lsps2.buy with its desired payment size and receives a unique short channel ID (SCID) alias.
3. The client creates a Lightning invoice embedding the SCID alias and the LSP's routing hints.
4. The payer sends the payment, which routes through the LSP. The LSP detects the incoming HTLC, opens a zero-conf channel, and forwards the funds minus the channel-opening fee.

From the end user's perspective, this is seamless: they share an invoice, receive a payment, and a channel materializes automatically. The technical complexity is handled entirely by the LSPS2 protocol negotiation between the wallet and the LSP.

LSPS5: Webhook Registration (bLIP-55)

Mobile wallets face a fundamental platform constraint: operating systems suspend background processes to conserve battery. A Lightning node that gets suspended cannot receive payments. LSPS5 addresses this by letting wallets register HTTPS webhooks with their LSP. When a payment arrives, the LSP sends a signed push notification to wake the wallet app.

This is a critical piece of infrastructure for any non-custodial mobile Lightning wallet. Without it, users must keep the app open to receive payments, a UX that is unacceptable for mainstream adoption.

LSPS7: Channel Lease Extensions (bLIP-57)

Authored by ZEUS founder Evan Kaloudis and filed as a draft in January 2025, LSPS7 standardizes the process of extending channel leases. When a wallet has purchased a channel via LSPS1 with a fixed duration, LSPS7 lets it extend that channel's lifetime without closing and reopening: the client queries extendable channels, places an order, and pays to keep the channel alive.

LSPS Specification Status Overview

Who Has Implemented LSPS

Adoption of LSPS varies significantly across implementations. Some projects have embraced the specification fully; others have charted their own path.

LDK and lightning-liquidity

The most comprehensive LSPS implementation lives in the lightning-liquidity Rust crate, part of the LDK project. It was merged into the main rust-lightning repository with LDK v0.1 in January 2025 and supports LSPS0, LSPS1, LSPS2, and LSPS5 on the client side.

The crate's architecture centers on a LiquidityManager that integrates with LDK nodes as a CustomMessageHandler. Any wallet built on LDK can connect to any LSPS-compliant LSP by plugging in this manager, making it the closest thing to a reference implementation that exists. LDK Node v0.7.0 (released December 2025) wraps this at a higher level for applications that want turnkey LSPS2 support.

Breez SDK

Breez SDK includes LSPS1 and LSPS2 support, with dynamic fee selection according to the LSPS2 standard. Breez also maintains lspd, an open-source LSP daemon that works with both LND and Core Lightning nodes. As the team that coined the term "LSP," Breez has been one of the strongest advocates for standardized protocols throughout the process.

Core Lightning

Core Lightning v25.05 shipped early LSPS support with client and server plugins for the LSPS0 transport layer. Blockstream also maintained a dedicated cln-lsps implementation supporting LSPS0 and LSPS1 (Lightning payment only), though this repository was archived in October 2025 as the functionality was folded into CLN's core codebase.

ZEUS and Olympus

ZEUS operates the Olympus LSP with LSPS1 support for channel purchases and LSPS7 for lease extensions. ZEUS expanded Olympus integrations in 2025, adding support for third-party wallets connecting via standard LSPS protocols.

The Phoenix Exception: ACINQ's Alternative Approach

Not everyone adopted LSPS. ACINQ, the team behind Phoenix and Eclair, took a fundamentally different approach. Rather than implementing LSPS1 and LSPS2, they built their own open protocol documented as bLIP-36: a thin layer on top of dual funding, splicing, and liquidity ads.

Phoenix v2.4.0 (released October 2024) switched from ACINQ's previous proprietary, closed-source LSP protocol to this new open standard. Phoenix's model maintains a single dynamic channel that resizes via on-chain splice transactions rather than opening and closing multiple channels. This architectural decision means Phoenix does not need LSPS1's channel-purchase flow or LSPS2's JIT channel opens: instead, it uses liquidity ads to dynamically adjust the channel's capacity.

Two open standards, one goal: Both LSPS and ACINQ's bLIP-36 approach aim to replace proprietary LSP protocols with open ones. They differ in architecture (discrete channels vs. a single spliced channel) but share the objective of reducing vendor lock-in.

LSPS Implementation Comparison

How LSPS Enables LSP Competition

The strategic value of LSPS is not just technical interoperability: it is enabling a competitive market for Lightning liquidity services. Without standardized protocols, switching costs are high and LSPs face little pressure to compete on price or quality.

With LSPS, a wallet developer can build against a single API surface and then connect to any compliant provider. This creates several dynamics:

• LSPs must compete on fees, uptime, and channel quality rather than integration lock-in.
• Wallets can implement multi-LSP failover: if one provider goes down, the wallet automatically falls back to another.
• Smaller LSPs can enter the market without convincing wallet teams to build custom integrations.
• Geographic diversity becomes possible: wallets can route through regional LSPs for lower latency without per-provider code.

That said, real-world multi-LSP switching remains uncommon. Most wallets still rely on a single integrated provider, and the specification's promise of seamless provider switching has yet to be fully realized in production deployments.

Challenges Facing LSPS Adoption

Despite progress, LSPS faces several structural challenges that limit its impact on the broader Lightning ecosystem.

Incomplete Coverage

LSPS3, LSPS4, and LSPS6 were referenced in early discussions but never formalized as bLIPs. The specification suite covers channel purchases and JIT opens, but other aspects of the wallet-LSP relationship (channel lifecycle management, fee renegotiation, dispute handling) remain unspecified. Each LSP fills these gaps with proprietary logic.

Fragmented Adoption

The Phoenix/ACINQ split illustrates a broader tension. ACINQ's argument for bLIP-36 is that JIT channels are a workaround for a deeper problem: instead of opening new channels reactively, the protocol should support dynamic channel resizing natively. If splicing and liquidity ads become standard BOLT features, much of LSPS1 and LSPS2 could become unnecessary.

The Channel Problem Itself

LSPS standardizes interactions that exist because of Lightning's channel architecture. Users need LSPs because they need channels, and they need channels because Lightning requires pre-funded payment paths. A protocol that eliminates channels eliminates the need for LSPs and their specification entirely.

This is exactly the approach taken by Spark, a Bitcoin Layer 2 built on statechains and FROST threshold signatures. Spark users do not manage channels, do not need inbound liquidity, and do not rely on LSPs for receiving payments. Transfers happen by rotating key shares between the sender, recipient, and a set of operators: no channel opens, no liquidity planning, no LSPS negotiation. The liquidity management that LSPS is trying to standardize simply does not exist in Spark's architecture.

What Comes Next for Lightning Liquidity Standards

The LSPS process has established a foundation, but the specification's long-term relevance depends on how Lightning's architecture evolves. Several trends are worth watching.

Splicing adoption could shift the balance toward ACINQ's approach. If most implementations support dynamic channel resizing via splice transactions, the distinction between "opening a new channel" (LSPS1) and "resizing an existing one" blurs. LSPS2's JIT channel flow becomes less necessary when channels can grow on demand.

Lightning's broader trajectory also matters. As channel factories and other scaling proposals mature, the role of individual LSPs may shift from channel provisioning to factory membership management, an interaction surface that LSPS does not yet cover.

For developers building Lightning-enabled applications today, the practical advice is clear: build against LSPS2 for JIT channel support (via LDK's lightning-liquidity crate or Breez's lspd) to avoid locking into a single provider. For those evaluating whether to build on Lightning's channel model at all, explore Spark's SDK as an alternative that sidesteps the liquidity problem entirely.

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.