Zero-conf Channel

A zero-conf channel (zero-confirmation channel) is a Lightning Network payment channel that can send and receive immediately after its funding transaction is broadcast, before that transaction is mined into a block. Normally a node waits several confirmations to be sure the funding output cannot vanish in a reorg or double-spend; a zero-conf channel skips that wait so the user can transact instantly. This is the machinery behind the "turbo channels" many mobile wallets advertise, and it is why a brand-new wallet can receive its first sats seconds after installation instead of half an hour later.

The trust trade-off

Skipping confirmations reintroduces a small, bounded trust assumption. Until the funding transaction confirms, it exists only in the mempool, and the party who funded the channel could in principle replace it with a conflicting transaction, erasing the channel and anything received over it. The exposed party is whoever accepted value across the unconfirmed channel — typically the fundee. The window is short, lasting only until the funding transaction is mined, but it is real, which is why zero-conf is accepted only from known, reputable counterparties rather than arbitrary strangers. In practice that almost always means a Lightning Service Provider opening a channel to its own user: the LSP funds the channel, so the user risks nothing by using it immediately, and the LSP's business depends on not defrauding its customers.

How it is enabled

Zero-conf is formalized in the Lightning specification through the option_zeroconf feature bit, negotiated when the channel opens, with the required minimum confirmation depth set to zero. Because an unconfirmed channel has no block position yet, it also has no real short channel ID; the spec solves this with SCID aliases, temporary identifiers both peers agree to use for routing until the funding transaction confirms and the genuine ID exists. From the payer's perspective nothing unusual is happening — HTLCs flow through the aliased channel exactly as they would through a confirmed one.

Accepting nodes also manage the risk actively rather than just hoping. An LSP funding its own channel bears the risk itself, which is the cleanest case; where the acceptor is exposed, mitigations include watching the mempool for conflicting spends during the window, requiring the funder to use non-replaceable transactions, or adding a third-party co-signer so the funding output cannot be double-spent unilaterally. None of these make zero-conf trustless — they shrink and instrument the trust until confirmation makes it moot.

For the home node runner the practical stance is simple: leave zero-conf acceptance off for unsolicited channels — implementations default that way — and treat it as a consumer-onboarding tool rather than a routing-node feature. The place you will meet it is as a wallet user, where an LSP's turbo channel is genuinely convenient and the risk sits with the LSP, not with you.

Why it matters for onboarding

Zero-conf channels solve Lightning's coldest cold-start problem: a new user has no channels, no inbound liquidity, and no patience for a confirmation wait. With zero-conf plus an LSP, the flow becomes: install wallet, request payment, LSP opens a turbo channel with the needed channel capacity, payment arrives — all inside a minute. The cost is a dose of trust in the LSP during the confirmation window, and that trade deserves eyes-open acceptance rather than denial. A sovereign user can take the convenient onramp, let the channel confirm, and still end up in a fully trustless position afterward; the trust was temporary scaffolding, not the foundation. As always in Bitcoin, the point is not that trust is forbidden — it is that you should know exactly when you are extending it, to whom, and for how long.