Dual-Funded Lightning Channels: Solving the Inbound Liquidity Bootstrap Problem

Every new Lightning node faces the same bootstrapping problem: it can send payments immediately but cannot receive a single satoshi. All capacity in a newly opened channel sits on the opener's side, leaving zero inbound liquidity until someone else opens a channel back or the node pushes funds outward by spending. Dual-funded channels attack this problem at the protocol level, letting both sides of a channel contribute funds to the opening transaction so that inbound capacity exists from the first block confirmation.

This article breaks down how dual-funded channels and liquidity ads work, what they cost, and how they compare to other approaches for bootstrapping inbound capacity on the Lightning Network.

Why Inbound Liquidity Is Hard

The original Lightning channel establishment protocol (v1) is single-funder: the node that opens the channel puts up all the bitcoin. The opener gets outbound capacity equal to the channel size, while the remote peer gets inbound capacity of the same amount. But from the opener's perspective, inbound capacity is zero. To receive payments, someone else must open a channel toward you, or you must spend down your outbound balance to shift sats to the remote side.

For a merchant or service that primarily receives payments, this creates a chicken-and-egg problem. You need inbound liquidity to receive, but you need to be connected and routing-worthy before other nodes will open channels to you. The result is that new nodes either wait passively (hoping for inbound channels), pay third parties for liquidity, or resort to circular rebalancing strategies that burn routing fees without creating net new capacity.

The asymmetry in numbers: A node that opens a 1,000,000 sat channel can immediately send up to ~990,000 sats (minus channel reserve), but its inbound capacity is exactly 0 sats. It cannot receive any payment until capacity shifts to the remote side.

How Dual-Funded Channels Work

Dual-funded channels (v2 channel establishment, feature bits 28/29) allow both parties to contribute inputs and outputs to the funding transaction. If Alice opens a 2,000,000 sat channel with Bob and each contributes 1,000,000 sats, Alice starts with 1,000,000 sats of outbound capacity and 1,000,000 sats of inbound capacity. The bootstrapping problem disappears for that channel.

