Channel Capacity

What Is Channel Capacity?

Channel capacity is the total amount of Bitcoin locked into a Lightning Network payment channel when it is opened. It represents the combined funds that both channel partners have committed to the channel's multisig funding transaction on the Bitcoin base layer. Once set, the capacity does not change unless the channel is closed and reopened, or modified through splicing.

Think of channel capacity like a tube containing a fixed number of marbles. The marbles can slide freely between the two ends (representing the two channel partners), but the total number of marbles in the tube never changes. If Alice and Bob open a channel with 1,000,000 satoshis of capacity, the sum of Alice's balance and Bob's balance will always equal 1,000,000 sats, minus a small amount reserved for channel reserves.

Channel capacity is a fundamental constraint of the Lightning Network because it determines how large a payment can flow through any given channel. Understanding capacity, and how it differs from available balance, is essential for anyone running a Lightning node or building applications on top of the network.

How It Works

A Lightning channel is created by broadcasting a funding transaction to the Bitcoin blockchain. This transaction locks Bitcoin into a 2-of-2 multisig output controlled by both channel partners. The amount locked in this output is the channel's capacity.

Channel Opening and Capacity

When a channel is opened, one or both parties contribute funds to the funding transaction. The initial balance distribution depends on who funded the channel:

• Single-funded channel: one party provides all the funds. They start with 100% of the balance on their side, while the counterparty starts with zero. This means the funder can send up to the full capacity (minus reserves), but the counterparty cannot send anything until payments flow in their direction.
• Dual-funded channel: both parties contribute funds. The initial balance reflects each party's contribution, allowing payments to flow in both directions immediately.

Capacity vs. Balance

This distinction is the most important concept to understand about channel capacity. Consider a channel between Alice and Bob with 500,000 sats of total capacity:

Channel: Alice <──────────────────> Bob
Capacity: 500,000 sats (fixed)

Initial state (Alice funded):
  Alice: 490,000 sats  |  Bob: 0 sats  |  Reserve: 10,000 sats

After Alice pays Bob 200,000 sats:
  Alice: 290,000 sats  |  Bob: 200,000 sats  |  Reserve: 10,000 sats

After Bob pays Alice 50,000 sats:
  Alice: 340,000 sats  |  Bob: 150,000 sats  |  Reserve: 10,000 sats

Capacity never changes: always 500,000 sats total

The capacity stays constant throughout the channel's lifetime. What changes is the balance distribution: how much each party can spend. Alice's local balance is her outbound liquidity (what she can send), while Bob's side of the channel is Alice's inbound liquidity (what she can receive).

Channel Reserves and Usable Capacity

Not all of the channel's capacity is available for payments. The Lightning protocol requires each party to maintain a channel reserve: a minimum balance that cannot be spent. This reserve (typically 1% of the channel capacity) ensures that both parties always have something at stake, creating an economic incentive against broadcasting old (revoked) channel states.

Channel capacity:    1,000,000 sats
Reserve per side:       10,000 sats (1%)

Maximum Alice can send:  capacity - (2 × reserve)
                       = 1,000,000 - 20,000
                       = 980,000 sats

(In practice, HTLC fees and dust limits further reduce the usable amount)

This means a channel's effective capacity for payments is always slightly less than its total capacity. The reserves exist to support the penalty mechanism that secures Lightning channels through justice transactions.

Capacity and Routing

When routing payments through the Lightning Network, every channel along the path must have sufficient balance on the correct side to forward the payment. A route is only viable if each hop has enough outbound liquidity. The channel with the lowest available balance along a route becomes the bottleneck, regardless of the other channels' capacities.

This is why public channel capacity is visible to the network (it's derived from the on-chain funding transaction), but balance distribution is private. Routing nodes can see that a channel exists with a given capacity, but they cannot know how that capacity is currently split between the two sides. This privacy property means that senders must probe or estimate balance distributions when constructing routes.

Overcoming Capacity Limits

Multi-Path Payments (MPP)

The most significant advancement for overcoming capacity constraints is multi-path payments. MPP allows a single payment to be split into smaller parts, each routed through different channels simultaneously. The receiver reassembles the parts using the same payment hash.

Payment: 800,000 sats

Without MPP:
  Requires a single route with 800,000+ sats capacity at every hop
  Often fails for large amounts

With MPP:
  Part 1: 300,000 sats → Route A
  Part 2: 250,000 sats → Route B
  Part 3: 250,000 sats → Route C
  Total received: 800,000 sats ✓

MPP dramatically increases the effective payment size the network can handle. Instead of being limited by the smallest channel in a single route, payments can leverage the aggregate capacity across many routes. For more on how liquidity flows through the network, see the Lightning Network liquidity deep dive.

Splicing

Splicing allows channel capacity to be modified without closing the channel. A splice-in adds funds from an on-chain transaction, increasing capacity. A splice-out removes funds to an on-chain address, decreasing capacity. During the splice, the channel remains open and operational: payments continue to flow while the new funding transaction confirms.

Channel Factories

Channel factories allow multiple channels to be created from a single on-chain transaction, reducing the cost of establishing capacity. This makes it more economical to open many smaller channels rather than concentrating funds in a few large ones, improving overall network liquidity distribution.

Use Cases

Merchant Payment Processing

Merchants receiving Lightning payments need sufficient inbound capacity on their channels. A merchant with 10 BTC of total channel capacity but all of it on their side (outbound) cannot receive any payments. Services like Loop help merchants acquire inbound liquidity by performing submarine swaps that shift balance to the remote side of their channels.

Routing Node Operation

Routing nodes earn routing fees by forwarding payments. To maximize routing opportunities, they need well-balanced channels with large capacity. A routing node operator might use circular rebalancing to shift funds between channels, ensuring balanced liquidity across their channel portfolio without changing total capacity.

Layer-2 Protocols

Protocols built on top of Lightning must account for capacity constraints in their design. Spark, for example, takes a different approach by using shared UTXO ownership rather than bilateral channels, eliminating per-channel capacity limits entirely. This allows users to send and receive any amount without worrying about individual channel sizing.

Risks and Considerations

Capital Inefficiency

Channel capacity requires locking Bitcoin on-chain for the lifetime of the channel. This capital cannot be used for anything else while the channel is open. For routing nodes, the return on locked capital (through routing fees) is often modest compared to the opportunity cost.

Opening a channel also requires an on-chain transaction with mining fees. If fees are high, opening small channels may be uneconomical: the on-chain cost could exceed the value that flows through the channel during its lifetime.

Capacity Planning Challenges

Choosing the right channel capacity is difficult. Open too small and the channel cannot handle typical payment sizes. Open too large and capital sits idle. Capacity cannot be adjusted after opening (without splicing support), so the decision is semi-permanent.

Zero-conf channels can speed up channel creation but do not solve the sizing problem. Operators still need to estimate future payment flows and size channels accordingly.

Liquidity Imbalance

Even with adequate capacity, channels become unusable when liquidity is heavily skewed to one side. A channel with 1 BTC capacity where 0.99 BTC sits on one side can effectively only route tiny payments in one direction. Rebalancing tools like autoloop help maintain balance, but they incur routing fees and are not always successful.

Network-Level Capacity Constraints

The Lightning Network's total capacity is the sum of all channel capacities across the network. While individual channels might be well-sized, the overall network topology affects payment success rates. Payments between poorly-connected nodes may fail even when sufficient aggregate capacity exists, simply because no viable route has enough balance at every hop.

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.