Liquidity Lease

What Is a Liquidity Lease?

A liquidity lease is an agreement where a Lightning Network node operator (the lessor) opens a payment channel with a specified capacity toward another node (the lessee) for a fixed duration, in exchange for a fee. The lessee gains guaranteed inbound liquidity: the ability to receive payments up to the leased amount without needing to find cooperative peers or lock up their own bitcoin on the remote side of a channel.

The concept emerged because Lightning channels are asymmetric by default. When a node opens a channel, all the capacity starts on the opener's side (outbound). To receive payments, a node needs someone else to open a channel toward it or to push funds outward first. For merchants, routing nodes, and new entrants to the network, acquiring inbound liquidity has historically been one of the biggest operational hurdles. Liquidity leases turn this problem into a marketplace where capacity is bought and sold like any other resource.

How It Works

A liquidity lease follows a straightforward lifecycle, though the specifics vary by marketplace:

1. The lessee (buyer) determines how much inbound capacity they need and for how long
2. A lessor (seller) agrees to provide that capacity, either through an auction, a posted offer, or a protocol-level advertisement
3. The lessee pays the lease fee (upfront, deducted from the channel, or via a separate payment)
4. The lessor opens a Lightning channel with the agreed-upon capacity toward the lessee
5. The channel remains open for the lease duration, during which the lessee can receive payments up to the channel's capacity
6. After the lease expires, the lessor is free to close the channel and redeploy capital

Duration Enforcement

A critical challenge with liquidity leases is preventing the lessor from collecting the fee and immediately closing the channel. Different systems handle this differently:

• Lightning Pool uses Bitcoin Script enforcement: the lessor's funds are locked with a timelock set to the lease maturity block height, preventing early withdrawal
• Magma relies on reputation tracking: Amboss monitors channel behavior and penalizes sellers who close early or violate promised routing fee caps
• Liquidity ads enforce duration via CSV (CheckSequenceVerify) timelocks on the lessee's outputs, currently fixed at 4,032 blocks (approximately 28 days)

Pricing Factors

Lease pricing is driven by several factors that determine the cost per satoshi of capacity:

Market rates for liquidity leases have generally ranged between 1% and 4% APR, with the market converging around 2.5% for standard-sized channels as of 2026.

Marketplace Implementations

Lightning Pool

Lightning Pool, built by Lightning Labs, is a non-custodial auction marketplace for channel leases. It uses sealed-bid, uniform clearing-price, batched auctions that run approximately every 10 minutes. Sellers submit asks and buyers submit bids; matched orders in each batch pay the same per-block rate. Multiple channel openings are bundled into a single on-chain transaction to reduce fees.

Pool introduced script-enforced leases in December 2021, preventing lessors from closing channels before the agreed maturity block height. Available lease durations include 2-week, 4-week, 12-week, and 1-year buckets.

# Lightning Pool: submit a bid for inbound liquidity
pool orders submit bid \
  --amt 5000000 \
  --interest_rate_percent 2.5 \
  --lease_duration_blocks 8064 \
  --acct_key <account_key>

# Submit an ask to lease out capacity
pool orders submit ask \
  --amt 10000000 \
  --interest_rate_percent 3.0 \
  --lease_duration_blocks 8064 \
  --acct_key <account_key>

As of mid-2026, Lightning Pool remains functional but sees limited activity as Lightning Labs has shifted focus toward Taproot Assets.

Magma by Amboss

Magma is a peer-to-peer marketplace operated by Amboss that supports all major Lightning implementations: LND, Core Lightning, and Eclair. Rather than auctions, Magma uses a posted-offer model where sellers list their capacity with custom pricing.

Magma uses a hodl invoice mechanism for trustless execution: the buyer's payment is held in an HTLC until the seller opens the channel and it receives three on-chain confirmations. If the seller fails to deliver, the hodl invoice is cancelled and the buyer recovers funds automatically. Amboss charges a flat 500 PPM platform fee on every order.

Liquidity Ads (Protocol-Level)

Liquidity ads represent the most decentralized approach to liquidity leasing. Defined in BOLTs PR #878, they allow nodes to advertise willingness to fund channels via the Lightning gossip protocol without any central marketplace. When a peer wants to open a channel, it can request that the advertising node contribute funds through a dual-funded channel open.

Core Lightning and Eclair both implement liquidity ads. Phoenix wallet adopted this approach in late 2024, moving from a proprietary LSP protocol to an open standard based on dual funding, splicing, and liquidity ads.

Liquidity Leases vs. Alternatives

Liquidity leases are one of several approaches to solving the inbound liquidity problem on Lightning. Each involves different tradeoffs:

For a deeper comparison of these approaches, see the research article on Lightning liquidity marketplace analysis.

Use Cases

Merchant Onboarding

A merchant accepting Lightning payments needs inbound liquidity from day one. Without it, customers cannot route payments to the merchant's node. Liquidity leases let merchants purchase predictable receiving capacity for a known cost, similar to renting bandwidth from an ISP.

Routing Node Operators

Routing nodes earn routing fees by forwarding payments through their channels. Leasing liquidity to well-connected peers helps a routing node position itself in high-traffic payment paths, increasing fee revenue. The lease fee functions as a cost of capital that routing income must exceed to be profitable.

Yield on Bitcoin Holdings

For node operators with idle bitcoin, leasing out channel capacity generates yield without surrendering custody. The lessor's bitcoin remains in a multisig channel on-chain, and they continue to earn routing fees on payments that traverse the channel during the lease period.

Risks and Considerations

Capital Inefficiency

Liquidity leases lock bitcoin into specific channels for fixed periods. If payment patterns shift or the lessee's node goes offline, the leased capacity sits idle while the lessor's capital remains frozen. Unlike traditional lending, the lessor cannot recall funds early when script-enforced timelocks are in place.

Pricing Uncertainty

The value of a liquidity lease depends on future payment volumes that are impossible to predict accurately. A merchant who leases 5 million sats of inbound capacity but only receives 500,000 sats in payments during the lease period has overpaid significantly. Conversely, demand spikes may exhaust leased capacity before the term ends.

Counterparty Behavior

Even with enforcement mechanisms, counterparty risk remains. Lessors may force-close channels during periods of high on-chain fees, effectively passing costs to the lessee. Lessees may route large payments that deplete channel balance, leaving the channel one-sided and reducing the lessor's routing fee income.

On-Chain Fee Exposure

Every liquidity lease requires at least one on-chain transaction to open the channel and another to close it. During fee spikes, these costs can exceed the value of the lease itself, particularly for small channels. The fee market introduces unpredictable costs that erode both parties' expected returns.

How Spark Eliminates the Need for Liquidity Leases

The entire concept of liquidity leasing exists because Lightning's channel-based architecture requires pre-committed capital on specific routes. Spark takes a fundamentally different approach: instead of routing payments through a network of bilateral channels, Spark uses a statechain-based architecture where virtual UTXOs are transferred directly between participants.

Because Spark does not rely on payment channels, there is no concept of inbound or outbound capacity to manage. Users can receive any amount up to their balance without pre-arranging liquidity, and operators do not need to lock capital in bilateral channels. This eliminates the liquidity management overhead: no lease fees, no channel rebalancing, and no capacity planning. For developers building on Bitcoin, this means one fewer operational concern to manage.

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.