The specification was proposed by Lisa Neigut (niftynei) at Blockstream, who posted the initial draft of the interactive transaction construction protocol to the lightning-dev mailing list in February 2020. The formal specification (BOLTs PR #851) went through nearly three years of review before being merged into the BOLT 2 specification in February 2024.

The Interactive-TX Protocol

The core innovation enabling dual-funded channels is the interactive transaction construction protocol, specified in BOLT 2. Rather than one party building the entire funding transaction, both peers take turns contributing inputs and outputs through a structured negotiation.

After exchanging open_channel2 and accept_channel2 messages, the initiator and non-initiator alternate turns using a set of purpose-built message types:

Each contribution carries a serial_id for ordering: even IDs for the initiator, odd for the non-initiator. Negotiation ends when both peers send consecutive tx_complete messages. The final transaction is assembled with inputs and outputs sorted by serial_id, both peers exchange commitment_signed and tx_signatures, and the funding transaction is broadcast.

Protocol Constraints

The interactive-tx protocol enforces several safety rules. All external inputs must use SegWit to prevent txid malleability. The funding transaction is limited to 252 inputs, 252 outputs, and 400,000 weight units. A require_confirmed_inputs TLV lets either peer demand that all contributed inputs are already confirmed on-chain, mitigating transaction pinning attacks.

Unlike v1 channels, the channel_id in v2 is derived from the lesser and greater revocation basepoints (via SHA-256) rather than the funding txid. This accommodates RBF fee-bumping of the funding transaction using the tx_init_rbf and tx_ack_rbf messages (type IDs 72 and 73), which allow peers to renegotiate fees after the initial negotiation without changing the channel identity.

Liquidity Ads: A Marketplace for Inbound Capacity

Dual-funded channels solve the mechanical problem (both sides can contribute funds), but they do not solve the economic problem: why would a remote peer lock up capital in your channel? Liquidity ads provide the incentive layer. A node advertises its willingness to provide inbound liquidity at a stated price, and any peer can accept the offer during dual-funded channel establishment.

The liquidity ads specification (BOLTs PR #878), also authored by Lisa Neigut, proposes an option_will_fund TLV in node_announcement gossip messages. Nodes broadcast their liquidity offers to the entire network, and any compatible peer can take them up during channel opening.

Pricing Parameters

Liquidity ads use a six-parameter pricing model that covers both the upfront cost of the lease and the ongoing routing fee caps:

• lease_fee_base_msat: a flat fee for the liquidity lease (e.g., 500 sats)
• lease_fee_basis: a proportional charge in basis points of the requested amount (e.g., 50 bps = 0.5%)
• funding_weight: the transaction weight the buyer pays for in the opening transaction
• channel_fee_max_base_msat: maximum base routing fee the seller can charge during the lease
• channel_fee_max_proportional_thousandths: maximum proportional routing fee cap during the lease
• compact_lease: a compact encoding of the above five fields for gossip efficiency

A concrete example: leasing 1,000,000 sats of inbound capacity at 50 basis points with a 500 sat base fee costs approximately 5,500 sats plus on-chain transaction fees. The default lease duration is 4,032 blocks (roughly 28 days), during which the seller's funds are locked via CLTV timelocks preventing early unilateral closure.

Lease Enforcement

The critical question with liquidity ads is enforcement: what stops a seller from immediately closing the channel and recovering their funds? The specification uses timelocks to prevent this. The seller's outputs on commitment transactions are encumbered with CLTV locks matching the lease duration. Even in a force-close scenario, the seller's funds remain locked until the lease expires.

ACINQ's Eclair team identified and mitigated a griefing vector in January 2025 (Eclair #2982) where a buyer could lock up a seller's capital without ever routing payments through the channel. This highlights a recurring theme with liquidity ads: the specification is still evolving, and edge cases continue to surface.

Implementation Support Across Lightning

Not all Lightning implementations support dual-funded channels and liquidity ads equally. As of mid-2026, the landscape is fragmented:

Fragmentation matters: Because LND is the most widely deployed Lightning implementation and does not support dual-funded channels or liquidity ads, the addressable market for these features is limited to CLN and Eclair nodes. This fragmentation is one reason liquidity ads see low adoption in practice.

Comparing Approaches to Inbound Liquidity

Dual-funded channels and liquidity ads are far from the only way to acquire inbound capacity. The Lightning ecosystem has produced multiple competing approaches, each with different trust assumptions, costs, and implementation requirements. Understanding when each approach makes sense requires comparing them across several dimensions.

Lightning Service Providers

Lightning Service Providers (LSPs) abstract away liquidity management entirely. Phoenix (ACINQ) maintains a single dynamic channel per user that resizes via splicing, charging 1% of the inbound amount (minimum 3,000 sats) plus mining fees. Breez charges roughly 0.1-0.25% on received payments. The LSPS specification (bLIP-50, bLIP-51, bLIP-52), finalized in 2025, standardizes LSP communication, channel ordering, and JIT channel negotiation across implementations.

Submarine Swaps

Submarine swaps (Loop) allow nodes to shift capacity between on-chain and off-chain without closing channels. Loop Out sends off-chain sats to an on-chain address, freeing up inbound capacity. Loop In moves on-chain funds into a channel. Both operations use HTLCs that span both layers for atomic execution. These are most useful for rebalancing existing channels rather than creating new inbound capacity from scratch.

Marketplace Platforms

Magma (by Amboss) has emerged as the most active peer-to-peer liquidity marketplace. Node operators list channel offers with specified capacity, price, and duration. It works with any Lightning implementation (unlike liquidity ads, which require dual-funding support) and uses HODL invoice enforcement. Lightning Pool (Lightning Labs) uses a non-custodial batch auction model with uniform clearing prices, but its activity has declined significantly from its 2021-2022 peak.

Cost Comparison

The following table compares the approximate cost of acquiring 1,000,000 sats of inbound liquidity across different approaches:

When Do Liquidity Ads Make Economic Sense?

Liquidity ads occupy a specific niche. They are the most protocol-native solution: no external marketplace, no third-party service, just two peers negotiating directly through gossip and the interactive-tx protocol. The CLTV enforcement gives buyers stronger guarantees than marketplace platforms that rely on reputation or HODL invoices.

However, liquidity ads face a fundamental adoption challenge. With U.S. Treasury yields around 4.3% in mid-2026, liquidity providers need to earn at least that return to justify locking capital in a Lightning channel rather than a risk-free instrument. Smaller channels (under 1,000,000 sats) often carry implicit APRs exceeding 4% due to fixed costs, while larger channels (above 1 BTC) tend to clear at roughly 2.6% APR on marketplaces like Magma.

The Fulfillment Problem

The biggest practical limitation of liquidity ads is not cost but reliability. As documented in multiple analyses of the Lightning liquidity marketplace, liquidity ads suffer from extremely low fulfillment rates. A node may advertise willingness to fund channels, but when a buyer actually tries to open a dual-funded channel, the offer frequently goes unfilled. This stands in contrast to Magma, which has more active market-making and reliable order execution.

The reasons are partly technical (few nodes run compatible implementations) and partly economic (passive advertising does not create the same urgency as an active marketplace with price discovery). Until LND adds dual-funding support, liquidity ads will remain constrained to a fraction of the Lightning network.

Liquidity Ads vs. LSPs

For consumer-facing wallets, LSPs are almost always the right choice over liquidity ads. LSPs handle channel management automatically, provide instant onboarding via JIT channels, and abstract away the complexity of liquidity management. Phoenix's 1% fee is higher than liquidity ad rates, but it buys reliability and zero user configuration.

Liquidity ads make more sense for routing node operators running CLN or Eclair who want protocol-enforced guarantees and are comfortable with the manual process of finding and accepting offers. These operators are optimizing for cost per unit of capacity rather than convenience.

Splicing: The Complementary Innovation

Channel splicing deserves mention alongside dual-funded channels because both features share the same interactive-tx protocol. Splicing lets nodes resize existing channels without closing them: splice-in adds funds, splice-out removes funds to an on-chain output. The channel remains operational during the confirmation period.

CLN enabled splicing by default in its v26.04 release (April 2026), and Eclair has production-ready support. Combined with dual funding, splicing creates a world where channels are no longer fixed-size commitments. A node can open a dual-funded channel at one size, then splice in more capacity as demand grows, all without ever closing the channel.

The Broader Liquidity Problem

Dual-funded channels and liquidity ads represent incremental improvements to a fundamental architectural challenge. The Lightning Network's channel-based design inherently requires active liquidity management: nodes must lock capital in specific channels, balance capacity across their channel graph, and continuously monitor and rebalance as payment flows shift.

This is not a problem that can be fully solved within the channel paradigm. Every approach covered in this article (dual funding, liquidity ads, LSPs, submarine swaps, marketplace platforms) is a mitigation strategy for the underlying constraint: channels require pre-committed capital on both sides.

Some Bitcoin Layer 2 architectures avoid this constraint entirely. Spark, for example, uses a statechain-based design that eliminates channels altogether. Users transfer ownership of Bitcoin UTXOs off-chain without needing to pre-fund bilateral channels or manage inbound and outbound capacity. There is no concept of inbound liquidity on Spark because there are no channels to balance. For developers building wallets or payment applications, this means users can receive their first payment instantly without any liquidity bootstrapping step.

What Comes Next for Dual Funding

Several developments are shaping the future of dual-funded channels and liquidity ads:

• Eclair merged dual funding and splicing combined with simple taproot channels in August 2025, pointing toward a future where all three features work together natively
• LDK is working toward full dual-funding support in its v0.2.0 release, which would bring the feature to the growing number of wallets and services built on the LDK framework
• The LSPS specifications (bLIP-50/51/52) create a standardized interface for LSPs that can incorporate dual-funded and spliced channels under the hood, potentially bringing protocol-native liquidity acquisition to consumer wallets
• LND's continued absence from the dual-funding ecosystem remains the single largest barrier to adoption, given its large share of network nodes

The trajectory is clear: Lightning's liquidity tools are improving, but the complexity tax remains. Node operators in 2026 have more options for acquiring inbound capacity than ever before, yet each option requires understanding tradeoffs between cost, reliability, trust assumptions, and implementation compatibility.

For developers evaluating how to build on Bitcoin's Layer 2 ecosystem, the choice increasingly comes down to whether the application can absorb the operational complexity of channel management and routing or whether a channel-free architecture is a better fit. Explore the Spark SDK documentation to see how statechain-based transfers work in practice, or read the Spark vs. Lightning comparison for a deeper tradeoff analysis.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.