Capacity Planning (Lightning)

What Is Capacity Planning?

Capacity planning on the Lightning Network is the process of strategically allocating Bitcoin across payment channels to maximize routing success rates, earn routing fees, and maintain reliable payment forwarding. It encompasses three core decisions: which peers to connect with, how much capital to commit to each channel, and how to keep liquidity balanced as payments flow through the node.

For routing nodes, capacity planning is the most important operational task. A node with poorly allocated capital will fail to route payments (earning nothing) or route them at a loss after rebalancing costs. Think of it as managing inventory for a logistics company: you need the right amount of stock at the right locations, and demand constantly shifts.

Unlike traditional network capacity planning (provisioning bandwidth or compute), Lightning capacity planning is about financial capital. Every satoshi locked in a channel is capital that cannot be used elsewhere. This creates a direct trade-off between routing capability and opportunity cost.

How It Works

Capacity planning breaks down into three interdependent activities: peer selection, channel sizing, and liquidity management.

Peer Selection

Choosing the right channel partners is the foundation of capacity planning. A well-connected node routes more payments, earns more fees, and requires less rebalancing. Key factors in peer selection include:

• Centrality: connecting to well-connected nodes places your node on more potential payment paths. Nodes with high betweenness centrality in the network graph see more routing traffic.
• Volume endpoints: channels to exchanges, payment processors, and popular merchants see natural two-way flow, reducing rebalancing needs.
• Complementary connectivity: opening channels to peers in different network regions (geographic or topological) increases the diversity of routes through your node.
• Reliability: peers with high uptime and responsive channel management reduce the risk of force closures and stuck payments.

Network analysis tools like Amboss, LNRouter, and 1ML provide centrality metrics, uptime scores, and channel data that help operators identify high-value peers. The gossip protocol broadcasts public channel information across the network, but choosing peers well requires analyzing patterns beyond what gossip alone reveals.

Channel Sizing

Once peers are selected, operators must decide how much capital to commit per channel. Channel size directly affects what the node can route:

• Minimum effective size: channels below approximately 500,000 sats (0.005 BTC) struggle to route meaningful payments, especially after accounting for the channel reserve (typically 1% of capacity) that each side must hold back.
• Standard channels: the original Lightning protocol capped channels at 16,777,215 sats (approximately 0.168 BTC). This limit was intended to reduce risk during the network's early growth.
• Wumbo channels: nodes that signal wumbo support can open channels without the size cap. Large routing nodes regularly open channels of 5,000,000 to 50,000,000+ sats to handle higher-value payments and reduce per-channel overhead.

The sizing decision involves a trade-off: larger channels route bigger payments and need less frequent rebalancing relative to their throughput, but they also tie up more capital with a single peer. If that peer goes offline or the channel sees little traffic, the capital is wasted.

Inbound vs. Outbound Liquidity

Every channel has two sides: outbound liquidity (what you can send) and inbound liquidity (what you can receive). For routing, both sides matter. A routing node needs outbound liquidity toward destinations where payments flow, and inbound liquidity from sources where payments originate.

When a node opens a channel, all the capacity starts on the opener's side as outbound liquidity. Getting inbound liquidity requires one of several approaches:

• Having peers open channels to you (acquired through reputation or by being a useful routing partner)
• Purchasing inbound via liquidity ads, a protocol-level marketplace where nodes offer to open channels for a fee
• Using dual-funded channels where both parties contribute capital at open time
• Moving existing outbound to inbound through circular rebalancing or Loop Out swaps

A common target is a 50/50 balance across the node's total capacity, though in practice the optimal ratio depends on traffic patterns. Channels to payment senders should lean toward inbound, while channels to payment receivers should lean toward outbound.

Capacity Planning Tools

Manual capacity planning does not scale beyond a handful of channels. The Lightning ecosystem has developed several tools for monitoring, analysis, and automated management:

Automated Rebalancing Example

Balance of Satoshis automates circular rebalancing with configurable constraints:

# Rebalance 500,000 sats from a high-outbound channel
# to a low-outbound channel, with a max fee of 50 ppm
bos rebalance \
  --in <peer_alias_needing_outbound> \
  --out <peer_alias_with_excess_outbound> \
  --amount 500000 \
  --max-fee-rate 50

# Automate with a cron job for continuous balancing
# Run every 30 minutes, targeting 50% outbound ratio
*/30 * * * * bos rebalance --amount 200000 --max-fee-rate 100

Strategies for Routing Node Profitability

