Zero-Conf Channels

What Are Zero-Conf Channels?

A zero-conf channel (also called a turbo channel or zero-confirmation channel) is a Lightning channel that both parties agree to use before the funding transaction has been confirmed in a Bitcoin block. In the standard channel opening flow, both nodes wait for the funding transaction to receive a minimum number of confirmations (typically three to six) before they begin forwarding payments. This waiting period can take 30 minutes to over an hour depending on block times and fee rates.

Zero-conf channels eliminate this delay by allowing the channel to become active as soon as the funding transaction is broadcast to the mempool. Both parties cooperate to treat the unconfirmed channel as valid, enabling instant payment routing. The tradeoff is a temporary window of trust: until the funding transaction confirms, the funder could theoretically double-spend it and invalidate the channel.

This concept was formalized in BOLT proposals and has been adopted widely by Lightning Service Providers (LSPs) to offer seamless onboarding. For a deeper exploration of the mechanics and security model, see our research article on zero-conf Bitcoin.

How It Works

Opening a standard Lightning channel involves several steps, and zero-conf modifies the final waiting phase:

Standard Channel Opening

1. Two nodes exchange open_channel and accept_channel messages
2. The funder creates and broadcasts the funding transaction
3. Both nodes wait for the transaction to receive sufficient confirmations
4. Once confirmed, both nodes exchange channel_ready (formerly funding_locked) messages
5. The channel becomes active and can route payments

Steps 3 and 4 introduce the delay. With zero-conf, these steps are modified:

Zero-Conf Channel Opening

1. The acceptor signals option_zeroconf in the accept_channel message, indicating willingness to use the channel before confirmation
2. The funder creates and broadcasts the funding transaction
3. Both nodes immediately exchange channel_ready messages without waiting for confirmations
4. The channel is active and can route payments within seconds

The critical protocol detail is the minimum_depth field. In standard channels, the acceptor sets this to the number of confirmations required (typically 3 or 6). For zero-conf, the acceptor sets minimum_depth=0, signaling that no confirmations are needed.

SCID Aliases

A key technical challenge with zero-conf channels is identification. Standard Lightning channels are identified by Short Channel IDs (SCIDs) derived from the funding transaction's position in a confirmed block: the block height, transaction index, and output index. An unconfirmed transaction has no block position, so it cannot have a real SCID.

SCID aliases solve this by assigning a temporary, locally meaningful identifier to the channel. Each node generates a random alias and communicates it in the channel_ready message:

// channel_ready message with SCID alias
{
  "channel_id": "a]f8c2...funding_txid",
  "second_per_commitment_point": "02abc...",
  "short_channel_id_alias": "1234567x0x0"
}

These aliases serve two purposes: they allow unconfirmed channels to participate in route hints and invoice routing, and they provide a privacy benefit by hiding the on-chain funding UTXO from the public channel graph. Even after confirmation, nodes can continue using the alias instead of the real SCID.

The Trust Model

The security of zero-conf channels depends on understanding exactly who trusts whom. Consider two parties: Alice (the funder) and Bob (the acceptor, typically an LSP).

• Alice funds the channel with her on-chain Bitcoin. Until the funding transaction confirms, Alice could broadcast a conflicting transaction that spends the same inputs, effectively double-spending the funding UTXO.
• Bob accepts the channel and begins routing payments through it. If Alice double-spends the funding transaction, Bob loses any funds he has forwarded through the channel.
• Alice bears no risk from the zero-conf arrangement because her funds remain under her control until confirmed.

In practice, this means Bob (the acceptor) is the party who trusts Alice. This is why zero-conf channels are almost always initiated by LSPs who open channels to their users: the LSP trusts the user not to double-spend during the confirmation window. Since the user typically receives funds through the channel rather than sending them, the LSP's exposure is limited.

Use Cases

LSP-Powered Instant Onboarding

