Dual-Funded Channel

What Is a Dual-Funded Channel?

A dual-funded channel is a Lightning Network channel where both participants put bitcoin into the opening transaction. In the original (v1) channel protocol, only the initiator provides funds: they deposit bitcoin, and all initial capacity sits on their side. The counterparty starts with zero sending capacity and zero receiving capacity from their perspective. A dual-funded channel eliminates this asymmetry by letting both sides contribute from the start.

The protocol that makes this possible is called the version 2 (v2) channel establishment protocol, specified in BOLT 2. It was formally merged into the Lightning specification in February 2024 (feature bits 28/29, option_dual_fund) after more than four years of development. The first dual-funded mainnet channel was opened in May 2021 using c-lightning (now Core Lightning).

How It Works

Dual-funded channel opens rely on a turn-based message exchange called the interactive-tx protocol. Rather than one side building the funding transaction alone, both peers collaboratively construct it by taking turns adding their inputs and outputs.

The Interactive-TX Protocol

The channel open proceeds through these steps:

1. The initiator sends open_channel2 with proposed channel parameters: their funding amount, feerates, dust limits, HTLC limits, and channel flags
2. The acceptor responds with accept_channel2, specifying their own contribution amount and parameters
3. Both parties enter the interactive construction phase, taking turns sending tx_add_input and tx_add_output messages to build the funding transaction
4. Either party may send tx_remove_input or tx_remove_output to revise their contributions
5. When a party is finished, they send tx_complete. Negotiation ends only when both parties send tx_complete consecutively
6. Both peers independently construct the identical funding transaction and compute the txid
7. Both exchange commitment_signed messages (ensuring either side can force-close if needed)
8. Both exchange tx_signatures with their witnesses for the funding transaction
9. The initiator broadcasts the funding transaction to the Bitcoin network
10. After sufficient blockchain confirmations, both send channel_ready and the channel activates

Message Reference

The interactive-tx protocol defines these message types in the specification:

open_channel2    (type 64)  — Propose dual-funded channel
accept_channel2  (type 65)  — Accept with contribution parameters
tx_add_input     (type 66)  — Add input to funding transaction
tx_add_output    (type 67)  — Add output to funding transaction
tx_remove_input  (type 68)  — Remove previously added input
tx_remove_output (type 69)  — Remove previously added output
tx_complete      (type 70)  — Signal done adding/removing
tx_signatures    (type 71)  — Exchange funding tx witnesses
tx_init_rbf      (type 72)  — Initiate RBF fee bump
tx_ack_rbf       (type 73)  — Acknowledge RBF attempt

Initiators use even serial IDs for their inputs and outputs; acceptors use odd serial IDs. This prevents collisions when both sides add elements to the same transaction. The final transaction orders all inputs and outputs by serial ID, and all inputs must be SegWit to prevent txid malleability.

Fee Responsibility

Each peer pays for the on-chain fees attributable to their own inputs and outputs. The initiator additionally covers fees for common transaction fields: the version, segwit marker, input/output counts, and locktime. This distribution is fairer than v1 channels, where the opener bears the entire fee burden regardless of who benefits from the channel.

Why It Matters

The original single-funded channel model creates a bootstrapping problem. A new merchant node that wants to receive Lightning payments cannot do so until someone else opens a channel to them, providing inbound liquidity. This forces merchants to rely on Lightning Service Providers, pay for channel leases, or use workarounds like Loop to acquire receiving capacity.

Dual-funded channels solve this directly. Both parties contribute funds, so the channel has immediate capacity in both directions. A merchant can open a channel, contribute a small amount, and receive payments right away using the counterparty's contribution. No separate rebalancing transactions are needed.

Beyond solving liquidity bootstrapping, the interactive-tx protocol is the shared foundation for splicing (resizing live channels) and liquidity ads (a decentralized marketplace for channel liquidity). These features reuse the same collaborative transaction construction logic, making dual funding the infrastructure layer for the next generation of Lightning channel management. For a deeper look at how these tools work together, see the Lightning Network liquidity guide.

Use Cases

Merchant Onboarding

A business joining the Lightning Network can open dual-funded channels with routing nodes, contributing a small amount while the routing node provides the majority of funds. The merchant gets immediate receiving capacity without relying on third-party liquidity services. As customers pay the merchant, the balance shifts naturally toward the merchant's side.

Liquidity Ads

Liquidity ads (proposed in BOLTs #878, option_will_fund) build directly on dual funding. Nodes advertise their willingness to contribute liquidity via the Lightning gossip network, specifying lease durations and fees. Any node can browse these offers and open a dual-funded channel where the advertiser provides the agreed capacity for a fee. This creates a decentralized market for channel capacity without centralized intermediaries.

Peer-to-Peer Channel Balancing

Two routing nodes that frequently route payments between each other can open a dual-funded channel where both contribute equally. This eliminates the lopsided initial state of single-funded channels and reduces the need for circular rebalancing operations. The channel starts balanced and can handle traffic in both directions from the first block confirmation.

On-the-Fly Funding

Some implementations (notably Eclair) use dual funding for automatic liquidity provisioning. When a payment cannot be relayed due to insufficient capacity, the node automatically triggers a dual-funded channel open or splice to add the needed liquidity. This creates a seamless experience where channels grow to meet demand without manual intervention.

Implementation Status

Support varies across Lightning implementations:

Risks and Considerations

UTXO Privacy Exposure

During the interactive-tx negotiation, both parties reveal which UTXOs they own by adding inputs to the funding transaction. A malicious node could request dual-funded channel opens with many peers specifically to enumerate their UTXO sets without ever completing the channel. A mitigation called PoDLE (Proof of Discrete Log Equivalence) was discussed but ultimately deferred from the specification, since the UTXOs used for channel funding become publicly visible on-chain shortly after the channel opens.

Liquidity Griefing

An attacker can enter the interactive-tx negotiation, add inputs, and then abandon the protocol without completing the channel. The honest peer's UTXOs remain locked for the negotiation timeout period. The attacker pays no on-chain cost since no transaction is ever broadcast. Nodes can mitigate this by reusing the same UTXOs across simultaneous negotiations (so one griefing attempt does not freeze funds globally) and by requiring confirmed inputs via the require_confirmed_inputs TLV.

Implementation Complexity

The turn-based interactive protocol is significantly more complex than v1 channel opens. Both peers must be online throughout the negotiation, handle multiple round trips, validate each other's inputs and outputs, and correctly manage state across potential failures or restarts. This complexity is one reason adoption has been slower across implementations: only Core Lightning and Eclair offer production support as of 2026.

Fake Channel Attacks

In 2023, security researcher Matt Morehouse discovered a related vulnerability during dual funding review: attackers could create hundreds of thousands of fake channels by sending valid open_channel messages but never broadcasting funding transactions. Victim nodes allocated resources watching for confirmations for approximately two weeks per fake channel. All four major implementations were affected and subsequently patched with per-peer pending channel limits.

Dual-Funded Channels vs. Single-Funded Channels

For a broader comparison of Lightning channel management strategies, see the Lightning channel management guide and the splicing deep dive.

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.