Course outline · 10 lessons
Lightning Network & Bitcoin Nodes

Lightning Channels and Routing: How Payments Find Their Path

Lesson 2 of 10 27 min read Updated
Six ivory beads on a single brass rod, grouped four on one side and two on the other, in a dark frame on pale stone.

A lightning channel is a shared balance between two nodes: a fixed amount of bitcoin that shifts from one side to the other as payments flow. In Lesson 4.1 you saw how the lightning network works. This lesson goes deeper into channels, into inbound liquidity (why a new wallet or node often can’t receive), into how payments find a path across the network, and into the BOLT11 invoices that carry everything a payer needs.

Understanding Lightning Channels in Depth

Every lightning channel has a fixed capacity, set by the funding transaction. If Alice opens a channel with Bob and commits 0.05 BTC, the channel’s capacity is 0.05 BTC. It stays that way until the channel is closed, or until it is resized with a newer technique called splicing.

Channel Capacity

Capacity is a hard ceiling. No single payment through a channel can be larger than its capacity: a 500,000-sat channel can’t carry a 600,000-sat payment, however the balance is split.

A channel can be funded by one side (single-funded) or by both (dual-funded). A dual-funded channel starts with money on both sides, so both parties can send and receive from the start.

Local vs Remote Balance

Inside a channel, the capacity is split into two balances:

  • Local balance: the amount on your side. This is what you can send.
  • Remote balance: the amount on your partner’s side. This is roughly what you can receive.

The two add up to the capacity, minus a few amounts the protocol keeps aside:

  • The channel reserve: each side must keep a small part of the channel that it can’t spend, so it always has something to lose if it tried to cheat by publishing an old balance. The Lightning specification suggests 1% of the channel (BOLT 2). It can’t be smaller than the dust limit, which BOLT 2 sets at 354 sats or more, so on a small channel the reserve is more than 1%: at least 354 sats on a 25,000-sat channel, where 1% would be 250. A side that hasn’t yet reached its reserve, such as your partner’s side of a channel you have just funded, can still receive, but it can’t send until it holds more than its reserve (BOLT 2).
  • Money set aside for closing fees, in case the channel has to be force-closed. This amount rises and falls with on-chain fees and can be significant. On most channel types, whoever opened the channel pays the fee built into its force-close transaction, so this money comes out of the opener’s side (BOLT 2).
  • Payments in flight, which tie up part of the balance until they finish.

Phoenix’s documentation gives an example: a channel with a balance of 5,000 sats and a capacity of 25,000 sats can’t actually receive 20,000 sats, because part of the remaining room is locked for these reasons (Phoenix FAQ). That is why “what you can receive” is always a little less than it looks.

A channel between you and your partner with a capacity of 25,000 sats, drawn as one bar. 5,000 sats sit on your side: your balance, what you can send. The other 20,000 sats are on your partner's side, roughly what you can receive, but a small part of that room is kept aside, locked, for the channel reserve, closing fees and payments in flight. So this channel can't receive the full 20,000 sats.
What you can send and what you can receive add up to the channel’s fixed capacity, minus a little. In Phoenix’s example, a 25,000-sat channel with 5,000 sats on your side can’t actually receive the other 20,000: the channel reserve, closing fees and payments in flight lock part of that room.

Channels Are Bidirectional

Money moves both ways: if Alice pays Bob 10,000 sats and Bob later pays Alice 5,000, part of it flows back. A channel used in both directions keeps itself in balance.

Inbound vs Outbound Liquidity

Inbound liquidity is the topic that confuses newcomers most, and the most common reason a payment to them fails.

Picture a channel as a wire with a fixed number of beads on it, like an abacus. The number of beads is the capacity. Each payment slides beads along the wire: paying slides them toward your partner, receiving slides them toward you. You can only slide beads toward yourself if some are sitting at your partner’s end.

Outbound Liquidity

Outbound liquidity is the beads at your end: your local balance across all your channels, and the most you can send. When you open a channel and fund it yourself, the whole amount is outbound. Getting it is easy: fund a channel, and once the funding transaction confirms, you can send.

