Outbound Liquidity

What Is Outbound Liquidity?

Outbound liquidity is the total amount of bitcoin a Lightning Network node can send through its payment channels at any given moment. Every Lightning channel has a fixed capacity set by the funding transaction, and that capacity is divided between two sides: the local balance (your outbound liquidity) and the remote balance (your inbound liquidity). When you send a payment, your outbound decreases and your inbound increases by the same amount.

Think of a Lightning channel as a tube with a fixed number of marbles inside. Your outbound liquidity is the marbles on your side: you can push them toward your channel partner, but you cannot send more marbles than you have. When marbles move to the other side, they become your inbound capacity, allowing you to receive.

For a deeper look at how Lightning handles payment flow and capacity constraints, see the Lightning Network liquidity explainer.

How It Works

A Lightning channel is funded by a 2-of-2 multisig Bitcoin transaction. The total sats locked in that transaction become the channel capacity, and every sat must belong to one side or the other at all times. The fundamental invariant is:

outbound_liquidity + inbound_liquidity = channel_capacity

# Example: Alice opens a 1,000,000 sat channel to Bob
Alice outbound: 1,000,000 sats
Alice inbound:          0 sats
Channel capacity: 1,000,000 sats

# Alice sends 300,000 sats to Bob
Alice outbound:   700,000 sats
Alice inbound:    300,000 sats
Channel capacity: 1,000,000 sats  # unchanged

When Alice opens the channel and funds it entirely, she starts with 100% outbound and 0% inbound. She can send up to the full channel capacity (minus the channel reserve) but cannot receive anything until she sends some sats to the other side.

Channel Reserve Constraints

Each participant in a Lightning channel must maintain a reserve of approximately 1% of the channel capacity. This reserve exists to ensure both parties have "skin in the game" against broadcasting revoked commitment transactions. In practice, roughly 2% of total channel capacity is always unspendable across both sides.

For a 1,000,000 sat channel, each side holds about 10,000 sats in reserve, leaving 980,000 sats available as actual spendable capacity. On small channels, this reserve becomes a more significant fraction of total capacity.

Multi-Channel Aggregation

A node's total outbound liquidity is the sum of local balances across all its channels. However, a single payment cannot exceed the largest individual channel's outbound capacity unless the sender uses multi-path payments (MPP) to split the payment across multiple channels. MPP dramatically improves payment success rates for larger amounts by leveraging outbound capacity distributed across several channels simultaneously.

Why Outbound Liquidity Matters

Different participants on the Lightning Network have different outbound liquidity needs:

For Payment Senders

Outbound liquidity is the primary concern for anyone making payments. If a consumer's channels are depleted (all capacity has shifted to the remote side), they cannot send any more payments until they either receive funds, open new channels, or use a service like Loop In to replenish their local balance. Without sufficient outbound capacity, payments simply fail.

For Routing Nodes

Routing nodes face the greatest complexity because they must maintain both outbound and inbound liquidity simultaneously across many channels. A payment enters via one channel (consuming inbound on that channel) and exits via another (consuming outbound). If either side is depleted on the relevant channel, the node cannot route in that direction.

Routing nodes earn forwarding fees as compensation for locking capital in balanced channels. The economic challenge: the fees earned must exceed the costs of rebalancing, on-chain transaction fees for channel management, and the opportunity cost of locked capital.

For Merchants

Merchants primarily need inbound liquidity to receive customer payments. However, as they accumulate received payments, their outbound naturally grows. Merchants also need some outbound capacity for operational expenses like paying suppliers. The self-balancing effect of regular two-way payment flows can reduce active liquidity management needs.

Managing Outbound Liquidity

Lightning node operators have several tools for managing outbound capacity. For a comprehensive walkthrough, see the Lightning channel management guide.

Opening New Channels

The most direct way to acquire outbound liquidity: open a new channel and fund it with on-chain bitcoin. All funded sats become your outbound capacity. With dual-funded channels, both parties contribute funds at open, so each side starts with some outbound and inbound capacity.

# Open a channel with 2,000,000 sats of outbound capacity
lncli openchannel --node_key=<peer_pubkey> --local_amt=2000000

