Just-in-time channel
A just-in-time channel (JIT channel) is a Lightning Network channel that a Lightning service provider (LSP) opens in response to an incoming payment for a client that does not yet have inbound capacity. The LSP holds the first payment, funds a new channel, then forwards the HTLC into that channel so a new user can receive without first opening a channel or buying inbound liquidity.
JIT channels should not be confused with just-in-time routing, which rebalances existing channels so a payment that would otherwise fail for lack of local liquidity can be accepted.
Receiving on Lightning needs inbound capacity: a channel where the remote side holds enough balance (and a free HTLC slot) to carry the payment. A new wallet has neither. A JIT open treats the incoming payment as the event that creates the channel. Negotiation is commonly specified by LSPS2 (bLIP-52). The open usually depends on zero-confirmation channel features (option_zeroconf and option_scid_alias) so peers can use a short-channel-id alias before the funding transaction confirms. See also Zero-confirmation transaction.
In outline: the client gets JIT parameters from an LSP and embeds a reserved SCID in invoice routing hints. When a matching payment arrives, the LSP holds the HTLC, opens an often-unannounced channel with the client, funds it (crediting the payment minus any opening fee), and forwards the HTLC so the client can settle with the preimage. Without extra on-chain contracts, the first open typically requires trusting the LSP for that handshake. After a channel exists, later capacity changes are often done with Splicing rather than more JIT opens. Related liquidity tooling includes Dual funding.
Trust models
LSPS2 describes two trust models for that handshake. In one model the LSP trusts the client to claim the forwarded payment after the channel is open. In the other the client trusts the LSP, and the LSP may withhold broadcasting the funding transaction until it learns the payment preimage. Opening fees are typically deducted from the first received amount rather than paid as a separate on-chain invoice. Channels opened this way are often private. Public announcement is optional and usually deferred until the funding transaction has enough confirmations.
LSP fee schedules and channel announcement policy remain application choices outside BOLT consensus. Wallets should surface which trust model an LSP uses before the first receive, because the funding broadcast timing differs.
Risks
A risk specific to JIT opens is that a prepayment probe reaching the client's reserved route hint can cause an LSP to open a channel before a real payment arrives. Payers that probe only through the last public hop reduce that failure mode. After the first channel exists, the wallet usually buys more inbound capacity with LSPS1 channel orders or adjusts size with Splicing instead of repeating JIT opens for every payment.
Private JIT channels do not appear in public gossip, so pathfinding beyond the LSP depends on the LSP's own outbound graph. That concentration is intentional for onboarding and is a reason many wallets later splice or buy additional peers.