Inbound Liquidity

Inbound liquidity is the beads at your partners’ ends: the remote balance across your channels, and roughly the most you can receive.

This is the trap: open a channel with 100,000 sats of your own and all 100,000 beads sit at your end. You can send, but nobody can pay you through that channel, because there is nothing at the other end to slide toward you.

A channel drawn as an abacus wire: the beads are the capacity, beads at your end are yours, beads at your partner's end are theirs. First, you fund a 100,000-sat channel yourself: every bead sits at your end, so you can send 100,000 sats but receive nothing. Next, you pay through it: the beads you pay slide to your partner's end, so you can now receive about what you paid. Last, a channel someone else opens and funds to you: every bead sits at their end, so you can't send through it but all of it is inbound for you.
A channel you fund yourself can send, but it can’t receive. Inbound liquidity is the beads sitting at your partner’s end. You get it by spending, or when someone else opens and funds a channel to you.

How to Get Inbound Liquidity

  1. Spend first: every payment you send moves beads to your partner’s end, which you can later receive back. Simply using Lightning creates inbound liquidity.
  2. Have someone open a channel to you: when another node opens and funds a channel to you, its whole balance is on their side, so all of it is inbound for you. Merchants often ask for this.
  3. Swap out to on-chain: a submarine swap is an exchange between Lightning and on-chain bitcoin, locked together so neither side can cheat. Sending Lightning sats to a swap service and receiving on-chain bitcoin back (a “Loop Out”, after Lightning Labs’ tool for LND nodes; Boltz, which offered similar swaps from any wallet, has been offline since 3 August 2026) moves beads to the other end of your channel. Lesson 4.4 explains swaps.
  4. Buy it from a Lightning Service Provider (LSP): a company that opens channels to you for a fee. Wallets like Phoenix do this automatically behind the scenes.
  5. Dual-funded channels: both parties put money in when opening, so each starts with inbound and outbound.

Phoenix, for example, handles inbound liquidity itself. When a payment arrives that doesn’t fit, it resizes your channel and charges 1% plus the mining fee; creating your first channel costs 1,000 sats (Phoenix fee table). If you run your own node, managing inbound liquidity is your job.

How Lightning Routing Works

When you pay someone you don’t share a channel with, your wallet has to find a path of connected channels from you to them. This is routing.

Multi-Hop Payments

Most payments pass through one or more intermediate nodes. Your wallet weighs possible routes by:

  • Capacity: is every channel on the route big enough?
  • Balance: is the money on the right side of each channel? Nodes publish their channels’ capacity but not how it is split, so the wallet has to guess.
  • Fees: what do all the hops charge together?
  • Reliability: has this route worked before?
  • Number of hops: fewer hops usually means cheaper and more reliable.

Node software such as LND and Core Lightning (CLN) remembers which payments succeeded and failed, and uses that to pick better routes next time.

Onion Routing

Lightning uses onion routing for privacy. Your wallet wraps the route instructions in layers of encryption, like an onion. Each node peels off one layer and learns where the payment came from (the previous hop), where to send it next and how much to pass on. Nothing more about the route is written in its layer.

A node in the middle of the route usually can’t tell:

  • who started the payment
  • who receives it in the end
  • how long the route is

The exception is the node right next to you. A phone wallet usually has a single channel, to its LSP, and doesn’t forward payments for anyone else. So when a payment comes out of that channel, the LSP can tell it came from you. In the same way, if the person you pay receives through one private channel (a channel that isn’t announced to the rest of the network, as most phone wallets’ channels are), the node just before them knows who is being paid. Phoenix goes further: it hands each payment to ACINQ’s node to find the route, so ACINQ also sees where the payment goes (Lesson 4.3 explains this trade-off).

Every node on the route does see roughly how much is being paid. Each hop is told the amount to pass on, and that amount is the payment plus the fees still owed to the hops after it (BOLT 4), which is close to the full amount. Splitting a payment into parts that take different routes (multi-path payments) hides the total from a hop that only carries some of the parts.

