Overview
A dual-funded channel is a Lightning channel where both parties contribute bitcoin to the funding transaction, as opposed to the traditional single-funded model where only the channel opener provides funds. This seemingly simple change has profound implications for liquidity management on the Lightning Network, because it means the channel has usable capacity in both directions from the moment it opens.
In the standard single-funded model, the channel opener starts with all the capacity on their side (outbound liquidity) and zero on the remote side (inbound liquidity). This creates an immediate imbalance: the opener can send but cannot receive. Dual funding eliminates this cold-start problem by ensuring both sides of the channel have funds from the beginning.
How It Works
Dual-funded channel opening uses an interactive transaction construction protocol where both parties exchange input and output information to collaboratively build the funding transaction. This is defined in the Lightning specification and replaces the simpler single-funder flow.
Single-Funded Channel:
┌────────────────────────────────────┐
│ Funding TX │
│ Input: Alice's UTXO (1.0 BTC) │
│ Output: 2-of-2 multisig (1.0 BTC) │
└────────────────────────────────────┘
Result:
┌──────────────────────────────┐
│ Alice: 1.0 BTC │ Bob: 0 BTC │
│ ██████████████ │ │
└──────────────────────────────┘
Alice can send 1.0, receive 0
Bob can send 0, receive 1.0
Dual-Funded Channel:
┌─────────────────────────────────────────┐
│ Funding TX │
│ Inputs: Alice's UTXO (0.6 BTC) │
│ Bob's UTXO (0.4 BTC) │
│ Output: 2-of-2 multisig (1.0 BTC) │
└─────────────────────────────────────────┘
Result:
┌──────────────────────────────────┐
│ Alice: 0.6 BTC │ Bob: 0.4 BTC │
│ █████████ │ ██████ │
└──────────────────────────────────┘
Alice can send 0.6, receive 0.4
Bob can send 0.4, receive 0.6
Interactive Transaction Protocol
The interactive construction protocol works as a negotiation between the two peers:
Alice Bob
│ │
│ ── open_channel2 ──────────────► │
│ ◄── accept_channel2 ──────────── │
│ │
│ ── tx_add_input (Alice's UTXO) ─►│
│ ◄── tx_add_input (Bob's UTXO) ── │
│ ── tx_add_output (funding out) ─►│
│ ◄── tx_complete ──────────────── │
│ ── tx_complete ─────────────────►│
│ │
│ Both sign the funding TX │
│ ── commitment_signed ──────────► │
│ ◄── commitment_signed ────────── │
│ │
│ Funding TX broadcast │
Both parties exchange their inputs and outputs in rounds until both signal tx_complete. This interactive process ensures neither party can manipulate the transaction to their advantage.
Liquidity Marketplaces
Dual funding enables liquidity marketplaces where nodes can negotiate compensation for providing channel liquidity. A well-connected routing node might agree to contribute funds to a channel in exchange for a fee, because the resulting routing fees will compensate for the capital lockup. This creates a natural market for inbound liquidity, one of the most persistent challenges for new Lightning nodes.
The liquidity ads protocol (built on top of dual funding) allows nodes to advertise their willingness to provide channel liquidity at a specified rate, enabling automated matching between nodes that need inbound capacity and those willing to provide it.
Security Considerations
The interactive transaction protocol introduces complexity not present in single-funded channels. Both parties must carefully validate each other's inputs to prevent attacks. For example, a malicious peer could provide invalid inputs that cause the funding transaction to be rejected by the network, wasting the honest party's on-chain fees. Implementations mitigate this through careful input validation and requiring both parties to commit before either signs.
Related Concepts
- Lightning Channel — the standard channel construction that dual funding enhances
- Liquidity — the bidirectional capacity that dual funding provides from channel creation
- Open Channel — the channel opening process that dual funding extends
- Rebalancing (Lightning) — a liquidity management technique that dual funding reduces the need for