Inbound Liquidity

What Is Inbound Liquidity?

Inbound liquidity refers to the total amount of Bitcoin that can be sent to you across all your open Lightning channels. Each channel has a fixed capacity split between your local balance (what you can send) and the remote balance (what your counterparty can send to you). The remote balance across all your channels is your inbound liquidity.

Think of a Lightning channel as a tube with a fixed amount of water inside. If all the water sits on your end, you can push it to the other side (send payments), but nothing can flow back to you. To receive payments, the water needs to be on the other end first. Inbound liquidity is the water sitting on your counterparty's side, ready to flow your way.

This asymmetry is a fundamental property of Lightning's bidirectional payment channels. Unlike on-chain Bitcoin, where anyone can send to your address without preconditions, Lightning requires pre-positioned liquidity on the sender's side of each hop. For the final recipient, that means having sufficient remote balance in at least one channel.

How It Works

Inbound liquidity is governed by the mechanics of Lightning channels. When two nodes open a channel, the node that funds it commits Bitcoin to an on-chain multisig output. Initially, the entire channel balance belongs to the funder:

Channel opened by Alice (1,000,000 sats capacity):

  Alice (local)          Bob (remote)
  ┌──────────────────────┬──────────────────────┐
  │    1,000,000 sats    │       0 sats         │
  └──────────────────────┴──────────────────────┘

  Alice's outbound liquidity: 1,000,000 sats
  Alice's inbound liquidity:  0 sats
  Bob's outbound liquidity:   0 sats
  Bob's inbound liquidity:    1,000,000 sats

From Alice's perspective, she has 1,000,000 sats of outbound liquidity but zero inbound liquidity. She can send but not receive. When Alice sends 300,000 sats to Bob (or routes a payment through Bob), the balances shift:

After Alice sends 300,000 sats:

  Alice (local)          Bob (remote)
  ┌──────────────────────┬──────────────────────┐
  │     700,000 sats     │    300,000 sats      │
  └──────────────────────┴──────────────────────┘

  Alice's inbound liquidity: 300,000 sats
  Bob's inbound liquidity:   700,000 sats

Now Alice can receive up to 300,000 sats. Every outgoing payment she makes increases her inbound liquidity by the same amount. Note that the channel reserve slightly reduces the usable amounts on each side, ensuring both parties always have some skin in the game to discourage cheating.

Multi-Channel Inbound Liquidity

A node's total inbound liquidity is the sum of remote balances across all its channels. With multi-path payments, a node can receive a single payment split across multiple channels, making use of fragmented inbound liquidity that no single channel could handle alone:

Node with three channels:

  Channel 1: 200,000 sats inbound
  Channel 2: 150,000 sats inbound
  Channel 3:  50,000 sats inbound
  ─────────────────────────────────
  Total inbound: 400,000 sats

  Without MPP: max receivable = 200,000 sats (largest single channel)
  With MPP:    max receivable = 400,000 sats (combined across channels)

However, the sender must also support MPP and find routes to each of the receiver's channels. In practice, total receivable capacity may be lower than the arithmetic sum due to routing constraints.

The Inbound Liquidity Problem

The "inbound liquidity problem" is the bootstrapping challenge every new Lightning node faces. When you first set up a node and open channels, you fund those channels yourself. All your liquidity is outbound. You can send payments but cannot receive any.

For merchants, this is especially problematic. A store that wants to accept Lightning payments needs inbound liquidity before its first customer can pay. But acquiring inbound liquidity requires either spending Bitcoin first (which the merchant may not want to do) or convincing other nodes to open channels to you (which requires reputation or payment).

This chicken-and-egg problem is one of the most discussed usability challenges in Lightning. For a deeper look at how liquidity flows through the network, see Lightning Network Liquidity Explained.

Acquiring Inbound Liquidity

Several methods exist for acquiring inbound liquidity, each with different tradeoffs:

Spend Outbound First

The simplest method: open a channel and spend from it. Every sat you send moves to the remote side, becoming inbound liquidity. If you regularly buy goods or services over Lightning, your inbound capacity grows naturally over time.

Limitation: you need to actually spend Bitcoin, which is not viable if you primarily want to receive payments (as a merchant, for example).

Request Inbound Channels