A route from you through your LSP, a node in the middle and the node before the recipient, to the recipient. Your wallet wraps the route in layers like an onion, and each node peels off one. Can each node tell who sent the payment? Your LSP can, because it is your only channel; the others usually can't. Who gets paid? Your LSP usually can't, but with Phoenix ACINQ does; a node in the middle usually can't; the node before the recipient can if the recipient has one private channel. About how much? Every hop can, roughly, because it is told to pass on the payment plus the fees still owed to the hops after it.
Onion routing hides who pays whom from the nodes in the middle, but not the amount. The nodes at the two ends of the route can know more: your LSP sees that the payment came from you, and the node before a recipient with one private channel knows who is paid.

On-chain, by contrast, the sending address, receiving address and amount are visible to anyone reading the blockchain.

Routing Fees as Incentives

Nodes in the middle charge a fee for forwarding. It pays them for keeping bitcoin locked in channels and staying online, and it steers wallets toward cheaper routes. Each node sets a base fee per payment and a rate in parts per million (ppm) of the amount. The fee for one hop is:

fee = base fee + amount × rate ÷ 1,000,000

Lesson 4.1 prices a two-hop route with the network’s median fees: about 3 sats for 10,000 sats and about 21 sats for 100,000. Choosing your own fees as a routing node is covered in Lesson 4.8, and our lightning network fees guide goes further.

Lightning Invoices Explained

To be paid over Lightning, the recipient creates a lightning invoice: a payment request that carries everything the payer’s wallet needs to build the payment.

BOLT11 Invoices

BOLT11 is the most widely used invoice format. An invoice is a long string, starting with lnbc on Bitcoin’s main network, that contains:

  • Payment hash: the fingerprint of the secret the recipient will reveal when paid. This is what makes HTLCs work (Lesson 4.1).
  • Amount: optional. A “zero-amount” invoice lets the payer choose.
  • Expiry: how long the invoice stays valid. The specification’s default, used when the invoice doesn’t say, is one hour (BOLT 11), but wallets set their own: LND, for example, makes invoices valid for 24 hours unless told otherwise.
  • Description: a note such as “Coffee at Bitcoin Café”.
  • Routing hints: suggested last hops, needed when the recipient’s channels are private.
  • The recipient’s node identity: its public key, which tells the payer where to send. It also tells anyone who sees the invoice which node is being paid.

Invoices are usually shown as QR codes. Scan one with your lightning wallet and it reads all of this and builds the payment.

An ordinary BOLT11 invoice can only be paid once. If a second person tries to pay the same invoice, the payment fails. LND’s AMP invoices are the exception: they can be paid again and again, but only by wallets that support AMP.

BOLT12 Offers

BOLT12 is a newer format that fixes several BOLT11 limits:

  • Reusable: one offer can be paid many times, which suits a donation page or a tip jar. Behind the scenes, each payer’s wallet asks the recipient for a fresh invoice.
  • Amount left open: a reusable offer can omit the amount, so each payer chooses it when paying. An offer with a price sets the minimum to pay.
  • Better privacy: an offer can hide the recipient’s node behind “blinded paths” instead of naming it. With a blinded path, the recipient chooses the last few hops of the route and encrypts them, so the payer only learns the node where that hidden stretch begins.
  • Refunds: the format includes a way for a merchant to pay a user, for example to refund them.
  • Payer proofs: the payer can prove they were the one who requested the invoice, not just that someone paid it.

Support for BOLT12 is still spreading across wallets and node software. Core Lightning (CLN) led its development. Our guide to BOLT11 and BOLT12 compares them in more detail.

Lightning Channel Management Best Practices

If you use a wallet like Phoenix, channel management is done for you. If you run your own node, it is your job, and it comes down to three habits: keep channels useful in both directions (rebalancing), close channels that sit idle, and open channels to reliable, well-connected peers. Lesson 4.8 covers each of them for node operators, including what rebalancing costs, and our channel management masterclass goes deeper.