# Dual-funded channel (both parties contribute)
# Each side starts with outbound capacity equal to their contribution

Loop In and Loop Out

Lightning Loop provides submarine swap services for converting between on-chain and off-chain bitcoin:

• Loop In converts on-chain bitcoin into Lightning channel balance, replenishing outbound capacity
• Loop Out converts Lightning balance into on-chain bitcoin, creating inbound capacity (useful when you have excess outbound)

For details on how submarine swaps work and when to use each direction, see the Loop and submarine swaps guide.

Splicing

Splicing allows adding or removing funds from an existing channel without closing it. A splice-in adds on-chain funds to increase both capacity and outbound liquidity. A splice-out removes funds to an on-chain output, decreasing total capacity. Splicing avoids the downtime and on-chain fees associated with closing and reopening channels.

Circular Rebalancing

Circular rebalancing routes a payment from your node back to itself through different channels. If Channel A has high outbound and Channel B has low outbound, sending from A through the network and receiving into B evens out the balances. The cost of rebalancing must be lower than the routing fees the rebalanced channel will earn.

Liquidity Marketplaces

Several marketplaces let node operators buy and sell channel capacity: Liquidity Ads (built into the BOLT spec for Core Lightning), Lightning Pool (non-custodial batch auctions from Lightning Labs), and Magma (peer-to-peer marketplace from Amboss). These services allow nodes to price and trade liquidity as a commodity.

Outbound Liquidity vs. Spark

The entire concept of outbound liquidity exists because Lightning locks funds inside payment channels. Every sat must sit on one side of a specific channel, creating a fragmented landscape where your total balance and your spendable capacity are two different numbers.

Spark takes a fundamentally different approach. Instead of payment channels, Spark uses virtual UTXOs (vUTXOs) built on statechains. There are no channels to fund, no local vs. remote balances to manage, and no liquidity to rebalance. A user's entire Spark balance is fully spendable at all times, similar to how an on-chain UTXO works but without the on-chain fees or confirmation delays.

This eliminates several categories of operational overhead:

For a detailed comparison of these two architectures, see the Lightning vs. Spark glossary entry.

Use Cases

• Retail payments: consumers need enough outbound liquidity to cover everyday purchases over Lightning. Running out of outbound means topping up via Loop In or opening a new channel.
• Payment routing: professional routing nodes allocate capital across dozens or hundreds of channels, continuously rebalancing outbound capacity toward high-traffic corridors to maximize fee revenue.
• Exchange withdrawals: when users withdraw bitcoin from an exchange over Lightning, the exchange node needs sufficient outbound liquidity on its channels. High withdrawal volumes can deplete outbound quickly, requiring automated management via AutoLoop or similar tools.
• Lightning Service Providers: LSPs manage outbound liquidity on behalf of end users, handling channel opens, just-in-time channels, and automated rebalancing so wallet users never interact with liquidity constraints directly.

Risks and Considerations

Channel Depletion

Channels naturally become lopsided as payments flow in one direction. A channel that started at a 50/50 balance might drift to 90/10 after days of one-directional traffic. When outbound runs out on a channel, no more payments can be sent through it until balance shifts back.

Rebalancing Costs

Every rebalancing operation has a cost: on-chain fees for channel opens and splices, service fees for Loop operations, and routing fees for circular rebalancing. For routing nodes, the fundamental economic question is whether rebalancing costs remain lower than the forwarding fees earned. Poorly managed rebalancing can turn a profitable routing node into a loss-making one.

Capital Inefficiency

Outbound liquidity is locked capital. Sats committed to Lightning channels cannot be used for anything else until the channel is closed or funds are spliced out. Routing nodes must deploy enough capital to handle expected payment volumes while earning fees that justify the opportunity cost. This creates a tension between capital efficiency and routing reliability.

New Node Bootstrapping

A new node that opens channels has all outbound and zero inbound: it can send but cannot receive. Building balanced liquidity from scratch requires a combination of spending (which converts outbound to inbound), Loop Out operations, convincing peers to open channels toward you, or purchasing inbound via liquidity marketplaces. This bootstrapping challenge is one of the most common friction points for new Lightning participants.

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.