Turbo Channel

What Is a Turbo Channel?

A turbo channel is a Lightning channel that can be used immediately after the funding transaction is broadcast, without waiting for any block confirmations. Standard Lightning channel opens require the funding transaction to reach a minimum depth (typically three to six confirmations) before either party can route payments through the channel. This translates to roughly 30 to 60 minutes of dead time before a new channel becomes usable.

Turbo channels eliminate that wait by having the channel funder (usually an LSP) trust that the funding transaction will eventually confirm. The channel becomes operational within seconds of broadcast, allowing users to send and receive payments almost instantly after opening their first Lightning wallet.

The term "turbo channel" originated with Bitrefill's Thor service in 2019, when the company added a "Turbo" option that allowed users to start spending through their new channel without waiting for confirmations. As more implementations adopted the same approach, the Lightning community standardized the concept under the name "zero-conf channels" with the option_zeroconf feature bit. Today, the two terms refer to the same mechanism, though "turbo channel" persists in some wallets and documentation.

How It Works

To understand turbo channels, it helps to see how a standard channel open compares to a zero-conf open.

Standard Channel Open

1. The funding party creates and broadcasts a funding transaction that locks bitcoin into a 2-of-2 multisig output
2. Both nodes watch for the transaction to appear in the mempool
3. The accepting node specifies a minimum_depth (commonly three to six blocks)
4. Both nodes wait for the funding transaction to reach the required confirmation depth
5. Once the depth is reached, both sides exchange channel_ready messages (formerly called funding_locked)
6. The channel is now open for routing payments

This process ensures the funding transaction is irreversible before either party risks funds through the channel. The confirmation requirement protects against scenarios where the funder could broadcast a conflicting transaction that spends the same inputs, invalidating the channel.

Turbo (Zero-Conf) Channel Open

1. The funding party creates and broadcasts the funding transaction
2. The accepting node sets minimum_depth to zero and immediately sends channel_ready
3. The channel becomes usable within seconds of broadcast, before any block includes the funding transaction
4. Payments can flow through the channel while the funding transaction confirms in the background

The key difference: the accepting node skips the confirmation wait and trusts the funding transaction to eventually confirm. This trust is one-directional: it flows from the acceptor (typically the LSP) toward the funder (the user or the LSP itself).

The Trust Model

The safety of a turbo channel depends on who funded it and who holds the initial balance:

• When the LSP funds the channel and pushes balance to the user, the LSP trusts itself not to double-spend its own funding transaction. Since the LSP controls the inputs, it is the only party that could create a conflicting transaction. This makes the trust assumption trivial: the LSP would only be defrauding itself.
• When a user funds a channel to an LSP, the LSP trusts the user not to double-spend. This is riskier, because the user controls the funding inputs and could broadcast a conflicting transaction using replace-by-fee. In practice, LSPs mitigate this by limiting the channel size or only accepting zero-conf from users with established history.

In the most common deployment (LSP-funded channels for mobile wallet onboarding), the trust assumption is minimal. The LSP is essentially trusting its own broadcast, which it has no incentive to reverse.

Protocol-Level Mechanism

At the specification level, turbo channels use the option_zeroconf channel type negotiated during the channel open handshake. When both peers support zero-conf:

# Channel type negotiation includes option_zeroconf
open_channel2:
  channel_type: [option_static_remotekey, option_anchors, option_zeroconf]

# Acceptor immediately sends channel_ready with minimum_depth = 0
accept_channel2:
  minimum_depth: 0

# Both sides exchange channel_ready before any confirmations
channel_ready:
  channel_id: <temporary_channel_id>

One important restriction: nodes must not send announcement_signatures (which make the channel publicly visible in the network graph) until the funding transaction has at least six confirmations. This means turbo channels operate as private channels until the funding transaction is sufficiently confirmed.

Use Cases

Instant Mobile Wallet Onboarding

The primary use case for turbo channels is removing the onboarding delay for new Lightning users. When a user installs a Lightning wallet like Phoenix or Breez, the wallet's LSP opens a turbo channel so the user can start transacting immediately. Without turbo channels, the user would need to wait 30 to 60 minutes after their first deposit before they could make a payment.

This instant onboarding is critical for adoption. A user trying Lightning for the first time is unlikely to wait an hour to make their first payment. Turbo channels make the experience feel as fast as installing any other payment app.

Just-in-Time Channel Provisioning

