A Lightning channel is a two-party Bitcoin contract that lets both sides update their balances off-chain, settling back to the blockchain only when one side closes the channel. Liquidity is the amount available to move in each direction, and routing is how the network finds a path of funded channels between sender and recipient. This guide covers all three concepts with worked examples, troubleshooting playbooks, and the safety practices that matter at each wallet type. It does not cover altcoin scaling comparisons, trading strategy, or deep protocol specifications aimed at developers.
What is a Lightning channel, and how do balances work inside one?
A Lightning channel is a 2-of-2 multisig Bitcoin address that locks a fixed amount of satoshis between two peers. Once funded, the peers exchange signed balance updates off-chain at no cost and near-instant speed. The Bitcoin blockchain records only two transactions for a channel's entire life: the opening funding transaction and the closing settlement transaction.
Two terms define every channel:
Capacity is the total sats locked when the channel opens. It stays fixed until the channel closes.
Balance is how those sats split between the two peers at any moment. Every payment shifts the split.
Your outbound liquidity (local balance) determines how much you can send. Your inbound liquidity (remote balance) determines how much you can receive. Holding sats in a wallet does not guarantee you can receive sats. Receiving requires someone else's outbound liquidity pointed toward you.
Worked example: Alice and Bob
Alice opens a channel to Bob, funding it with 1,000,000 sats.
Starting state:
Channel capacity: 1,000,000 sats (fixed)
Alice outbound: 1,000,000 sats
Alice inbound: 0 sats
Alice pays Bob 600,000 sats. New state:
Alice outbound: 400,000 sats (she can send up to 400k)
Alice inbound: 600,000 sats (she can now receive up to 600k)
The capacity never changed. Only the split moved.
Three misconceptions that cost beginners time
"I have 500k sats, so I can receive 500k more."
Your inbound depends on your peers' outbound to you, not your own balance.
"Lightning money teleports."
Payments travel through real channels with real balance constraints at every hop.
"Lightning is a sidechain."
Channels are direct Bitcoin-backed contracts enforced by the Bitcoin blockchain, not a separate chain.
How does a Lightning channel open, operate, and close?
Opening a channel broadcasts an on-chain transaction that creates the 2-of-2 multisig address and locks the funds. Both peers must sign every balance update. The funding transaction typically needs 1 to 6 Bitcoin confirmations before the channel becomes active.
During normal use, peers exchange signed commitment transactions that shift the balance split. These updates happen in milliseconds and cost nothing. The blockchain never sees these intermediate states.
Closing a channel
Closing brings the final balances back on-chain through one of two paths.
Cooperative close. Both peers agree to settle. A single on-chain transaction splits the funds according to the last signed state. One confirmation, low fees, fast.
Force close. One peer broadcasts unilaterally, usually because the other is offline or unresponsive. The initiator's funds are locked behind a CSV timelock, typically 144 blocks (about 24 hours), that can extend up to 2,016 blocks (roughly two weeks) depending on channel parameters (source: Lightning Labs). Higher on-chain fees, longer wait, but honest participants recover their funds.
What is Lightning liquidity, and why do payments fail because of it?
Liquidity in the Lightning context means the sats available to move in a specific direction through your channels. It is the most common reason payments fail.
Outbound liquidity is your local balance across all channels. If you have 300,000 sats outbound total, you can send up to 300,000 sats, potentially split across multiple routes.
Inbound liquidity is the sum of your peers' local balances in channels with you. If your peers collectively hold 500,000 sats on their side, you can receive up to 500,000 sats.
Most Lightning implementations enforce a channel reserve, typically 1% of capacity, that neither side can spend. The reserve must exceed Bitcoin's dust limit (354 sats per BOLT #2) to remain enforceable on-chain (source: Lightspark). This ensures both parties keep a stake that can be claimed as penalty if either broadcasts a revoked state.
How to get inbound liquidity without jargon
Most new users face the same problem: they funded channels (outbound), but nobody funded channels to them (inbound). Three practical solutions cover most cases.
LSP-managed wallets (easiest). Wallets like Phoenix or Breez use Liquidity Service Providers that open channels to you automatically when you receive a payment. Phoenix now uses splicing instead of opening new channels, so the fee is just the on-chain mining cost of the splice transaction rather than a percentage (source: Acinq). Breez uses a similar model. The process is invisible to the user.
Someone opens a channel to you. If you run a node, other users or services can open channels in your direction. Their outbound becomes your inbound. Free for you, but requires the other party to lock funds.
Loop services. Lightning Labs' Loop lets you "loop out," sending a Lightning payment that converts to on-chain Bitcoin. This shifts your outbound to inbound. Fees typically run 0.1 to 0.5% plus base fees. Non-custodial, but requires understanding the process. Lightning Pool is a related marketplace where node operators can buy and sell channel liquidity from each other.
Rebalancing: when it matters and when to ignore it
Rebalancing moves liquidity between your own channels through circular payments. If Channel A is 90% outbound and Channel B is 90% inbound, a circular payment through the network can even them out.
When it matters: You run a routing node with many channels and some have become unusable due to extreme imbalance.
When to ignore it: You use an LSP-managed wallet. The LSP handles liquidity automatically. If you have fewer than 10 channels, manual rebalancing rarely pays for itself.
How does routing find a path for your Lightning payment?
Routing is the process of finding a multi-hop path through the network from sender to recipient where each hop has enough liquidity and acceptable fees. You do not need a direct channel with the person you pay.
Step-by-step payment flow:
Invoice generated. The recipient creates a BOLT11 invoice containing their node ID, payment amount, payment hash, and expiry.
Path discovery. Your wallet queries its view of the network graph, which includes announced channel capacities and fee policies. It selects a path where each channel appears to have enough liquidity. Because the actual balance split in each channel is private, pathfinding is probabilistic (source: Lightning Labs).
HTLC chain created. Your wallet constructs onion-encrypted layers, one per hop. Each node only sees the previous hop and the next destination, not the full path.
Forwarding. Your node sends the payment to the first hop. Each routing node verifies the conditions and forwards to the next.
Settlement or failure. If the recipient holds the preimage (the secret matching the payment hash), they reveal it. Each hop settles backward. If any hop fails, the payment rolls back and your funds return.
Key terms:
Hop: a single channel link in the path.
Route: the complete path from sender to recipient.
Running my own routing node for the past year and a half, the single biggest factor in payment success has been choosing well-connected peers at channel open time. Picking peers with high uptime and balanced channels avoids most routing failures before they start.
What are HTLCs, and why do failed payments refund automatically?
An HTLC (Hashed TimeLock Contract) is the mechanism that makes every Lightning payment conditional and refundable on failure (source: Lightning Labs).
Two locks enforce the contract:
Hashlock: the payment completes only if the recipient reveals a preimage that matches a known hash.
Timelock: if the preimage is not revealed before a deadline, the payment automatically refunds to the sender.
What this means in practice:
Payments are atomic. The entire multi-hop chain succeeds or the entire chain fails. No funds get stuck in the middle.
Failures refund automatically. If any hop fails, the timelock expires and your sats return, usually within seconds to minutes.
Onion routing preserves privacy. Each hop sees only the previous and next node, not the full path or final amount.
You do not need to understand the cryptography. The practical outcome is that failed payments come back to you.
Why do Lightning payments fail, and what should you try first?
When a Lightning payment fails, the cause falls into one of five categories:
Insufficient liquidity on a hop (most common). Some channel in the path does not have enough balance in the right direction.
Fee limits exceeded. Your wallet's fee cap is lower than what the route requires.
Node offline or unresponsive. An intermediate node is not responding, causing the payment to time out.
Timeout issues (CLTV). The cumulative timelock across hops exceeds configured limits. More hops mean higher total timeout requirements.
Max HTLC constraints. Some channels cap individual payment sizes. A 500,000 sat payment will not route through a channel with max_htlc set to 100,000 sats.
Troubleshooting order, safest to most invasive:
Verify the recipient is online and the invoice is still valid
Increase your fee limit (many wallets default too low)
Request a fresh invoice (invoices expire)
Try a smaller amount to test whether the problem is route capacity
Wait a few minutes and retry; network state changes constantly
Check your own channel balances for sufficient outbound
Try splitting the payment if your wallet supports multi-path payments (MPP)
Fall back to an on-chain transaction if Lightning repeatedly fails
How do Lightning fees work, and when do they get expensive?
Lightning fees are set per-channel by node operators and have two components:
Base fee: a fixed amount charged per forwarded payment (commonly 0 to 1,000 sats).
Proportional fee (fee rate): charged per million satoshis forwarded (expressed in ppm, parts per million). A rate of 100 ppm means 100 sats per 1,000,000 forwarded.
Worked fee calculation
Send 100,000 sats through a route with 3 hops, each charging 1,000 sat base fee plus 100 ppm:
Base fees: 3 x 1,000 = 3,000 sats
Proportional: 3 x (100,000 x 100 / 1,000,000) = 30 sats
Total: 3,030 sats (3.03%)
Send 10,000 sats through the same route:
Base fees: 3,000 sats
Proportional: 3 sats
Total: 3,003 sats (30%)
Base fees dominate small payments. Lightning is economical for medium amounts but can become expensive for tiny payments routed through multiple hops. Many modern routing nodes now set base fees to zero and rely on proportional fees alone, which helps small payments.
When fees spike
High network congestion, with many payments competing for limited channel liquidity
Poorly connected nodes that require longer, more expensive routes
Wallet fee limits set too low, causing retries through progressively more expensive paths
Reliability by payment size
Small payments (under 10,000 sats): roughly 95% success rate
Medium payments (10,000 to 500,000 sats): roughly 85 to 90% success rate
Large payments (over 1,000,000 sats): roughly 70% without MPP, higher with multi-path splitting
What wallet type should you use, and what does each require?
Your wallet type determines what you control, what you delegate, and what can go wrong.
Custodial. The provider holds your keys. They can freeze funds, see every transaction, and potentially lose your Bitcoin. Convenient, but requires complete trust. No backup needed beyond your login credentials.
LSP-managed (self-custodial). You hold your private keys and can recover funds if the LSP disappears, though recovery may involve force-closing channels with delays. The LSP opens and manages channels for you and sees your payment activity. Channel operations cost fees. Backup requirement: your seed phrase stored offline.
Self-hosted node. You control everything. No third party can freeze or observe your funds. But you handle backups, uptime, liquidity management, and Bitcoin security checklist yourself. Mistakes can mean lost funds. Backup requirement: seed phrase, channel state database, and watchtower configuration. Test recovery before committing significant funds.
Choosing based on priorities
Maximum convenience, minimal learning: LSP-managed wallet. Accept that the LSP sees your payment activity.
Maximum privacy: Self-hosted node with private (unannounced) channels. Accept the complexity and ongoing maintenance.
Balance of both: Start with an LSP-managed wallet, upgrade to a self-hosted node as you learn.
What happens when a channel closes, and what backups do you need?
Cooperative close settles with a single on-chain transaction splitting funds by the last agreed state. Available after 1 confirmation (roughly 10 minutes). Low fees.
Force close locks the initiator's funds for a delay period (typically 144 to 2,016 blocks, or 1 to 14 days). Higher fees. Triggered when a peer goes offline, a dispute is detected, or one side exits unilaterally. Honest participants always recover their funds; the delay exists to let watchtowers or the counterparty challenge a revoked state.
Safety practices
Back up your seed phrase offline before opening channels
Use a watchtower if you cannot keep your node online continuously
Keep your channel database backed up if you run a self-hosted node
Do not delete your channel database while channels are open
Do not ignore "peer offline" warnings for weeks
A force close does not mean lost funds for honest participants; it means delayed funds
Backup requirements by wallet type
Wallet type | What to back up |
|---|---|
Custodial | Login credentials only |
LSP-managed | Seed phrase (12 or 24 words), stored offline, never digitally |
Self-hosted | Seed phrase + channel.backup file + watchtower config; test recovery before significant use |
How private are Lightning payments compared to on-chain Bitcoin?
Lightning improves Bitcoin privacy over on-chain transactions, but it is not anonymous.
What Lightning hides:
Transaction amounts from the public blockchain (until channel closes)
The full payment path from intermediate nodes (onion routing)
Direct sender-recipient link for multi-hop payments
What remains visible:
Channel opens and closes are on-chain transactions, visible to anyone
Your node's public key and channel connections are visible if you announce channels
Invoice metadata (amount, description) is visible to payer and recipient
Custodial providers see everything: all payments, amounts, recipients, timing
Lightning is better characterized as "less transparent than on-chain" rather than anonymous. Running your own node with private channels and careful peer selection offers the strongest privacy within the Lightning model.
Practical playbooks: send, receive, and troubleshoot
Most payment failures come down to two issues: liquidity direction (outbound to send, inbound to receive) and route constraints (fees, hop liquidity, node availability).
Send playbook
Check outbound liquidity exceeds the payment amount
Get a valid, fresh invoice from the recipient
Set fee limit at 1 to 2% of payment amount to start
Attempt the payment
If it fails, raise fee limit to 5%, then 10%
If still failing, try 10% of the intended amount as a test
Consider MPP if your wallet supports it
Fall back to on-chain if Lightning repeatedly fails
Receive playbook
Confirm your inbound liquidity exceeds the expected amount
If inbound is low, the LSP may handle it automatically (with fees); for self-hosted, request inbound channels or loop out
Generate a fresh invoice with correct amount and reasonable expiry
Share the invoice string or QR code with the sender
Stay online until the payment arrives
If the payment fails repeatedly, confirm the sender has sufficient outbound and try a new invoice
Failure triage
Error mentions "liquidity" or "insufficient": check outbound (sending) or inbound (receiving) balance
Error mentions "no route": increase fee limit, request a new invoice, verify the recipient is online
Error mentions "timeout": the recipient may be offline, or the route is too long; retry after a few minutes
Error mentions "fee exceeded": raise your fee limit setting
Error is unclear: try a smaller test amount, wait 5 minutes, check connectivity on both sides
Advanced concepts (optional reading)
These features are useful context but not required for basic Lightning usage.
Multi-path payments (MPP). Splits a large payment across multiple routes simultaneously. If no single route can handle 1,000,000 sats, MPP might send 400,000 through one path and 600,000 through another. Most modern wallets support MPP automatically.
Splicing. Adds or removes funds from an existing channel without closing it. Want to add 500,000 sats to a 1,000,000 sat channel? Splicing creates a 1,500,000 sat channel without the cost and delay of close-and-reopen. Operational in Core Lightning since v23.08 and adopted by Phoenix wallet for dynamic channel resizing (source: Bitcoin Optech).
Trampoline routing. Delegates pathfinding to a well-connected node. Instead of computing the full route, your wallet pays a trampoline node to find the path. This reduces computation on mobile wallets and can improve privacy by hiding path details from the sender's device.
Channel factories (experimental). Would allow multiple parties to share a single on-chain funding transaction, opening many channels with one broadcast. Still in research; not widely deployed.
Frequently asked questions
What is a Lightning channel in one sentence?
A Lightning channel is a Bitcoin-backed, off-chain contract between two peers that lets them exchange unlimited balance updates without touching the blockchain until one side closes the channel. The channel's total capacity is set at open time and stays fixed; only the internal split between the two peers changes with each payment. Channel opens and closes are standard Bitcoin transactions, so the security model inherits directly from the Bitcoin base layer rather than relying on a separate consensus mechanism.
Why can I sometimes send but not receive, or the other way around?
After sending payments, your outbound decreases and your inbound increases. After receiving, the reverse happens. A channel you funded yourself starts with all outbound and zero inbound, which is why new channels can send immediately but cannot receive until the balance shifts or someone opens a channel toward you. LSP-managed wallets solve this automatically by opening inbound channels on your behalf when a payment arrives, charging a fee for the on-chain transaction involved.
Are Lightning fees always cheaper than on-chain fees?
Not always. For very small payments routed through multiple hops, base fees can add up to a higher percentage than a low-priority on-chain transaction would cost during quiet mempool periods. Lightning is consistently cheaper for medium-sized payments (roughly 10,000 to 1,000,000 sats) sent through well-connected nodes. During on-chain fee spikes from Bitcoin mempool congestion, the gap widens further in Lightning's favor.
What happens if my channel force-closes? Will I lose funds?
Honest participants do not lose funds in a force close. Your sats are locked behind a timelock (typically 1 to 14 days) while the network verifies no cheating occurred, then released to your on-chain address. You lose funds only if you broadcast an old, revoked channel state, because your counterparty can then claim your entire balance as a penalty. Keep your channel state database current and use a watchtower to prevent this scenario.
What is an HTLC, and why do failed payments come back automatically?
An HTLC (Hashed TimeLock Contract) is a conditional payment that completes only if the recipient reveals a cryptographic secret within a deadline. If any hop in the route fails or the deadline passes, the timelock expires and your sats return to your wallet automatically. This atomic design means you never risk losing funds to a routing failure; the worst outcome is a brief delay while the timelock resolves.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include BOLT #2 (channel reserve specification), Lightning Labs Builder's Guide (liquidity management, HTLC mechanics, timelocks), Bitcoin Optech topic pages (splicing), and ACINQ's Phoenix splicing update (LSP fee model changes). All facts independently verified against current documentation as of April 2026.
Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.