Zero-Conf Lightning Channels: Speed vs Trust in Instant Channel Opens

Opening a Lightning channel normally means waiting. The funding transaction must confirm on the Bitcoin blockchain before either party can route payments, and that takes anywhere from 30 minutes to over an hour. For a new user downloading a mobile wallet for the first time, this delay is a dealbreaker. Zero-conf channels solve this by letting two peers use a channel immediately after the funding transaction is broadcast, before it confirms on-chain. The tradeoff: one party must trust that the other will not double-spend the funding output during the confirmation window.

This article explains why standard channel opens require confirmations, how zero-conf channels bypass that requirement, the trust assumptions they introduce, and how newer protocols avoid the problem altogether.

Why Standard Channel Opens Wait for Confirmations

A Lightning channel is anchored by an on-chain funding transaction: a 2-of-2 multisig output that locks bitcoin between two parties. The channel opening process, defined in BOLT #2, follows a specific sequence. The initiator sends an open_channel message. The acceptor responds with accept_channel, which includes a critical field: minimum_depth. This tells the initiator how many on-chain confirmations the acceptor requires before it considers the channel usable.

Once the initiator broadcasts the funding transaction, both parties wait. After the transaction reaches minimum_depth confirmations, they exchange channel_ready messages and the channel becomes operational. Most implementations default to requiring three to six confirmations, which translates to roughly 30 to 60 minutes of dead time.

The reason is double-spend prevention. Until the funding transaction is buried under sufficient proof-of-work, the channel initiator could broadcast a conflicting transaction that spends the same inputs elsewhere. If the acceptor had already forwarded payments through the unconfirmed channel, those funds would be lost. The confirmation requirement makes chain reorganizations that invalidate the funding output astronomically unlikely.

The UX cost: For a new Lightning user receiving their first payment, standard channel opens mean sitting through a multi-step process and then waiting 30+ minutes before they can actually use their wallet. This is the core onboarding problem that zero-conf channels attempt to solve.

How Zero-Conf Channels Work

Zero-conf channels (also called turbo channels) let peers use a channel immediately after the funding transaction is broadcast, without waiting for any confirmations. The protocol mechanism was standardized in BOLTs PR #910, merged in May 2022, which introduced the option_zeroconf feature bit (bit 50) to BOLT #2.

When both peers negotiate option_zeroconf as part of the channel type, the acceptor sets minimum_depth to zero. Both sides immediately exchange channel_ready messages instead of waiting for blocks. The channel is operational within seconds of the funding transaction entering the mempool.

The SCID Alias Requirement

Normal channels are identified by a Short Channel ID (SCID) derived from the funding transaction's position in a confirmed block. A zero-conf channel has no confirmed block position yet, so it cannot use a real SCID. The same BOLTs PR introduced option_scid_alias (feature bit 46), which lets peers establish an arbitrary alias for the channel. This alias is transmitted via TLV in the channel_ready message and used for all routing until the funding transaction confirms.

Because the channel lacks a confirmed on-chain output, it cannot be publicly announced via the gossip protocol. Zero-conf channels are private by default and only usable between the two directly connected peers until confirmation occurs. This means they are primarily useful for LSP-to-user connections rather than public routing infrastructure.

Protocol Constraints

The specification imposes several rules on zero-conf channels. Nodes must not send tx_init_rbf if option_zeroconf has been negotiated, because Replace-By-Fee on the funding transaction could invalidate the channel. The acceptor must set minimum_depth to exactly zero when the channel type includes option_zeroconf. And the channel type must also include option_scid_alias to handle identification before confirmation.

The Double-Spend Risk Window

The trust assumption in a zero-conf channel is explicit: the fundee trusts the funder not to double-spend the funding transaction. From the moment the funding transaction is broadcast until it accumulates sufficient confirmations, the funder could theoretically broadcast a conflicting transaction that spends the same inputs, invalidating the channel and any payments routed through it.

This window typically lasts 30 to 60 minutes under normal network conditions. During this period, any balance the fundee receives within the channel is at risk. If the funder replaces the funding transaction, the channel's multisig output never existed from the blockchain's perspective, and the fundee has no on-chain recourse.