The primary use case for zero-conf channels is mobile wallet onboarding. When a new user installs a Lightning wallet, they need a channel to send and receive payments. Without zero-conf, they would wait 30 to 60 minutes for the channel to confirm before making their first payment.

With zero-conf, the flow becomes:

1. User installs the wallet and initiates setup
2. The wallet's LSP opens a zero-conf channel to the user
3. The channel is usable within seconds
4. The user can receive their first Lightning payment immediately

Popular wallets like Phoenix and Breez use this pattern. The LSP bears the double-spend risk, which is minimal for small initial channels and can be mitigated through rate limiting and reputation systems.

Just-in-Time Liquidity

Zero-conf channels enable just-in-time (JIT) channel creation, where an LSP opens a new channel precisely when a user needs to receive a payment. Instead of pre-provisioning channels, the LSP intercepts an incoming HTLC destined for a user, opens a zero-conf channel on the fly, and forwards the payment through it.

This approach optimizes capital efficiency: the LSP only commits funds to channels that are actively receiving payments, rather than maintaining idle channels for users who may never transact.

Channel Upgrades and Resizing

When combined with splicing, zero-conf enables instant channel capacity changes. A node can splice in additional funds to increase channel capacity and continue using the channel at its new size without waiting for the splice transaction to confirm. This is particularly useful for routing nodes that need to respond quickly to liquidity demands.

Rapid Rebalancing

Routing nodes that need to rebalance their channels can use zero-conf to open new channels as part of a rebalancing strategy. Combined with Loop or similar services, this allows nodes to restructure their liquidity without extended downtime.

Risks and Considerations

Double-Spend Risk

The fundamental risk of zero-conf channels is the double-spend window. Until the funding transaction confirms, the funder can replace it with a conflicting transaction. If the acceptor has already forwarded payments through the channel, those funds are lost.

Several factors affect the practical severity of this risk:

• Transaction propagation: once a transaction is widely propagated across the mempool, replacing it becomes more difficult (though not impossible with RBF)
• Replace-by-fee (RBF): if the funding transaction signals RBF, it can be trivially replaced with a higher-fee conflicting transaction, increasing double-spend risk
• Channel direction: if the acceptor only receives through the channel (as in LSP-to-user channels), the funder has no incentive to double-spend because they would be stealing from themselves

Mitigation Strategies

LSPs and implementations employ several strategies to manage zero-conf risk:

• Limit channel size: restrict zero-conf channels to small amounts where the double-spend payoff is not worth the effort
• Monitor the mempool: watch for conflicting transactions that could indicate a double-spend attempt, and freeze the channel if detected
• Restrict to known peers: only offer zero-conf to users with established history or verified identity
• Direction-aware risk: only allow inbound payments to the user through zero-conf channels until confirmation, preventing the user from forwarding funds outward

Network-Level Considerations

Zero-conf channels interact with the broader Lightning Network in ways that require careful handling. Routing nodes that encounter an unconfirmed channel in a payment path must decide whether to trust it. In practice, this is handled by keeping zero-conf channels private (not announced to the network graph) and using SCID aliases in route hints so that only the direct counterparty needs to trust the unconfirmed state.

Once the funding transaction confirms, the channel can optionally be announced to the network like any standard channel. The transition from zero-conf to fully confirmed is seamless: the channel continues operating with the same state, and the only change is that the double-spend risk disappears.

Comparison to Standard Channels

Spark and Zero-Conf

Spark takes a fundamentally different approach to the channel management problem that zero-conf channels address. Rather than requiring users to open, manage, and close individual Lightning channels, Spark operates as a Bitcoin layer that provides instant transfers without channel constraints. Users on Spark benefit from immediate transaction finality without the trust tradeoffs inherent in zero-conf channels and without waiting for on-chain confirmations.

Where zero-conf channels solve the onboarding delay for Lightning wallets, Spark eliminates the need for per-user channel management entirely. This removes both the confirmation wait time and the associated double-spend risk window, while maintaining self-custodial guarantees through its cooperative signing model.