Profitable capacity planning goes beyond opening channels and waiting for fees. Successful operators follow structured strategies:

Triangle Strategy

Open channels to three or more nodes that transact heavily with each other. If exchange A frequently sends to merchant B, and merchant B pays supplier C, positioning your node with channels to all three creates natural circular flow. This reduces the need for paid rebalancing because payments in one direction are offset by payments in the other.

Fee-Based Flow Management

Rather than rebalancing with circular payments (which cost routing fees), experienced operators use fee adjustments to steer traffic. Tools like charge-lnd automate this process:

• When outbound liquidity in a channel drops below 25%, raise fees on that channel to discourage further outbound flow
• When outbound liquidity exceeds 75%, lower fees to attract traffic that will rebalance the channel naturally
• Set inbound fee discounts (negative inbound fees, supported since LND 0.18) to incentivize payments flowing in the desired direction

This approach turns fee policy into a passive rebalancing mechanism, reducing the direct cost of circular payments.

Capital Efficiency Metrics

Operators track several metrics to evaluate whether their capital is well-deployed:

# Key capacity planning metrics
Routing yield = (fees earned - rebalancing costs) / total capacity
Channel utilization = volume routed / channel capacity
Flow ratio = inbound volume / outbound volume per channel
PPM earned (net) = (gross fee income - rebalance spend) / volume routed × 1,000,000

A channel with high capacity but near-zero utilization is dead capital. A channel with high utilization but negative net PPM after rebalancing is destroying value. Both indicate capacity planning failures that need correction through fee adjustment, rebalancing, or channel closure.

Why Capacity Planning Is Hard

Several structural features of Lightning make capacity planning inherently difficult:

• Incomplete information: nodes only know their own channel balances. Remote channel balances across the network are invisible, making it impossible to predict routing success with certainty. Payment probes help estimate remote balances but add latency and can be unreliable.
• Dynamic traffic patterns: payment flows shift with market activity, business cycles, and network topology changes. A well-planned capacity allocation today may be obsolete next week.
• On-chain costs: opening and closing channels requires on-chain transactions with mining fees. During high-fee environments, adjusting channel allocations becomes expensive, creating inertia that prevents optimal positioning.
• Rebalancing costs can exceed routing revenue. A common failure mode is spending more on circular rebalances than the node earns in fees, resulting in net losses despite high routing volume.

For a deeper analysis of these challenges, see the research article on Lightning Network routing.

How Spark Eliminates Capacity Planning

Spark takes a fundamentally different approach to off-chain Bitcoin payments. Instead of payment channels with fixed capacity between two parties, Spark uses virtual UTXOs (vTXOs) and statechains to represent ownership off-chain.

This architecture means:

• No channels to open, size, or close: users hold vTXOs directly without locking funds in bilateral channels
• No inbound/outbound liquidity distinction: receiving a payment does not require pre-positioned inbound capacity from a specific peer
• No rebalancing: there are no channel balances to shift, so the entire category of rebalancing costs disappears
• No routing: payments transfer ownership of vTXOs directly rather than hopping through intermediary channels, so there is no pathfinding, no failed routes, and no routing fees

For users and businesses, this means they can focus on building applications rather than managing network infrastructure. The operational burden of capacity planning, which can consume hours of daily attention for routing node operators, simply does not exist on Spark.

Risks and Considerations

Capital Lock-up Risk

Poor capacity planning locks Bitcoin in unproductive channels. Unlike a bank that can recall a loan, a Lightning operator cannot easily recover funds from a channel without closing it, which incurs on-chain fees and may take hours to confirm. During periods of high on-chain fees, the cost of closing and reopening channels can exceed months of routing revenue.

Centralization Pressure

The complexity of capacity planning favors large, well-capitalized operators. Nodes with more capital can open larger channels, absorb rebalancing costs, and maintain balanced liquidity more easily. This creates centralization pressure where a small number of nodes route the majority of payments, potentially undermining the network's censorship resistance.

Opportunity Cost

Capital allocated to Lightning channels cannot simultaneously be used for other purposes: on-chain transactions, DeFi lending, or simply holding as a store of value. Routing node operators must weigh their expected routing yield against alternative uses of their Bitcoin, particularly as Bitcoin staking and BTCFi protocols offer competing yields.

Automation Risks

Automated rebalancing tools can drain a node's funds if misconfigured. A rebalancing bot set with overly generous fee limits can spend significant sats on circular payments that never generate return traffic. Operators should set strict maximum fee rates and monitor automated tool activity closely.

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.