Common Routing Problems

Even well-run channels sometimes fail to deliver a payment. Knowing the usual causes helps you fix them quickly.

No Route Found

Your wallet couldn’t find any path to the recipient. Causes include:

  • the recipient’s node is offline or has no public channels
  • no connected path exists between your node and theirs
  • every possible route lacks capacity

Fix: open channels to well-connected nodes, or ask the recipient for a fresh invoice with routing hints.

Insufficient Liquidity

A route exists, but one or more channels on it don’t have enough money on the right side. This is common with larger payments.

Fix: try a smaller amount, use multi-path payments (MPP) to split it across routes, or try again later when balances have moved.

Channel Capacity Exceeded

The payment is bigger than a channel on the route can ever carry, whatever its balance.

Fix: split the payment with MPP, or find routes through larger channels.

Two reasons a channel can't carry a payment. Left: a 600,000-sat payment is longer than a 500,000-sat channel, so it can't pass, however the channel's balance is split. Right: a channel with enough capacity in total, but the side that has to send holds less than the payment, so the payment fails there; nodes publish their channels' capacity but not how it is split. One fix for both: split the payment into parts that take different routes (MPP).
Capacity is a ceiling; balance is where the money sits. A payment bigger than a channel can never pass through it. A payment that fits the channel can still fail if the side that has to send it holds too little.

Payment Timed Out

Your wallet tried routes for a while and stopped starting new attempts. This usually means slow or unresponsive nodes on the routes it tried. An attempt that had already left your wallet can still be on its way, though: software such as LND doesn’t cancel a payment while part of it is in flight (LND router documentation).

Fix: wait until the payment no longer shows as pending, then retry. Your wallet will usually avoid the problem node next time. If it stays pending, it is the next case.

A Payment Stuck Until Its HTLC Expires

This is a different, rarer problem. Sometimes a payment leaves your wallet but a node further along stops responding, and the payment stays “pending”. Each hop’s HTLC has a deadline set in blocks, and your funds stay locked until the payment either completes or reaches that deadline. That can take hours or days: LND accepts forwards locked for up to 2,016 blocks, about two weeks (LND sample configuration). If the deadline arrives and the HTLC still can’t be settled cleanly, the protocol requires the channel holding it to be closed on-chain (BOLT 2): a force close, with on-chain fees.

Fix: retrying does nothing here. Keep your wallet or node online and wait. Phoenix, for example, asks you to keep the phone on and open the app from time to time until the payment fails cleanly (Phoenix FAQ).

Two different problems. Payment timed out: your wallet stopped trying new routes; wait until the payment no longer shows as pending, then retry, because nothing is locked. If it stays pending, it is the other problem, stuck until its HTLC expires: the payment left your wallet, but a node further along stopped responding. Your funds stay locked, block after block, until the payment ends or reaches its deadline: hours or days, and LND allows up to 2,016 blocks, about two weeks. It then ends one of two ways: it completes, or it fails cleanly and the money returns over Lightning; or it can't settle cleanly, the channel is force-closed and the funds come back on-chain, minus on-chain fees. Retrying does nothing here: keep your wallet or node online and wait.
A timeout and a stuck payment look alike, but you handle them differently. After a timeout nothing is locked, so you retry once it no longer shows as pending. A stuck payment keeps your funds locked until it ends or its deadline passes, and retrying doesn’t help.

For more cases and step-by-step fixes, see our lightning troubleshooting guide for failed transactions.

