Channel Balance

What Is Channel Balance?

A channel balance is the current distribution of bitcoin between the two participants in a Lightning Network payment channel. Every channel has a fixed total capacity, set when the channel is opened, and this capacity is divided into two complementary balances: a local balance (funds on your side) and a remote balance (funds on your counterparty's side).

Think of it like a tube with a fixed number of marbles. You can push marbles to the other side by sending payments, or pull them back by receiving payments, but the total number of marbles never changes. Your local balance is the marbles on your end: the maximum amount you can send through this channel. Your remote balance is the marbles on the other end: the maximum amount you can receive.

This directional constraint is what makes Lightning fundamentally different from on-chain Bitcoin. On-chain, if you hold 1 BTC, you can spend up to 1 BTC and receive any amount. On Lightning, your ability to send and receive depends on how your funds are distributed across your channels.

How It Works

When two nodes open a Lightning channel, one or both contribute funds to a 2-of-2 multisig funding transaction on-chain. The amount locked in this transaction becomes the channel's capacity and cannot change without closing the channel or using splicing.

Local and Remote Balance

If Alice opens a channel with Bob by contributing 1,000,000 sats, the initial state is:

Channel: Alice <-> Bob
Capacity:      1,000,000 sats
Alice (local):  1,000,000 sats  (can send up to this amount)
Bob (remote):           0 sats  (Alice cannot receive)

At this point, Alice can send up to 1,000,000 sats through this channel, but she cannot receive anything because Bob has no funds on his side. After Alice sends 300,000 sats to Bob:

Channel: Alice <-> Bob
Capacity:      1,000,000 sats
Alice (local):   700,000 sats
Bob (remote):    300,000 sats  (Alice can now receive up to 300,000)

Every payment shifts funds from one side to the other. The balance is always complementary: your local balance is your peer's remote balance, and vice versa. This is tracked through commitment transactions that both parties maintain, each reflecting the current balance split with to_local and to_remote outputs.

Channel Reserve

Per the BOLT 2 specification, each party must maintain a minimum channel reserve: typically around 1% of the total channel capacity. This reserve cannot be spent, ensuring both parties always have funds at stake. If either party tries to broadcast a revoked commitment transaction (an old state), the counterparty can claim all channel funds through a justice transaction. Without a reserve, one party could drain their side to zero and cheat without consequence.

This means users can never spend 100% of their local balance. On a 1,000,000-sat channel with a 1% reserve, the maximum spendable amount is roughly 990,000 sats.

Dual-Funded Channels

In a standard channel opening, only one party contributes funds. A dual-funded channel allows both parties to contribute, creating a more balanced initial state. If Alice contributes 500,000 sats and Bob contributes 500,000 sats, both start with the ability to send and receive up to 500,000 sats through that channel.

Why It Matters

Channel balance is the single biggest UX challenge on the Lightning Network. Unlike on-chain Bitcoin where holding funds automatically means you can both send and receive, Lightning users must actively manage their balance distribution to maintain both inbound liquidity (ability to receive) and outbound liquidity (ability to send).

For a merchant receiving payments, channels quickly become saturated on the local side: plenty of funds to send, but no capacity to receive more payments. For a consumer spending bitcoin, the opposite happens: all funds move to the remote side, leaving nothing to send. Both scenarios require active rebalancing to maintain payment flow.

This problem compounds across a routing node's many channels. A node operator running dozens of channels must continuously monitor and rebalance each one. Payment routing fails when any hop in the path lacks sufficient balance in the right direction, making balance management a network-wide concern.

Balance Management Strategies

Several techniques exist to manage channel balance, each with different cost and complexity tradeoffs. For a comprehensive guide, see the Lightning channel management guide.

Circular Rebalancing

Circular rebalancing routes a payment from yourself, through the network, back to yourself. If your channel with Alice is depleted (low local balance) but your channel with Bob has excess local balance, you can send a payment from yourself via Bob, through the network, arriving back at yourself via Alice. This shifts funds from your Bob channel to your Alice channel without any on-chain transaction.

The cost is only the routing fees charged by intermediate nodes. However, finding a viable circular route can be difficult, and the economics do not always work: some node operators have reported spending more on rebalancing fees than they earn from routing.

Submarine Swaps

Submarine swaps exchange on-chain bitcoin for Lightning balance (or vice versa). Services like Loop offer this: a Loop Out sends funds from your Lightning channel to an on-chain address, freeing up inbound capacity. A Loop In does the reverse, converting on-chain funds into Lightning balance.

Submarine swaps require an on-chain transaction, making them slower and more expensive than circular rebalancing. But they are more reliable because they do not depend on finding a circular route through the network.

Liquidity Ads

Liquidity ads allow nodes to advertise their willingness to open channels and provide inbound liquidity in exchange for a fee. A merchant who needs inbound capacity can use liquidity ads to find peers willing to open dual-funded channels, gaining immediate receiving capacity.

Splicing

Splicing allows adding or removing funds from an existing channel without closing it. A splice-in adds on-chain funds to increase capacity, while a splice-out removes funds to an on-chain address. The channel remains operational throughout the process, making splicing a powerful tool for adjusting capacity on demand.

Use Cases

• Routing node operation: node operators monitor channel balances across all their channels, rebalancing proactively to ensure payment routing succeeds in both directions. Tools like Autoloop automate this process.
• Merchant payment acceptance: merchants receiving Lightning payments need consistent inbound capacity. They use a combination of Lightning Service Providers, liquidity ads, and submarine swaps to maintain receiving capacity.
• Payment routing optimization: the network relies on well-balanced channels for reliable payment delivery. Nodes with imbalanced channels cause routing failures, increasing the importance of balance management for overall network health.
• Liquidity planning: businesses building on Lightning must forecast their payment volume and direction to provision adequate channel capacity. A payment processor expecting mostly inbound payments needs different channel configurations than a wallet expecting mostly outbound.

Risks and Considerations

Liquidity Imbalances Cause Payment Failures

When a channel's balance is pushed entirely to one side, it becomes a one-way street. A channel with no remote balance cannot receive payments; a channel with no local balance cannot send. This is the primary cause of Lightning payment failures, particularly for larger amounts that exceed available balance on any single hop.

Rebalancing Costs

Every rebalancing operation has a cost: routing fees for circular rebalancing, on-chain fees plus service fees for submarine swaps, and lease fees for liquidity ads. For small routing nodes, rebalancing costs can exceed routing fee income, making the node economically unviable.

Capital Inefficiency

Funds locked in Lightning channels cannot be used for anything else. A well-balanced channel with 50/50 distribution means half the locked funds are effectively idle at any given moment: local balance waits to be sent, remote balance waits to be received. This capital inefficiency is inherent to the channel model.

How Spark Eliminates Channel Balance

The channel balance problem is a fundamental constraint of payment channel networks, not a bug to be fixed. Protocols like Spark take a different approach entirely: instead of using channels, Spark transfers ownership of UTXOs by rotating cryptographic keys between sender, recipient, and a distributed operator set. There are no channels to balance, no inbound liquidity to acquire, no reserves to maintain, and no force-close scenarios. For a detailed comparison, see the Lightning vs. Spark overview or the Lightning Network liquidity explained deep dive.

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.