A lightning channel is far more than a simple connection between two nodes — it is a dynamic, bidirectional payment pipe with a fixed capacity that shifts between two parties as payments flow. In Lesson 4.1, you learned the fundamentals of how the lightning network works. Now we go deeper into the mechanics of channels, the concept of inbound liquidity, how payments route across the network, and how BOLT11 invoices encode all the information needed to complete a payment.
Understanding these topics is essential before you start managing channels yourself. The difference between a smooth lightning experience and constant payment failures often comes down to how well you understand channel balances and routing.
Understanding Lightning Channels in Depth
Every lightning channel has a fixed capacity determined by the funding transaction. If Alice opens a channel with Bob and commits 0.05 BTC, that channel has a capacity of 0.05 BTC. This capacity does not change unless the channel is closed and reopened (or, with newer technology like splicing, resized on the fly).
Channel Capacity
The total bitcoin locked in a channel is its capacity. This is a hard ceiling — no single payment through this channel can exceed its capacity. If a channel has a capacity of 500,000 sats, you cannot route a 600,000 sat payment through it, regardless of the balance distribution.
Capacity can be funded by one side (single-funded channel) or by both sides (dual-funded channel). Dual-funded channels are useful because they start with liquidity on both sides, which means both parties can send and receive immediately.
Local vs Remote Balance
Within a channel, the capacity is split between two balances:
- Local balance: The amount on your side of the channel. This is what you can send.
- Remote balance: The amount on your channel partner’s side. This is what you can receive.
These two numbers always add up to the total channel capacity (minus a small reserve). If a channel has 500,000 sats capacity and your local balance is 300,000 sats, then your remote balance is approximately 200,000 sats.
Channels Are Bidirectional
Lightning channels are not one-way streets. Funds flow back and forth as payments are made. If Alice pays Bob 10,000 sats, her local balance decreases by 10,000 sats and Bob’s local balance increases by 10,000 sats. If Bob later pays Alice 5,000 sats, the flow reverses partially.
This bidirectional nature is what makes the lightning network efficient. A single channel between a coffee shop and a supplier can handle payments flowing in both directions — the shop pays the supplier for beans, and the supplier might pay the shop for catering an event. The channel rebalances naturally through use.
Inbound vs Outbound Liquidity
The concept of inbound liquidity is the single most confusing topic for lightning newcomers, and misunderstanding it is the #1 cause of frustration when receiving payments fails.
Outbound Liquidity
Outbound liquidity is your local balance — the funds on your side of your channels. When you open a channel and fund it with bitcoin, that entire amount is outbound liquidity. You can send up to that amount.
Getting outbound liquidity is straightforward: fund a channel. As soon as the funding transaction confirms, you have outbound liquidity equal to your channel balance.
Inbound Liquidity
Inbound liquidity is the remote balance across your channels — funds sitting on the other side that can flow toward you. This represents how much you can receive.
Here is why this confuses people: when you first open a lightning channel and put 100,000 sats in, you have 100,000 sats of outbound liquidity but zero inbound liquidity. You can send payments, but nobody can pay you because there is no capacity flowing in your direction.
Think of it like a water pipe. If all the water is pushed to your end, nothing can flow toward you. Someone else needs to have water on their end that can flow your way.
How to Get Inbound Liquidity
There are several strategies to obtain inbound liquidity:
- Have someone open a channel to you: When another node opens a channel to you and funds it, that entire capacity is your inbound liquidity. This is common for merchants — they ask customers or services to open channels to them.
- Spend first, receive later: When you send payments through a channel, your local balance decreases and your remote balance (inbound) increases. Simply using the lightning network for payments naturally creates inbound liquidity.
- Submarine swaps: Services like Loop Out let you send lightning sats and receive on-chain bitcoin. This drains your local balance, converting outbound into inbound liquidity.
- Buy from a Lightning Service Provider (LSP): Services sell inbound liquidity by opening channels to you for a fee. Wallets like Phoenix and Breez handle this automatically behind the scenes.
- Dual-funded channels: Both parties contribute funds when opening the channel, giving each side both inbound and outbound from the start.
Modern wallets abstract most of this complexity. Phoenix Wallet, for example, automatically manages inbound liquidity using its LSP, charging a 1% fee when new inbound capacity is needed. But if you run your own node, understanding and managing inbound liquidity is a core skill.
How Lightning Routing Works
When you make a payment on the lightning network, your wallet must find a path from your node to the recipient’s node through a series of connected channels. This process is called routing.
Multi-Hop Payments
Most lightning payments travel through multiple intermediate nodes. Your wallet’s pathfinding algorithm evaluates available routes based on:
- Channel capacity: Does each channel along the route have enough capacity?
- Channel balance: Is the liquidity on the correct side? (Public nodes only advertise capacity, not balance distribution, so this involves probabilistic guessing.)
- Fees: What is the total routing fee across all hops?
- Reliability: Has this route worked well in the past?
- Number of hops: Fewer hops generally means faster, cheaper, more reliable payments.
Modern pathfinding algorithms like those in LND and CLN maintain a scoring system that tracks past payment success and failure, improving route selection over time.
Onion Routing
The lightning network uses onion routing for privacy. When your wallet constructs a payment route, it encrypts the routing instructions in layers — like an onion. Each intermediate node peels off one layer to learn only two things: who sent them this packet (previous hop) and where to forward it (next hop).
No intermediate node learns:
- Who originated the payment
- Who the final recipient is
- The total path length
- The total payment amount (each hop only sees the amount they need to forward)
This is a significant privacy advantage over on-chain Bitcoin transactions, where the sender, recipient, and amount are visible to anyone examining the blockchain.
Routing Fees as Incentives
Intermediate nodes charge small fees for forwarding payments. These fees serve two purposes: they compensate node operators for providing liquidity and keeping their nodes online, and they help the pathfinding algorithm select efficient routes (lower-fee routes are preferred).
Each node sets its own fee policy with two parameters:
- Base fee: A fixed amount per forwarded payment (e.g., 1 sat)
- Fee rate: A proportional amount based on the payment size (e.g., 100 ppm = 0.01%)
For a deep analysis of fee structures and strategies, see our lightning network fees complete guide.
Lightning Invoices Explained
To receive a lightning payment, the recipient generates a lightning invoice. This invoice encodes all the information the sender’s wallet needs to construct and route the payment.
BOLT11 Invoices
The BOLT11 invoice standard is the most widely used invoice format on the lightning network. A BOLT11 invoice is a long string of characters (usually prefixed with lnbc for mainnet) that encodes:
- Payment hash: A cryptographic hash that the sender must provide the preimage for (this is what makes HTLCs work)
- Amount: The requested payment amount (optional — “zero-amount” invoices let the sender choose)
- Expiry time: How long the invoice is valid (default is 1 hour)
- Description: A human-readable note (e.g., “Coffee at Bitcoin Café”)
- Routing hints: Suggested paths to reach the recipient, especially useful if the recipient’s channels are private
- Recipient’s public key: Identifies the destination node
A BOLT11 invoice is typically displayed as a QR code for easy scanning. When you scan this code with your lightning wallet, the wallet decodes all the information and constructs the payment automatically.
Key limitation: each BOLT11 invoice can only be paid once. If you pay it and then someone else tries to pay the same invoice, the second payment will fail.
BOLT12 Offers
BOLT12 is a newer standard that addresses several limitations of BOLT11:
- Reusable: A single offer can be paid multiple times (perfect for donation pages or tip jars)
- No amount required: The sender specifies the amount at payment time
- Better privacy: The offer does not reveal the recipient’s node ID
- Refund support: Built-in mechanism for the recipient to return funds
- Payer proofs: Cryptographic proof that a specific payer made the payment
BOLT12 is still being adopted across wallets and implementations, but it represents the future of lightning payment requests. CLN (Core Lightning) has led its development, and support is expanding to other implementations.
Lightning Channel Management Best Practices
Effective lightning channel management is what separates a well-running node from one plagued by payment failures. Here are the core principles:
Keep Channels Balanced
A channel where all the funds are on one side is only useful for payments flowing in one direction. Aim to keep your channels roughly balanced — around 50/50 local-to-remote ratio — so you can both send and receive.
Strategies for rebalancing:
- Circular rebalancing: Route a payment from one of your channels back to another through the network, shifting funds internally
- Submarine swaps: Use Loop In (on-chain → lightning) to increase local balance, or Loop Out (lightning → on-chain) to increase remote balance
- Natural use: If you both send and receive payments regularly, channels rebalance naturally
Close Inactive Channels
Channels with peers who are frequently offline or that see no payment activity tie up capital without providing value. Periodically review your channels and cooperatively close ones that are not contributing to your payment flow or routing revenue.
Choose Channel Partners Wisely
The nodes you connect to determine your reach in the network. Prioritize well-connected, high-uptime nodes with sufficient capacity. For routing nodes, connecting to a diverse set of peers across different network regions improves your routing success.
For a complete walkthrough of advanced techniques, including automated rebalancing tools and capacity planning, see our lightning channel management masterclass.
Common Routing Problems
Even with well-managed channels, you will occasionally encounter payment failures. Understanding the common causes helps you troubleshoot quickly.
No Route Found
Your wallet could not find any path to the recipient. Causes include:
- Recipient’s node is offline or has no public channels
- No connected path exists between your node and theirs
- All potential routes lack sufficient capacity
Solution: Open additional channels to well-connected nodes, or ask the recipient for updated routing hints.
Insufficient Liquidity
A route exists, but one or more channels along the path do not have enough balance on the correct side to forward your payment. This is common for larger payments.
Solution: Try a smaller amount, use Multi-Path Payments (MPP) to split across routes, or try again later when channel balances may have shifted.
Channel Capacity Exceeded
Your payment amount exceeds the capacity of a channel along the route. Even if balance is available, a single channel cannot forward more than its total capacity.
Solution: MPP can split the payment. Or find routes through larger channels.
Expired HTLC / Timeout
The payment took too long to resolve, and the time locks expired. This can happen with very long routes or unresponsive nodes.
Solution: Retry. The pathfinding algorithm will usually avoid the problematic node on the next attempt.
For step-by-step solutions to these and other issues, see our lightning troubleshooting guide for failed transactions.
Key Takeaways
- A lightning channel has a fixed capacity split between local balance (what you can send) and remote balance (what you can receive)
- Inbound liquidity — capacity on the remote side of your channels — is required to receive payments and is the most misunderstood concept for newcomers
- Payments route through multiple hops using onion routing, where each node only knows the previous and next hop for privacy
- BOLT11 invoices encode payment hash, amount, expiry, and routing hints — they are single-use by design
- BOLT12 offers are the next evolution: reusable, more private, and more flexible than BOLT11
- Channel management — keeping balances roughly even, closing dead channels, and choosing good peers — directly impacts payment reliability
- Common routing failures (no route, insufficient liquidity, timeouts) each have specific causes and solutions
Frequently Asked Questions
What is the difference between inbound and outbound liquidity?
Outbound liquidity is the bitcoin on your side of a channel — it determines how much you can send. Inbound liquidity is the bitcoin on the remote side of your channels — it determines how much you can receive. When you open and fund a new channel, you start with full outbound but zero inbound. As you spend, outbound converts to inbound. This is why new nodes often struggle to receive payments until they build up inbound capacity.
Can I increase a channel’s capacity without closing it?
Yes, through a technique called splicing. Splicing allows you to add or remove funds from an existing channel with a single on-chain transaction, without any downtime. While the splice transaction confirms on-chain, the channel continues operating with the old capacity. Phoenix Wallet uses splicing extensively to resize channels automatically. Not all implementations support splicing yet, but it is becoming standard.
How do I decode a lightning invoice to see what is inside?
Most lightning wallets show invoice details when you scan one. For manual decoding, tools like lncli decodepayreq <invoice> (LND) or lightning-cli decode <invoice> (CLN) display all encoded fields. Online decoders also exist, but avoid pasting invoices with real payment details into third-party websites, as this reveals your node identity and payment amounts.
Why do some of my lightning payments fail?
The most common causes are: insufficient liquidity along the route, the recipient being offline, expired invoices, or the payment amount exceeding the capacity of channels along the path. Modern wallets retry with different routes automatically. If failures persist, opening channels to better-connected nodes or using different wallets with built-in LSPs can improve reliability significantly.
What happens to my funds if a routing node in the middle goes offline?
Your funds are safe. HTLCs have time-locked expiration — if a routing node fails to forward the payment within the time limit, the HTLC expires and your funds return to you automatically. This is a core safety feature of the lightning protocol. You may experience a delay (minutes to hours in rare cases), but you will never lose funds due to an intermediate node going offline.