JIT Channel (Just-in-Time)

What Is a JIT Channel?

A JIT (Just-in-Time) channel is a Lightning Network channel that an LSP opens at the exact moment a payment needs to be delivered to a user. Rather than requiring users to set up channels in advance, fund them with on-chain bitcoin, and wait for confirmations, a JIT channel creates the infrastructure on demand when money is already flowing.

Think of it like a toll road that builds itself the moment the first car arrives. The user never needs to think about channel management, liquidity provisioning, or on-chain transactions. They simply share a Lightning invoice, and when payment arrives, the LSP handles everything behind the scenes. The cost of building that road (the on-chain channel open) is deducted from the first toll payment.

JIT channels solve one of Lightning's core onboarding problems: new users cannot receive payments without an existing channel, but opening a channel requires on-chain funds and confirmations. This chicken-and-egg problem historically meant users had to acquire on-chain bitcoin first, open a channel, and wait before they could participate in Lightning. JIT channels eliminate that entire flow.

How It Works

The JIT channel flow is standardized in the LSPS2 specification (bLIP-52), developed by the LSP Spec working group and finalized in January 2025. The protocol operates over BOLT 8 peer connections using JSON-RPC 2.0 messages.

The LSPS2 Flow

1. The client queries the LSP for fee parameters by calling lsps2.get_info. The LSP returns a menu of fee tiers, each specifying a minimum fee, a proportional fee rate (in parts per million), validity period, minimum channel lifetime in blocks, and payment size limits.
2. The client selects a fee tier and calls lsps2.buy. The LSP responds with a jit_channel_scid (a short channel ID to use in invoice route hints) and the CLTV delta for the LSP hop.
3. The client generates a standard BOLT 11 invoice with a route hint pointing through the LSP's node using the provided jit_channel_scid.
4. The payer sends payment, which routes through the network to the LSP. The LSP recognizes the HTLC's destination as a JIT channel SCID and holds the HTLC.
5. The LSP initiates standard BOLT 2 channel establishment to the client, using option_scid_alias and setting the channel as private (announce_channel = false).
6. After both parties exchange channel_ready messages, the LSP forwards the payment with the opening fee deducted via a custom TLV field (extra_fee, type 65537).
7. The client validates the fee, releases the preimage, and the payment settles.

Fee Calculation

LSPS2 uses a two-component fee model combining a proportional rate with a minimum floor:

opening_fee = max(
  min_fee_msat,
  ceil(payment_size_msat * proportional / 1_000_000)
)

// Integer arithmetic version (no floating point):
opening_fee = ((payment_size_msat * proportional) + 999999) / 1000000
if opening_fee < min_fee_msat:
    opening_fee = min_fee_msat

The fee covers the on-chain transaction cost of opening the Lightning channel plus the LSP's margin. The LSP commits to keeping the channel open for at least min_lifetime blocks after confirmation. Real-world fees vary by LSP and mempool conditions, but typically include a minimum fee of a few thousand satoshis plus a proportional component.

The Zero-Conf Requirement

JIT channels depend on zero-confirmation channels for instant user experience. Without zero-conf, the user would wait 10 to 60 minutes for the funding transaction to confirm before receiving payment. Zero-conf channels were standardized in BOLTs #910, introducing the option_zeroconf feature bit (50/51) and option_scid_alias (46/47). Both parties exchange channel_ready before the funding transaction confirms, using an alias SCID rather than the real on-chain identifier.

LSPS2 defines two trust models for the zero-conf window. In the default mode (LSP-trusts-client), the LSP broadcasts the funding transaction immediately, and the client can independently verify it appears in the mempool before releasing the preimage. In the client-trusts-LSP mode, the LSP may delay broadcasting until receiving the preimage, which is riskier for the client but allows the LSP to avoid an unnecessary on-chain transaction if the payment fails. For a deeper look at zero-conf tradeoffs, see the zero-conf deep dive.

Why JIT Channels Matter

Before JIT channels, onboarding a new Lightning user required multiple steps: acquire on-chain bitcoin, find a well-connected peer, open a channel, wait for confirmations, and then request inbound liquidity from that peer. This process could take hours and required technical knowledge that most users lacked.