Ask other node operators to open channels to you. When someone else funds a channel to your node, the entire balance starts on their side, giving you immediate inbound liquidity. Well-connected nodes with good uptime are more likely to attract inbound channels organically.

Limitation: relies on the goodwill or commercial interest of other operators. No guarantee of channel size or reliability.

Buy Liquidity

Liquidity marketplaces allow you to pay for inbound channels. Platforms like Magma and Pool let you purchase channels of specific sizes from liquidity providers. You pay a fee, and the provider opens a channel to your node with the agreed capacity.

The Lightning specification also includes a liquidity ads protocol that lets nodes advertise their willingness to provide inbound liquidity at published rates, making the process more standardized.

Loop Out

Loop Out sends funds from a Lightning channel to an on-chain address. The Lightning side of the transaction moves sats to the remote side of your channel (creating inbound liquidity), while you receive the equivalent amount on-chain. The net effect: you convert outbound liquidity to inbound liquidity while keeping the same total value.

Autoloop can automate this process, monitoring your channel balances and executing Loop Out operations when inbound liquidity drops below a threshold. This is particularly useful for routing nodes that need to maintain balanced channels.

Circular Rebalancing

Circular rebalancing sends a payment from your node back to yourself through the network. You pay out through one channel (increasing its inbound) and receive through another (decreasing its inbound). This redistributes liquidity across your channels without changing the total.

This is useful when you have plenty of inbound liquidity in one channel but need it in another. The cost is the routing fees paid to intermediate nodes along the circular route.

Dual-Funded Channels

The dual-funding protocol (interactive-tx) allows both parties to contribute funds when opening a channel. Instead of one node funding the entire channel, both commit an amount. This gives each side immediate outbound and inbound liquidity proportional to the other party's contribution.

LSPs and Mobile Wallets

Lightning Service Providers (LSPs) solve the inbound liquidity problem for mobile wallet users. When a user first installs a Lightning wallet, the LSP opens a channel to them, funded by the LSP. The user immediately has inbound liquidity and can receive payments without any channel management.

Many LSPs use zero-conf channels to make this instant: the channel is usable before the funding transaction confirms on-chain. The LSP takes on the risk of a double-spend during the confirmation window.

LSPs typically recover their costs through routing fees, channel lease fees, or by integrating with wallet services. This model has made Lightning accessible to non-technical users who never need to think about channel management or liquidity.

Layer 2 protocols like Spark take a different approach entirely: by eliminating the channel model, they remove the inbound liquidity constraint altogether. Users can receive Bitcoin instantly without needing pre-positioned liquidity.

Routing Node Profitability

For routing nodes, inbound liquidity is a revenue-generating asset. Routing nodes earn routing fees by forwarding payments, but they can only route payments toward themselves (and out the other side) if they have inbound liquidity on the incoming channel.

A routing node with 10 channels but all the balance on its local side cannot route any payments. It has outbound capacity but no inbound. Effective routing requires balanced channels: enough inbound to attract forwarding traffic and enough outbound to complete the route.

This is why professional routing node operators actively manage their inbound liquidity using Loop Out, circular rebalancing, autoloop, and liquidity marketplaces. The cost of acquiring inbound liquidity is a key variable in routing profitability calculations.

Risks and Considerations

Liquidity Is Not Free

Every method of acquiring inbound liquidity has a cost. Loop Out incurs on-chain fees and swap fees. Buying channels involves lease fees. Circular rebalancing pays routing fees. Even "free" inbound channels from peers consume capital that could be deployed elsewhere. Node operators must weigh these costs against the expected revenue or utility.

Liquidity Is Dynamic

Inbound liquidity changes with every payment. Receiving a payment reduces your inbound and increases your outbound. Sending does the opposite. Channel splices (via splicing) can resize channels, but the constant flux means liquidity management is an ongoing task, not a one-time setup.

Channel Counterparty Risk

Inbound liquidity only exists while the channel is open and the counterparty is online. If your counterparty force-closes the channel, your inbound liquidity disappears. Relying on a single large inbound channel creates a single point of failure. Diversifying across multiple counterparties is more resilient.

Privacy Tradeoffs

Public channels expose your node's capacity to the network. Other nodes can observe your channel sizes and, through probing, estimate your balance distribution. This reveals information about your inbound liquidity. Private channels and blinded paths help mitigate this, but add routing complexity.

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.