Why LSPs Accept This Risk

In practice, Lightning Service Providers are the primary users of zero-conf channels, and they accept the double-spend risk for several reasons:

• In the most common scenario, the LSP is the one funding the channel and pushing initial balance to the user. Since the LSP controls the funding transaction, it has no incentive to double-spend its own output.
• Zero-conf channels are typically used for small amounts where the economic incentive to attack is negligible relative to the cost of executing a double-spend (transaction fees, reputation damage).
• LSPs operating public services have reputations to protect. As Muun documented in their turbo channel analysis, a double-spend “cannot happen secretly because it requires the service to deliberately make an on-chain transaction.”
• Nodes can monitor the mempool for conflicting transactions and take defensive action, such as refusing further payments through the channel, if a double-spend attempt is detected.
• Some implementations reject zero-conf requests for transactions that signal RBF, since RBF-signaling transactions are easier to replace.

JIT Channels: Zero-Conf in Action

Just-In-Time channels are the most common application of zero-conf channel opens. When a new user receives their first Lightning payment, the LSP intercepts the incoming HTLC, opens a new channel to the recipient on the fly, and forwards the payment through the freshly created channel. Without zero-conf, the HTLC would need to be held for 30+ minutes while waiting for confirmations, and Lightning HTLCs have finite expiry timeouts that would cause the payment to fail.

The LSPS2 specification (also published as bLIP-52) standardizes this JIT channel workflow. The client queries the LSP's fee structure, requests a channel, and receives a unique SCID alias to embed in their Lightning invoice. When payment arrives, the LSP opens a zero-conf channel and forwards the funds minus a service fee. The entire process completes in seconds from the payer's perspective.

Relationship between zero-conf and JIT: Zero-conf is the protocol mechanism; JIT channels are the product-level application of that mechanism. Zero-conf channels can exist without JIT (two peers manually opening a channel), but JIT channels fundamentally depend on zero-conf to deliver instant onboarding.

Implementation Support Across Lightning Nodes

All major Lightning implementations shipped option_zeroconf support within months of the specification being merged in May 2022. Each implementation takes a different approach to security configuration, reflecting varying philosophies about trust management.

The implementation differences reflect a consistent theme: zero-conf is opt-in and trust-explicit. No implementation enables it by default. Core Lightning's whitelist approach is the most restrictive, designed specifically for LSP operators who maintain known relationships with the peers they accept zero-conf channels from.

Wallets Using Zero-Conf Channels

Several mobile Lightning wallets rely on zero-conf channels to deliver instant onboarding. The most prominent implementations illustrate different approaches to managing the associated trust.

Phoenix (ACINQ)

Phoenix is the flagship example of zero-conf channel usage. Built on the Eclair implementation, Phoenix uses ACINQ as its sole LSP. When a user receives a payment that exceeds their current inbound liquidity, ACINQ opens a zero-conf JIT channel. Since ACINQ is the funder, the user does not bear double-spend risk: the LSP would be defrauding itself. Phoenix has evolved to use splicing to dynamically resize a single channel per user, combined with a swap-in-potentiam mechanism that further reduces trust assumptions after the initial channel open.

Breez

Breez pioneered the use of zero-conf JIT channels for non-custodial mobile Lightning. The classic Breez app used LND with the Breez LSP providing zero-conf channel opens for new users. In 2025, Breez launched Misty Breez, which migrated to the Liquid sidechain with submarine swaps, moving away from direct channel management. The Breez SDK remains available for developers building Lightning applications.

Zeus

Zeus operates its own LSP, Olympus, which provides zero-conf JIT channels with tiered fee structures. Zeus uses an embedded LND node on the user's device, giving users more control over their node while still benefiting from instant channel opens via the LSP.

Risk and Benefit Analysis by User Type

The appropriateness of zero-conf channels depends heavily on who is using them and in what context. The trust assumptions carry different weight for different participants.

End Users Receiving from an LSP

This is the lowest-risk scenario. The LSP funds the channel and pushes balance to the user. The user bears no double-spend risk because the LSP controls the funding transaction and would only be defrauding itself. The primary risk for the user is that the LSP could go offline before the funding transaction confirms, but this would affect liveness rather than safety: the user simply would not be able to send payments until the situation resolves.