JIT channels (also called just-in-time channels) combine turbo channels with on-demand channel creation. When a user receives their first Lightning payment, the LSP opens a turbo channel, pushes the incoming payment into it, and the user sees the funds instantly. The channel creation, funding, and first payment all happen in a single flow without any confirmation delay.

Exchange Withdrawals

Exchanges and services can open turbo channels to users withdrawing funds to Lightning. Because the exchange controls the funding transaction, it trusts itself not to double-spend, making the zero-conf assumption safe. This was the original use case described by Bitrefill's Thor Turbo service, which allowed users to open a channel with spendable bitcoin without waiting for confirmations.

Channel Liquidity Services

Services that sell inbound liquidity (such as liquidity ads or dedicated channel marketplaces) can use turbo channels to deliver purchased channel capacity immediately. The buyer pays for a channel and can start receiving payments within seconds rather than waiting for confirmation.

History and Adoption

The concept of skipping confirmation requirements for trusted channel opens existed informally from the early days of the Lightning Network, but the first widely publicized implementation came from Bitrefill. In 2019, the company added a "Turbo" option to its Thor channel service, allowing users to skip the roughly 60-minute wait for six confirmations. John Carvalho, then COO of Bitrefill, described it as a "purchased access" model where users trust Bitrefill to deliver on the channel funding.

Other wallet providers adopted the same approach independently. ACINQ implemented turbo channels in Phoenix wallet, and Breez built zero-conf channel opens into its mobile wallet. Each implementation used its own ad hoc mechanism before any formal specification existed.

In June 2021, a discussion on the Lightning development mailing list sought to formalize turbo channels into the BOLT specification. Bastien Teinturier proposed using a dedicated option_zeroconf channel type rather than simply setting minimum_depth to zero, which was considered ambiguous and unenforceable. This led to a formal spec proposal.

By 2022, zero-conf channels were standardized and implemented across major Lightning node software: LND added support in version 0.15.1-beta, and Core Lightning added support in version 0.12. The term "zero-conf channel" became the canonical name in specifications and documentation, though "turbo channel" remains in common use.

For a detailed analysis of the trust tradeoffs involved in zero-conf channels, see Zero-Conf Lightning Channels: Speed vs Trust in Instant Channel Opens.

Turbo Channels vs. Standard Channel Opens

Risks and Considerations

Double-Spend Exposure

The fundamental risk of any turbo channel is that the funding transaction can be replaced before it confirms. If the funder broadcasts a conflicting transaction with a higher fee (using RBF), the funding transaction may never confirm, and any payments routed through the channel in the interim become invalid. The party that accepted those payments loses funds.

In practice, this risk is mitigated by the LSP-funded model: when the LSP both funds and operates the channel, double-spending would mean the LSP is stealing from itself. For user-funded turbo channels, LSPs typically cap the channel size at small amounts to limit exposure.

Routing Through Unconfirmed Channels

Multi-hop payments that route through an unconfirmed turbo channel inherit its risk. If the funding transaction is double-spent, all HTLCs in flight through that channel become unenforceable. Routing nodes generally avoid forwarding payments through channels they cannot verify on-chain, which is why turbo channels are typically used only for the last hop between an LSP and its direct user.

Force-Close Complications

If a dispute arises and one party attempts a force close on an unconfirmed turbo channel, the commitment transaction cannot confirm until the funding transaction confirms first. This creates a dependency chain: the force close is stuck until the funding transaction makes it into a block. Meanwhile, the funder could still double-spend the funding transaction, invalidating the entire channel and any pending HTLCs.

Not Suitable for Large Amounts

Because the double-spend risk scales with the channel value, turbo channels are best suited for small to medium amounts where the potential loss is acceptable to the LSP. High-value channels should use standard confirmation requirements to ensure the funding transaction is irreversible before the channel is used.

Why It Matters

Turbo channels solved one of the biggest UX problems in Lightning: the cold start. Before turbo channels, a new user needed to fund a channel and then wait for confirmations before they could do anything. This confirmation delay made Lightning feel slow at the exact moment when first impressions matter most.

By accepting a small, well-understood trust tradeoff, LSPs transformed the onboarding experience from "wait an hour" to "start immediately." This pattern proved so effective that it became the default behavior in most consumer Lightning wallets and was eventually codified into the Lightning protocol itself.

Layer 2 protocols like Spark take a different architectural approach that avoids the channel model entirely, eliminating both the confirmation delay and the channel management complexity that turbo channels were designed to address.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.