LSPS2, or bLIP 52, negotiates parameters, places a special identifier in the payment data, and when it passes through the LSP triggers a private zero-confirmation channel open and delivery of the payment after the opening fee is deducted.
A Just-in-Time Channel is created only in response to an incoming payment that reaches the recipient from the public Lightning Network through an LSP. The recipient therefore need not own a channel, outbound capacity, or on-chain funds in advance; the cost of new inbound liquidity is paid from the value of the first received payment. [1]
The client first calls lsps2.get_info and receives offers containing min_fee_msat, a proportional rate in ppm, valid_until, min_lifetime, max_client_to_self_delay, and payment-size limits. It sends the selected offer and the LSP-created promise in lsps2.buy; the LSP can return an error if the offer expired, the payment is too small, or liquidity is unavailable. [2]
A successful lsps2.buy returns jit_channel_scid and lsp_cltv_expiry_delta. The client puts the LSP node ID and this SCID into a BOLT11 invoice as the route hint's only hop, or supplies the same information through a future scheme such as a blinded path; payment expiry must not exceed valid_until, and the client must be connected to the LSP when payment arrives. [1]
When the LSP recognizes jit_channel_scid in an incoming HTLC, it starts standard BOLT 2 channel establishment. The channel must be large enough for payment_size_msat minus opening_fee and a reserve, remains unannounced, uses option_scid_alias, and can forward the payment as a zero-confirmation channel before the funding transaction confirms. [4]
LSPS2 defines two different trust models. In LSP trusts client mode, the provider first publishes a valid funding transaction and risks the client not releasing the preimage; in client trusts LSP mode, the provider may delay broadcast while the client releases the preimage and relies on the LSP to create a valid funding outpoint. [3]
JIT is not unconditional delivery. The payment must cover the opening fee, limits, and minimum HTLC; a client disconnect before funding_signed produces temporary_channel_failure, and a naive prepayment probe can, under LSP trusts client, trigger a channel open for which the LSP is never paid. [1]
bLIP 52 is listed as an active specification and requires LSPS0, or bLIP 50, as transport. The lightning-liquidity reference crate provides both client and service handlers for LSPS2, but its documentation calls service-side support beta; API availability therefore does not prove production readiness of a particular wallet or LSP. [5]
Verification starts with lsps2.get_info and an exact calculation of max(min_fee_msat, proportional fee), plus checks of valid_until, promise, payment limits, min_lifetime, and max_client_to_self_delay. After payment, verify the deducted fee, funding outpoint, channel parameters, channel_ready, alias, and actual inbound capacity; an invoice alone does not prove an open channel. [1]
For the clearest picture, read this entry together with Lightning Service Provider, Inbound Liquidity, Payment Channel, Price Channel, BOLT 11, BOLT 12.
01Is a Just-in-Time Channel free?+
No. The LSP deducts an opening fee from the first incoming payment. Beforehand, the client must check the minimum and proportional fee components, payment limits, and parameter validity period in the offer.
02Is a Just-in-Time Channel confirmed on-chain before the payment is received?+
Usually not. LSPS2 opens a zero-confirmation channel in response to the payment, and depending on the trust model the funding transaction may only be in the mempool or may still await broadcast. The client must knowingly choose the confirmation threshold and LSP risk it accepts.