LSPs Accepting User-Funded Channels

This is the highest-risk scenario. The LSP trusts that the user will not double-spend the funding transaction. For small amounts from known users, this risk is manageable. For large amounts from anonymous users, the incentive to double-spend may exceed the deterrent. Most LSPs mitigate this by capping zero-conf channel sizes, monitoring the mempool for conflicting transactions, and restricting the feature to users with established accounts or completed identity verification.

Routing Node Operators

Routing nodes generally should not accept zero-conf channels from unknown peers. A routing node that accepts a zero-conf channel and then forwards payments through it is exposed to the full double-spend risk on the channel's capacity. The specification's restriction against public announcement before confirmation provides a natural guardrail: zero-conf channels cannot be used for public routing until they confirm.

Merchant Point-of-Sale

Merchants accepting Lightning payments through an LSP benefit from zero-conf channels indirectly. The LSP handles channel management, and payments routed to the merchant through existing channels are not affected by the zero-conf trust model. However, if a merchant's wallet opens a new zero-conf channel to receive a large payment, the double-spend window applies. This is one reason most Lightning POS implementations rely on pre-established channels rather than on-the-fly opens for receiving.

The Evolving Landscape: Beyond Zero-Conf

The Lightning ecosystem is not standing still on the channel-opening problem. Several developments are reshaping how wallets handle onboarding, each offering different tradeoffs.

Splicing and Swap-in-Potentiam

Splicing allows dynamically adding or removing funds from an existing channel without closing it. Combined with swap-in-potentiam (a mechanism where on-chain funds are pre-committed to a potential channel splice), this reduces the frequency of new channel opens. Phoenix adopted this approach: after the initial channel is established, subsequent deposits use splicing with zero-conf properties rather than opening entirely new channels.

Submarine Swaps and Liquid

Submarine swaps allow moving funds between on-chain Bitcoin and Lightning without opening a channel at all. Breez's migration to Liquid-based submarine swaps represents a shift away from zero-conf channel management toward swap-based architectures. This trades the zero-conf trust assumption for the trust model of the Liquid federation.

Protocols Without Channels

Spark takes a fundamentally different approach to the instant-onboarding problem. Rather than optimizing how channels are opened, Spark eliminates the concept of channels entirely. Transfers happen by updating ownership of statechain-based leaves: the Bitcoin remains in the same on-chain output while cryptographic key material is rotated between sender and recipient.

This means a new Spark user can send and receive bitcoin from their very first transaction without any channel setup, confirmation wait, or trust assumption about unconfirmed on-chain transactions. There is no funding transaction to double-spend because there is no channel to fund. The tradeoff shifts from on-chain confirmation trust (zero-conf) to operator honesty trust (1-of-n operators must behave correctly during each transfer). For a deeper look at how this architecture compares to channel-based systems, see the analysis of Spark's channel-free design.

Different trust models, same goal: Zero-conf channels trade confirmation security for instant usability during a finite window. Spark trades channel infrastructure entirely for a different trust model based on operator key management. Both aim to solve the same problem: making Bitcoin payments instant for new users.

Comparing Onboarding Approaches

When Zero-Conf Channels Make Sense

Zero-conf channels are a practical solution for specific scenarios, not a universal improvement over standard channel opens. They work best when:

• The LSP is the funder and bears its own double-spend risk (the standard JIT channel model).
• Channel amounts are small enough that the cost of attack exceeds the potential gain.
• The two peers have an established, ongoing relationship (LSP and regular user).
• Instant onboarding is a product requirement and the trust window is acceptable.

They are inappropriate when the fundee cannot tolerate any double-spend risk, when channel amounts are large relative to the attacker's cost, or when the channel needs to be publicly announced immediately for routing.

For developers building on Lightning, the choice between zero-conf channels, splicing-based approaches, and channel-free protocols like Spark depends on the specific UX requirements and acceptable trust model. The Spark SDK documentation provides integration guides for developers exploring the channel-free approach, while the LSPS specifications standardize the zero-conf JIT channel workflow for Lightning-native implementations.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.