JIT Channel (Just-In-Time)

A Just-In-Time (JIT) channel is one that a Lightning service provider opens in direct response to an incoming payment destined for a user who has no suitable channel yet. Instead of the user buying a channel, waiting for it to confirm, and then funding it, all of those steps collapse into one: the inbound payment triggers the channel open, and the funds flow through to the recipient in seconds. JIT channels exist to remove the cold-start problem that otherwise blocks a brand-new wallet from receiving anything over Lightning.

How it works in practice

When a payment arrives at the provider headed for a channel-less client, the provider opens a new payment channel to that client and forwards the payment through it, deducting a fee. The client instantly gains both inbound and outbound liquidity, having never pre-committed any capital of its own. Because the open and the forward are entangled, the provider takes on some short-term risk that the channel does not confirm as expected, which is why the mechanism is carefully specified so wallets and providers from different vendors can interoperate rather than each inventing its own incompatible flow. From the user's side it simply looks like a payment that arrived and worked, with no ceremony around channels at all.

Why it matters for onboarding

JIT channels dramatically lower the barrier to entry: a fresh wallet can receive its first sats without the user understanding inbound liquidity at all, and without first paying to acquire it. That is a genuine usability win, because the need to source inbound capacity before you can receive is one of Lightning's most persistent points of confusion for newcomers. The trade-off is a reliance on a service provider for the open, plus a fee taken out of that first inbound payment — a cost that buys convenience rather than a permanent dependency.

Reading the fee before you accept

Because the fee is deducted from the very first payment, a JIT open is one of the few moments where receiving sats actually costs the recipient something, and a careful wallet surfaces that cost so the user can decide whether the convenience is worth it. Well-behaved providers publish their rates up front and let the client refuse an open it considers too expensive, falling back to a conventional channel purchase instead. The economics matter: for a large first payment the fee may be trivial in percentage terms, while for a tiny one it can eat a meaningful slice, so the sensible pattern is to use JIT for a substantial first inbound and let ordinary channels handle the rest. This is also where a wallet earns or loses a user's trust: a JIT open that silently swallows a large slice of a first payment feels like a bait-and-switch, whereas one that shows the fee and asks before proceeding respects the user as the party actually in control of the decision.

Convenience without surrendering custody

For sovereignty-minded users the important detail is that this is a convenience layer, not custody. The resulting channel is an ordinary non-custodial Lightning channel that the user controls; the provider co-operates to open it but never holds the user's funds hostage, and once it confirms it behaves exactly like any channel the user might have opened themselves, with the same capacity accounting and the same exit rights. The inbound funds settle through the conditional contracts described in our HTLC entry, so the trust placed in the provider is bounded to the moment of onboarding rather than extended over the life of the channel. That boundedness is what makes JIT channels acceptable to a Bitcoiner who refuses to give up self-custody for the sake of a smoother first payment. In short, JIT channels trade a one-time, disclosed fee for the removal of an intimidating setup step, and they manage it without ever asking the user to hand over their coins to a third party.