JIT channels reduce onboarding to a single action: share an invoice, receive payment. The complexity shifts from the end user to the LSP, which handles channel management, liquidity provisioning, and on-chain transactions as an infrastructure service. This pattern mirrors how traditional payment networks abstract complexity: merchants don't manage card network infrastructure, and Lightning users shouldn't need to manage channel infrastructure.

For wallet developers and platforms building on Bitcoin's Lightning layer, JIT channels enable consumer-grade experiences. A user can download a wallet, receive their first payment in seconds, and start transacting without any prior Bitcoin knowledge. This is essential for driving adoption beyond technically sophisticated early users. For a comprehensive look at how LSPs enable these experiences, see the Lightning Service Providers explainer.

Implementations and Ecosystem

JIT channels are supported across the major Lightning implementations and several production wallets:

Notable wallets that have used JIT channels include Breez (using their Breez SDK and lspd daemon), Phoenix (before migrating to splicing in v2), and ZEUS (via Olympus LSP). The lightning-liquidity Rust crate from the LDK team provides a reusable library for wallet developers to integrate LSPS2 on both the client and server side.

Use Cases

New User Onboarding

The primary use case for JIT channels is bootstrapping new Lightning users. A user downloads a wallet, generates an invoice, and receives their first payment. The LSP opens a channel on-the-fly, deducts the opening fee, and delivers the funds instantly. No prior on-chain balance, no channel management, no waiting for confirmations.

Merchant Payment Acceptance

Merchants adopting Lightning for the first time can accept their first customer payment without pre-funding channels. The JIT channel opens when the first customer pays, and subsequent payments flow through the established channel. This dramatically lowers the barrier for merchant adoption.

Wallet-as-a-Service Platforms

Platforms that provision Lightning wallets for end users (such as neobanks, exchanges, or fintech applications) use JIT channels to create on-demand payment infrastructure. Each user gets a channel only when they need one, avoiding the cost of pre-provisioning channels for users who may never transact. This is particularly relevant for mobile wallet architectures where resource efficiency matters.

JIT Channels vs. Splicing

Splicing is increasingly seen as an evolution beyond JIT channels for ongoing liquidity management. Where JIT channels open a new channel for each capacity shortfall, splicing resizes an existing channel dynamically by adding or removing funds through a single on-chain transaction.

ACINQ (the team behind Phoenix wallet and Eclair) described this progression as moving from manual channel management (first generation) through JIT channels (second generation) to splicing (third generation). However, JIT channels remain necessary for the initial onboarding case: splicing requires an existing channel to modify, so the very first channel for a new user still needs a JIT open or a pre-purchased channel via LSPS1. For more on splicing mechanics, see the splicing deep dive.

Risks and Considerations

Zero-Conf Trust Assumptions

JIT channels inherit the trust assumptions of zero-conf channels. The LSP funds the channel, so the primary risk is that the LSP double-spends its own funding transaction before it confirms. In practice, this risk is mitigated by the LSP's reputational stake and the fact that double-spending would mean the LSP loses its own capital. The trust window is short: typically one to three block confirmations (10 to 30 minutes).

In the riskier client-trusts-LSP mode, the client releases the preimage before verifying the funding transaction. A malicious LSP could theoretically accept the preimage to settle the upstream payment without ever broadcasting the funding transaction. This mode should only be used with highly trusted LSPs.

LSP Dependency

JIT channels create a dependency on the LSP for the initial channel open and ongoing channel availability. If the LSP goes offline, users cannot receive new payments through JIT channels. The channel itself remains valid (the user can force-close to recover funds), but the convenience of automatic channel provisioning depends on LSP uptime. This is a common tradeoff in Lightning liquidity management.

Fee Variability

JIT channel fees fluctuate with on-chain fee markets. During periods of high mempool congestion, the cost of opening a channel rises, and LSPs pass this cost to users. A payment that costs a few thousand satoshis in fees during low congestion might cost significantly more during a fee spike. Users may be surprised by fee deductions from their first received payment, especially if they are accustomed to near-zero Lightning routing fees.

Channel Privacy

LSPS2 requires all JIT channels to be private (announce_channel = false). While this protects user privacy by keeping channels out of the public network graph, it means the LSP is the only routing path to the user. All incoming payments must flow through the LSP, giving it visibility into the user's payment activity. Users concerned about privacy should consider this when choosing an LSP.

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.