Channel Capacity

Channel capacity is the total amount of bitcoin committed to a Lightning payment channel between two nodes. It is fixed at the moment the channel's funding transaction confirms on-chain and can only change afterward by closing the channel or, more recently, by splicing funds in or out. Capacity sets the hard ceiling on the size of any single payment that channel can carry: a 5,000,000-satoshi channel can never forward a 6,000,000-satoshi payment, no matter how the balance is arranged.

Outbound versus inbound

Capacity splits into two directional components. Outbound capacity is the bitcoin sitting on your side of the channel — what you can send. Inbound capacity is the bitcoin on your peer's side — what you can receive. The two always sum to the total channel capacity, and every payment that crosses the channel shifts balance from one side to the other without changing the total. Think of it as beads on an abacus wire: the wire's length is fixed at funding time, and payments just slide beads back and forth.

When you open a channel by spending your own UTXO into the funding output, all of the funds begin on your side. You start with full outbound capacity and zero ability to receive. Sending payments moves balance toward your peer and simultaneously frees up inbound room. This asymmetry surprises newcomers constantly: a freshly funded node can pay anyone but cannot get paid by anyone until balance has moved, which is why acquiring inbound liquidity is its own discipline, with its own tools and marketplaces.

Sizing channels in practice

Bigger is not automatically better, but too small is definitely worse. A channel that is too small fails routing attempts, forces payments to split across multiple paths, and burns its economic value on the fixed on-chain cost of opening and closing it. Most operators prefer fewer, larger channels to well-connected peers over many dust-sized ones. A useful rule of thumb: a channel should be large enough that the on-chain open and close costs amount to a small fraction of the value it will route or hold over its lifetime, and large enough to carry your typical payment several times over without exhausting one side. The other constraint is concentration: capacity locked in a channel is capacity committed to that one peer, so a node runner balances channel size against how much they trust the peer's uptime and behavior. For a routing node, capacity is inventory — the working stock that earns fees — and the operator's job is keeping that stock split usefully between the two directions.

Changing capacity after the fact

For most of Lightning's history, resizing a channel meant closing it and opening a new one: two on-chain transactions, fees paid twice, and routing history lost. Splicing changes that by letting peers cooperatively rewrite the funding output, adding or removing funds while the channel keeps operating. Capacity is still fixed between splices — the invariant that makes Lightning's off-chain accounting sound — but the channel is no longer a one-shot commitment.

Why it matters for sovereign operators

For a home node runner on the Lightning Network, channel capacity is where self-custody meets operations. The funds in your channels are still your keys and your coins, but their usefulness depends on how you have allocated them. A merchant expecting to receive needs inbound; a spender needs outbound; a router needs both, roughly balanced. Watching how your capacity distributes across peers — and rebalancing, splicing, or opening strategically when it drifts — is the core recurring task of running Lightning infrastructure. The total on the abacus wire is yours; making it flow in the direction your use case demands is the craft.