Dual funding
Dual funding is a Lightning Network channel-opening protocol in which both peers can contribute inputs to the funding transaction, so the channel can open with a non-zero balance on both sides. It is the motivating use of the version 2 channel establishment flow in BOLT 2. Feature bits 28/29 advertise option_dual_fund.
The original Lightning open is single-funded: one peer pays the entire funding output and on-chain fees, and the other starts with no outbound liquidity until it receives payments or later adjusts the channel. Dual funding lets each peer put coins into the same 2-of-2 or Taproot funding output in one on-chain transaction.
Interactive construction
Peers that support the feature exchange open_channel2 and accept_channel2, then build the funding transaction interactively with tx_add_input, tx_add_output, remove messages, and tx_complete, followed by commitment setup and tx_signatures. Because both sides may contribute inputs, the unconfirmed funding transaction can be fee-bumped with Replace by fee by repeating interactive construction at a higher feerate. Dual funding does not by itself change HTLC routing. Both peers need on-chain UTXOs. A peer with no coins cannot dual-fund.
Interactive construction is shared with later channel updates that also rebuild funding, notably Splicing. Either peer may abort before signatures if the other's proposed inputs, outputs, or fees are unacceptable. Commitment transactions for the dual-funded channel still follow the ordinary Lightning penalty model after the funding outpoint is locked. Feature advertisement uses BOLT 9 bits 28 and 29. Implementations must agree on those bits before open_channel2 is useful.
Deployment
Some implementations combine dual funding with zero-confirmation acceptance of the funding transaction among trusting peers. That speeds first receive but reintroduces 0-conf risk on the channel capacity itself until the funding outpoint confirms. Public dual-funded channels still need gossip announcement rules and reserve balances like any other public channel.
Core Lightning was an early production adopter of interactive funding and option_dual_fund. Other implementations expose subsets of the v2 open messages or prefer single-fund opens plus later Splicing. Interoperability failures usually show up as peers advertising mismatched feature bits or aborting interactive construction when input ownership proofs disagree.
Peers that only implement single-funded opens can still connect. Dual funding activates only when both advertise option_dual_fund and complete the v2 handshake.