Lightning Network Channel Capacity Planner
Estimate the Bitcoin Lightning channel capacity you need from average payment size, daily volume, rebalance frequency, and a safety buffer. Educational. Runs in your browser.
How long the channel must last before you top up or rebalance.
A rough planning heuristic: capacity per direction ≈ average payment × payments per day × days between rebalances × (1 + buffer). Sending nodes need outbound (local) liquidity; receiving nodes need inbound (remote) liquidity; a routing node needs both. Real channels also depend on fees, peer reliability, and network topology. This is a back-of-envelope estimate, not financial or investment advice. Everything runs in your browser.
About this tool
The Bitcoin Lightning Network moves payments through payment channels — two-party balances that let funds flow back and forth off-chain. Each channel has a fixed total capacity split into local (outbound) liquidity, which lets you send, and remote (inbound) liquidity, which lets you receive. Sizing a channel well matters: too little capacity and payments fail or you must rebalance constantly (paying fees and on-chain costs); too much and you lock up bitcoin that earns nothing and could be deployed elsewhere. This planner gives a back-of-envelope estimate using a simple heuristic — capacity per direction ≈ average payment size × payments per day × days between rebalances × (1 + safety buffer). The logic is that your channel must hold enough liquidity in the relevant direction to cover all the payments you expect to push through it before you next top it up or rebalance, plus a cushion for variability. A node that mostly sends (a merchant paying suppliers, a wallet user) needs outbound liquidity; a node that mostly receives (a merchant taking payments) needs inbound liquidity, which usually has to be acquired from a peer or liquidity provider; a routing node needs both sides funded. Real-world channel design also depends on routing fees, peer uptime and reliability, on-chain fee conditions when opening or closing, and overall network topology, so treat this as a starting point for planning rather than a precise prescription. This is educational and not financial or investment advice. Everything runs in your browser; nothing is uploaded.
How to use it
- Enter the average payment size in satoshis (1 BTC = 100,000,000 sats).
- Enter how many payments per day you expect to flow through the channel.
- Set how many days the channel should last between rebalances or top-ups.
- Add a safety buffer percentage for variability.
- Pick whether you mainly send, receive, or route, and read the recommended capacity.
Frequently asked questions
- How much Lightning channel capacity do I need?
- As a rough rule, capacity per direction ≈ average payment × payments per day × days between rebalances × (1 + buffer). This covers the volume you expect to push through before topping up, plus a cushion. Actual needs vary with fees and peer reliability.
- What is the difference between inbound and outbound liquidity?
- Outbound (local) liquidity is your side of the channel balance and lets you send. Inbound (remote) liquidity is the peer's side and lets you receive. Sending needs outbound; receiving needs inbound; routing needs both.
- Why do I need inbound liquidity to receive payments?
- A payment to you moves balance from the peer's side to yours, so the peer must already hold that balance (your inbound liquidity). New nodes often have plenty of outbound but little inbound and must acquire it via a liquidity provider, channel swap, or by spending.
- What is rebalancing and why does it affect sizing?
- Rebalancing shifts liquidity between channels or tops them up so payments keep flowing. The longer you want a channel to operate before rebalancing, the more capacity it needs — which is why days-between-rebalances is part of the estimate.
- Is this an exact figure?
- No. It is a planning heuristic. Real capacity depends on routing fees, peer uptime, on-chain fee conditions, and network topology. Use it as a starting point and adjust from experience.
- Is anything uploaded?
- No. All calculations run entirely in your browser, and this is not financial advice.