Key Takeaways

  • A lightning channel has a fixed capacity, split between your local balance (what you can send) and the remote balance (roughly what you can receive)
  • The channel reserve, money set aside for closing fees, and payments in flight mean you can receive a little less than the remote balance suggests
  • Inbound liquidity is required to receive. A channel you fund yourself starts with none
  • Payments route through several hops with onion routing: hops in the middle usually can’t tell the sender or the recipient, but every hop sees the amount it forwards, which for a payment sent in one piece is close to the full amount. Your wallet’s LSP is the exception: it can see that a payment came from you, and with Phoenix, ACINQ also sees where it goes
  • BOLT11 invoices carry the payment hash, amount, expiry, routing hints and the recipient’s node identity, and can be paid only once (LND’s reusable AMP invoices are the exception)
  • BOLT12 offers are reusable and can hide the recipient’s node
  • A timed-out payment can be retried once it no longer shows as pending; a payment stuck until its HTLC expires can end in a force close

Frequently Asked Questions

What is the difference between inbound and outbound liquidity?

Outbound liquidity is the bitcoin on your side of your channels, the most you can send. Inbound liquidity is the bitcoin on the other side, roughly the most you can receive. A channel you open and fund yourself starts with full outbound and no inbound. As you spend, outbound turns into inbound. That’s why new nodes often can’t receive until they have spent or bought some inbound capacity.

Can I increase a channel’s capacity without closing it?

Yes, with splicing, which adds funds to or removes funds from an existing channel with one on-chain transaction. The channel keeps working while the splice confirms. Phoenix uses splicing to resize its channel automatically. Not every Lightning implementation supports splicing yet.

How do I decode a lightning invoice to see what is inside?

Most wallets show the details when you scan an invoice. On your own node, lncli decodepayreq <invoice> (LND) or lightning-cli decode <invoice> (CLN) shows every field. Online decoders exist too, but avoid pasting invoices with real payment details into third-party websites: the invoice reveals the node being paid and the amount.

Why do some of my lightning payments fail?

The usual causes are not enough liquidity along the route, the recipient being offline, an expired invoice, or a payment bigger than the channels on the path. Wallets retry other routes automatically. If failures keep happening, opening channels to better-connected nodes or using a wallet with a built-in LSP usually helps.

What happens to my funds if a routing node in the middle goes offline?

You don’t lose them, but you may wait: from a few hours to a few days, and up to about two weeks in the worst case, until the payment completes or its HTLC deadline passes. Most stuck payments then fail cleanly and the money returns over Lightning. If one can’t, a channel on the route is force-closed. That is usually the channel next to the unresponsive node. Yours closes only if that node is your direct partner, your own wallet is offline at the deadline or, rarely, your partner can’t time out its own HTLC on-chain fast enough, for example when fees spike; then your funds come back on-chain, minus on-chain fees. Keep your wallet online meanwhile. The section “A Payment Stuck Until Its HTLC Expires” above explains why.

Check Your Understanding

1. You open a 200,000-sat channel and fund it yourself. A friend tries to pay you 10,000 sats through it. What happens, and what could you do first?

Answer

The payment fails: all 200,000 sats are on your side, so there is no inbound liquidity in that channel. You could spend some sats through it first, swap some out to on-chain, ask another node to open a channel to you, or buy inbound liquidity from an LSP.

2. A routing node forwards your payment. Which of these can it see: who you are, who receives the payment, roughly how much is being paid?

Answer

It always sees the amount it forwards, which for a payment sent in one piece is close to the full amount: each hop is told the amount to pass on, the payment plus the fees still owed to the hops after it. Whether it can tell who you are or who gets paid depends on where it sits. A node in the middle of the route usually can’t, because onion routing hides both. But if it is your wallet’s LSP and your only channel, it can tell the payment came from you, and with Phoenix, ACINQ also sees the destination. Likewise, the node just before a recipient with a single private channel knows who is being paid.

3. Your wallet says “payment timed out”. A week ago another payment stayed “pending” for days. Why should you treat these two differently?

Answer

A timeout means your wallet stopped trying new routes. Once the payment no longer shows as pending, nothing is locked and you can retry. A payment that stays pending is locked in HTLCs along a route. Retrying doesn’t help: you keep your wallet online and wait until it completes or its deadline passes. If it can’t fail cleanly, a channel on the route, possibly yours, is force-closed, and any of your funds in that channel come back on-chain.

Practical guides