Bitcoin Lightning Network Explained: Inbound Liquidity, Routing and Fees
The Lightning Network is a Bitcoin payment-channel system that allows participating nodes to transfer bitcoin using off-chain channel balances, with the base chain providing funding and dispute settlement mechanisms. A payment route requires sufficient liquidity in the appropriate direction across every channel. Outbound liquidity is a node’s ability to send; inbound liquidity is its ability to receive. Total channel capacity alone does not guarantee a payment can complete.
Lightning payments differ from ordinary Bitcoin on-chain transactions because they depend on peer connectivity, directional channel balances, routing and channel-state security. This guide explains why inbound and outbound liquidity matter, how payments traverse multiple peers, why fees change and what merchants should monitor when accepting Lightning payments.
Key takeaways
- Channel capacity is split between local and remote balances.
- Outbound capacity is needed to send through a channel, while inbound capacity is needed to receive.
- A multi-hop payment requires sufficient directional capacity at every hop.
- Routing fees compensate forwarding nodes and may vary with channel conditions.
- Channel backups, uptime, liquidity management and on-chain fees remain operational risks.
A payment channel is not just a wallet balance
A Lightning channel is established through an on-chain Bitcoin funding arrangement and a protocol for updating its allocation between participating peers. The total channel capacity is not the same as the amount one participant can send or receive. If all capacity is currently on one participant’s side, that party can generally send but cannot receive significant funds through that same channel until liquidity moves in the opposite direction. Channel fees, reserves and implementation rules affect actual spendable values.
Local balance and outbound liquidity
A channel’s local balance represents funds attributable to a node on that channel under current state. It supports payments or forwards travelling outward from that node. A person opening a new channel with funds entirely on their own side may initially have substantial outbound capacity but almost no inbound capacity. The useful amount can be reduced by channel reserves, in-flight HTLCs and constraints. Therefore a dashboard showing ‘one million sats capacity’ does not automatically mean a user can receive one million sats.
Remote balance and inbound liquidity
Inbound liquidity represents capacity held by the remote peer that can move toward the local node if someone sends a payment through that channel. A merchant seeking to receive frequent payments needs adequate inbound capacity from useful peers. Simply opening more channels funded entirely by the merchant may add outward capacity rather than the needed inbound capacity. The Lightning Labs documentation discusses strategies for acquiring inbound capacity and managing outbound/inbound distribution.
How multi-hop routing works
Lightning can route a payment through multiple intermediary nodes using conditional payment mechanisms, commonly hashed time-locked contracts. Each forwarding channel must have suitable liquidity in the required direction. Nodes need not expose the full payment relationship to every intermediary. Route finding considers fee schedules, capacity estimates and other constraints. A payment may fail because one route lacks liquidity, even when the sender has sufficient total wallet funds and the recipient is online.
The purpose of payment hashes and timelocks
A multi-hop payment uses cryptographic conditions so intermediaries can settle or fail linked transfers subject to protocol rules. Timelocks give participants a route to recover or settle funds if the forwarding process stalls, but they also create time-sensitive on-chain obligations during disputes. Operational safety depends on current channel state management and monitoring. It is incorrect to assume Lightning is simply instant Bitcoin transfer with no counterparty or technical risks.
How routing fees are determined
Forwarding nodes commonly set a base fee and a proportional fee based on transferred amount, with network implementations also supporting variations and policy changes. Fees can rise when outbound capacity on a valuable route becomes scarce. Payment cost may vary as routing algorithms select alternative paths. A quoted payment fee is not necessarily a constant network tariff. The cheapest route may fail if it lacks sufficient capacity, making reliability and liquidity management important alongside price.
Worked concept of liquidity shifting
Suppose a channel between nodes A and B has 1,000,000 satoshis capacity, with 700,000 sats on A’s side and 300,000 on B’s side, ignoring reserves. A can send at most roughly 700,000 across that channel, and receive at most roughly 300,000 through it. If A sends 200,000 sats to B, the balances become approximately 500,000 local and 500,000 remote. A’s outbound capacity falls while inbound capacity rises. Fees and in-flight reservations may make exact values slightly different.
Why a routing node needs balance in both directions
A routing node can earn fees by forwarding payments between peers only when it has inbound capacity on the incoming channel and outbound capacity on the outgoing channel. A node connected to many peers might still be ineffective if its channels are skewed in the wrong directions. Operators may rebalance by sending through routes or using on-chain and off-chain services, but these actions cost fees and can consume liquidity. High forwarding volume alone is not evidence of high net routing profitability.
Rebalancing and capital efficiency
Rebalancing moves liquidity between a node’s channels so that future payments can travel. It may involve circular payments, submarine swaps or changing channel relationships. The expected routing fees earned from improved capacity need to exceed fees and operational costs. A channel that sits unused can tie up bitcoin that could otherwise be deployed or kept in cold custody. Operators should assess capital utilisation, liquidity demand by direction and the reliability of connected peers.
Payments can fail for several reasons
A failed Lightning payment does not necessarily mean the recipient wallet has no money or that the Bitcoin blockchain is offline. Possible causes include insufficient directional liquidity, stale route information, peer downtime, channel limits, expiry constraints or fee settings. Some wallets retry across multiple paths. Users should distinguish an attempted payment, a settled payment and a payment still in flight rather than interpreting all wallet notifications as final settlement.
Security, channel closures and on-chain fees
When a channel must close, participants may need to publish on-chain transactions and wait for appropriate confirmation. Under some closure conditions, funds can be temporarily unavailable. High Bitcoin transaction fees can make opening or closing small channels expensive relative to their capacity. Channel-state backups, monitoring and software quality are crucial; mishandling recovery data may put funds at risk even when the Lightning protocol itself operates as intended.
What to check before relying on Lightning
A merchant or analyst should consider user experience, inbound liquidity, wallet custody model, fee transparency, fallback payments, operational uptime and the ability to exit channels during blockchain congestion. A custodial Lightning service introduces provider counterparty exposure, while a self-operated node creates maintenance responsibilities. Do not confuse nominal channel counts, public capacity and successful routable payments when evaluating network adoption.
Worked example
Imagine a fictional merchant has a Lightning channel of 2,000,000 sats, with only 100,000 sats on the remote peer’s side and 1,900,000 on the merchant’s side. Despite the large total capacity, the merchant may have only about 100,000 sats of incoming ability through that channel, ignoring reserves. A customer attempting to pay 250,000 sats cannot use that direct inbound route without more liquidity. The merchant may need another inbound-capable path or liquidity adjustment.
For a routing fee example, assume a fictional hop charges a 1-sat base fee plus 100 parts per million of the amount forwarded. On a 500,000-sat payment, proportional fee is 500,000×100/1,000,000 = 50 sats; total at that hop is 51 sats, before other route fees. A more expensive route may be more reliable, so a transaction’s final fee reflects routing conditions rather than one universal percentage.
Professional comparison table
| Concept | Meaning | Limitation |
|---|---|---|
| Channel capacity | Total funds allocated to channel | Not all spendable in one direction |
| Outbound liquidity | Ability to send through channel | Decreases after outgoing payment |
| Inbound liquidity | Ability to receive through channel | Needs remote-side capacity |
| Routing fee | Charge for forwarding payments | Varies by node and route |
| Channel closure | Return to on-chain state | Settlement and timing costs |
Research and risk checklist
Assess channel capacity separately from local and remote balances, active peer reliability, fee schedules and successful payment volume. For a merchant, measure how much incoming payment capacity is available at expected ticket sizes, not only the number of channels or the amount of BTC committed.
For technical operations, ensure secure backups, robust monitoring and procedures for unexpected closures and on-chain fee spikes. Review the custody and recovery model of the wallet or service being analysed. A successful test payment does not guarantee a larger payment can be routed through the same network state.
Frequently asked questions
What is inbound liquidity?
The ability of a Lightning node to receive payments through a channel, typically determined by capacity on the remote side.
Why can Lightning payments fail despite enough BTC?
Directional route liquidity, peer availability, limits or fees can prevent completion.
What does a routing node earn?
Fees from forwarding successful payments, less operating and liquidity management costs.
Is Lightning the same as an on-chain Bitcoin transfer?
No. It updates payment-channel balances off-chain, with the Bitcoin chain used for channel funding and settlement.
Does more public channel capacity guarantee better payments?
No. Direction, connectivity, payment size and peer reliability determine usability.
Sources and further reading
- Lightning Labs: Managing Channel Liquidity
- Lightning Labs: Managing Liquidity on the Lightning Network
- Lightning Labs: Liquidity Report
Related Traders MBA lessons: Bitcoin UTXO model and Bitcoin mempool and settlement fees.
General technical and financial education, not a recommendation to buy cryptoassets, operate mining hardware or use any protocol. Digital assets and smart contracts can create substantial or total loss, technical and legal risk.