Your Lightning node is online, your channels are funded, and payments are routing. Then, a week later, half your channels can only receive and the other half can only send. Routing fees stop flowing because your node has nothing left to forward. This is the single most common complaint from Lightning Network operators in 2026, and it has nothing to do with your node software crashing. It is a liquidity problem, and it has a fix: rebalancing.

Lightning Labs puts it plainly in its own liquidity documentation: “As you route payments, you may find that your channels become unbalanced, meaning the local and remote balance become skewed.” That skew is not a bug. It is the predictable outcome of routing traffic that flows in one direction more than another. This tutorial walks through diagnosing imbalance, fixing it with real tools (Balance of Satoshis, Charge-LND, and Lightning Loop), and building an automated script that keeps doing it while you sleep.

Why Lightning Channels Go Unbalanced (and What It Costs You)

A Lightning channel holds two balances: your local balance (what you can send) and your remote balance (what you can receive). Every payment shifts sats from one side to the other. Route enough outbound payments through a channel and your local balance drains toward zero. Route enough inbound traffic and the opposite happens. Either extreme kills your usefulness as a routing node, because you can no longer forward in that direction.

The scale of the network makes this worth caring about. Public Lightning capacity sat at roughly 4,898 BTC across 41,080 channels and 17,438 nodes as of May 2026, according to Spark’s State of the Lightning Network research, which cites mempool.space crawl data. That is below the all-time high of 5,637 BTC recorded in mid-December 2025. Other trackers report different figures from the same period (1ML’s crawl showed a lower channel count), a reminder that public statistics only capture announced channels and vary by measurement date and crawler methodology. Spark’s capacity map also found that the ten largest nodes by channel capacity control roughly 62% of all public liquidity, with ACINQ, the liquidity provider behind Phoenix Wallet, holding close to 446 BTC across about 2,245 channels alone.

Rusty Russell, one of the original Lightning protocol developers, framed the tradeoff on the Stephan Livera podcast this way: “So, you do want to keep your channels balanced, and there was this idea that, ‘Well, what I could do is I could provide negative fees by just basically paying other people to balance the channel for me.'” That is the economic core of this whole tutorial. You either pay a small fee to rebalance proactively, or you lose routing revenue and payment reliability by doing nothing.

Unbalanced channels also create a trust problem you might not notice right away. Wallets and other routing nodes build internal reputation scores for peers based on payment success rates. A node that fails forwards constantly because it has no liquidity in the requested direction gets quietly deprioritized by pathfinding algorithms on other nodes, which means even fixing the balance later doesn’t immediately restore the routing volume you lost. The fix compounds the same way the problem does: a node that stays balanced earns steady, predictable fee income, while one that lets channels drift to the extremes sees both fewer successful routes and fewer attempts in the first place.

Prerequisites: Tools and Versions You’ll Need

This tutorial assumes you already run a Lightning node. If you haven’t reached that point yet, work through our Lightning Network node setup guide or the LND setup walkthrough first, then come back. Everything below assumes an LND-based node on Linux, though the Charge-LND and BOS steps apply almost unchanged to Umbrel, myNode, or RaspiBlitz installs.

ToolVersion used in this tutorialPurpose
LNDv0.21.4-betaCore Lightning node daemon
Lightning Terminal (litd)v0.17.6 (released Oct. 2, 2026)Dashboard, liquidity ads, Pool access
Lightning Loopv0.35.0-betaOn-chain to off-chain liquidity swaps
Poolv0.7.1-betaNon-custodial liquidity marketplace
Balance of Satoshis (BOS)latest from npmCircular rebalancing, node reporting
Charge-LNDlatest from GitHubAutomated fee-policy adjustment
Node.js18.x or newerRequired runtime for BOS
Python3.10 or newerUsed for the automation script below

Lightning Terminal v0.17.6 packages LND v0.21.4-beta, Loop v0.35.0-beta, Pool v0.7.1-beta, Taproot Assets Daemon v0.8.5, and Faraday v0.2.19-alpha as a bundle, so installing litd gets you most of this stack in one shot. You’ll still want BOS and Charge-LND installed separately since neither ships inside the Lightning Labs bundle.

You’ll also want a synced, fully operational node before touching any of the tools below. Rebalancing commands query your channel graph and routing table in real time, so a node that’s still catching up on blocks or graph sync will return incomplete or stale data, which leads to rebalance attempts that fail for reasons that have nothing to do with liquidity. Confirm sync status first:

lncli getinfo | jq '{synced_to_chain, synced_to_graph, num_active_channels}'

Both synced_to_chain and synced_to_graph need to read true before you start. If either is false, give the node more time and skip straight to Step 1 once both flip over.

How Routing Fees Actually Work (the Math Behind ppm)

Every fee number in this tutorial is expressed in parts per million, written as ppm, because that’s the unit Lightning implementations use internally and the unit every tool in this stack expects on the command line. A fee of 100 ppm means you charge 100 sats for every 1,000,000 sats you forward. On a 500,000-sat rebalance, a 142 ppm route costs 71 sats, which is exactly the number BOS reported back in Step 3’s output.

Two separate fee numbers matter here, and conflating them is a common source of confusion for anyone new to running a routing node. Your outbound fee rate, the one Charge-LND adjusts in Step 4, is what you charge other people to route through your channels. Your rebalancing cost, the one capped by --max-fee-rate in Step 3, is what you pay other nodes to route your own self-payment. The entire profitability question for a routing node boils down to whether the first number, averaged across all your channels over time, consistently beats the second.

Base fees complicate this slightly. Most nodes, including the Charge-LND policy from Step 4, set base_fee_msat to zero and rely entirely on the proportional ppm rate, since a flat per-payment fee discourages the small, frequent payments that make up a large share of Lightning traffic. If you see a node charging a non-zero base fee in the network graph, it’s usually an older configuration that hasn’t been updated to reflect how fee competition has evolved on the network.

Step 1: Map Your Current Channel Balances

Before fixing anything, find out which channels are actually broken. Run this against your LND node:

lncli listchannels | jq '.channels[] | {peer: .remote_pubkey, local: .local_balance, remote: .remote_balance, capacity: .capacity}'

Output looks something like this:

{
  "peer": "03a9d8f...e21c",
  "local": "4820000",
  "remote": "180000",
  "capacity": "5000000"
}
{
  "peer": "02f1c7b...9a04",
  "local": "95000",
  "remote": "4905000",
  "capacity": "5000000"
}

The first channel is 96% local, meaning it can send almost everything but receive almost nothing. The second is the mirror image. Neither is doing you any good as a two-way router. A channel sitting between roughly 30% and 70% local balance is generally healthy. Anything consistently outside that band is a rebalancing candidate. Note every channel like this before moving to the next step, since you’ll target them directly with BOS.

Step 2: Install Balance of Satoshis (BOS)

BOS, built by Lightning developer Alex Bosworth, is the most widely used command-line tool for manual and scripted rebalancing. Install it with npm:

npm install -g balanceofsatoshis
bos telegram --setup   # optional: wires up alerts later
bos wallets             # confirms BOS can see your node's macaroon

BOS authenticates against your node through its admin macaroon, the same credential litd and lncli use. Keep that macaroon file as locked down as you would a private key. Several 2026 incidents involving exposed Lightning macaroons, including the bug covered in our BTCPay Server macaroon exploit writeup, started with a credential file sitting somewhere it shouldn’t have been, like a world-readable Docker volume or a committed config file.

Step 3: Run Your First Circular Rebalance

Circular rebalancing sends a payment from your own node, out through the network, and back to yourself through a different channel. No on-chain transaction happens. Lightning Labs describes the technique directly: “It’s popular to periodically balance these channels, most commonly by making a payment to yourself in a way that spends your local balance from channels with high balances, to those with lower balances.” The only real cost is the routing fee paid to the intermediate hops that carry your self-payment.

Using the two channels flagged in Step 1, push liquidity from the overloaded channel into the drained one:

bos rebalance --out 03a9d8f...e21c --in 02f1c7b...9a04 --max-fee-rate 400 --avoid-high-inbound

--out names the overfunded peer you’re draining, --in names the drained peer you’re refilling, and --max-fee-rate caps the cost in parts per million (ppm) you’re willing to pay for the route. A successful run returns a report like this:

Rebalancing 500000 sats
Found route with fee: 142 ppm
Success: paid 71 sats in fees to move 500000 sats
New balance: 4320000 local / 680000 remote

That 142 ppm fee is the going rate for a route with some competition for liquidity. On a congested night it can spike well past 1,000 ppm, which is exactly why the next step automates fee limits instead of leaving them to guesswork.

If the command instead returns something like Error: unable to find route, no matching outbound channel, that usually means the drained channel you named with --in has a peer with no spare capacity anywhere else on the network to route your self-payment through. Try a smaller amount first. Rebalancing 50,000 sats succeeds far more often than rebalancing 2,000,000 sats in one shot, since smaller payments have more possible routes available at any given moment.

Step 4: Automate Fees With Charge-LND

Manual rebalancing solves today’s imbalance, not tomorrow’s. Charge-LND runs continuously and adjusts your outbound routing fees based on each channel’s current balance ratio, which discourages further draining of channels that are already low and encourages traffic through channels that need to push liquidity out. Install it from source:

git clone https://github.com/accumulator/charge-lnd.git
cd charge-lnd
pip install -r requirements.txt
cp charge-lnd.conf.example charge-lnd.conf

Edit charge-lnd.conf with a policy block that raises fees as a channel’s local balance drops, so you earn more for the sats that are getting scarce:

[default]
strategy = static
base_fee_msat = 0
fee_ppm = 100

[drain-protection]
chan.min_ratio = 0.0
chan.max_ratio = 0.3
strategy = proportional
min_fee_ppm = 300
max_fee_ppm = 1500

Run it once to test, then put it on a cron job every 30 minutes:

python3 charge-lnd.py -c charge-lnd.conf
# crontab entry:
*/30 * * * * cd /home/lnd/charge-lnd && python3 charge-lnd.py -c charge-lnd.conf

An early Lightning Network FAQ thread on BitcoinTalk described the goal behind this kind of automated balancing well: a rebalancing policy “tries to fix the liquidity cheaper than it can be ruined by transaction forwards.” In other words, your fee curve should discourage the exact traffic pattern that creates the imbalance in the first place, not just chase it after the fact.

Step 5: Move Liquidity On-Chain With Lightning Loop

Circular rebalancing only works when the rest of the network has the liquidity you need to borrow. Sometimes it doesn’t, and no amount of fee tuning fixes a channel that’s simply out of balance in a way the network can’t route around. That’s when Lightning Loop earns its place in the stack. Loop performs submarine swaps, moving value between your on-chain wallet and your channels without closing anything.

To free up inbound liquidity by moving funds from a channel back on-chain, run a Loop Out:

loop out --amt 1000000 --conf_target 12

To push on-chain funds into a channel and increase outbound capacity, run the reverse:

loop in --amt 1000000

Both directions cost an on-chain transaction fee plus a Loop service fee, so reserve this for channels that circular rebalancing genuinely can’t fix, typically ones connected to low-liquidity or poorly-connected peers. Loop v0.35.0-beta, bundled with Lightning Terminal v0.17.6, is the version this tutorial tested against.

Step 6: Monitor Everything in Lightning Terminal

Running commands by hand gets tedious fast. Lightning Terminal (litd) gives you a web dashboard over the same node, showing per-channel balance ratios, routing history, and fee performance in one view. Install and start it:

wget https://github.com/lightninglabs/lightning-terminal/releases/download/v0.17.6/lightning-terminal-linux-amd64-v0.17.6.tar.gz
tar -xzf lightning-terminal-linux-amd64-v0.17.6.tar.gz
./litd

Once running, litd’s balance view color-codes channels by ratio, so the ones you flagged manually in Step 1 become visually obvious at a glance. Check this dashboard daily for the first few weeks until you trust your automation, then drop to a weekly review once Charge-LND and your rebalancing script are proven stable.

Step 7: Tap the Pool Liquidity Marketplace (Advanced)

Pool, also bundled with litd, is a non-custodial marketplace where node operators bid for inbound or outbound channel liquidity instead of hunting for peers manually. If you’re consistently short on inbound capacity and circular rebalancing keeps failing because nobody on the network has spare liquidity to lend you, Pool lets you place a bid for a channel lease with a known capacity and duration.

pool accounts new --initial_balance 2000000 --expiry_height 900000
pool orders submit bid --amt 5000000 --max_batch_fee_rate 100 --account

Pool clears orders in batched auctions rather than instantly, so expect to wait for the next batch to execute rather than getting filled immediately. Treat it as a structural fix for chronic liquidity shortage, not a substitute for the day-to-day rebalancing covered in Steps 3 through 5.

Pool bids also compete against each other on fee rate, so a bid set too low simply sits in the order book unfilled while more aggressive bidders get matched first. Check the current clearing rate before submitting with pool orders list, which shows active orders and their fee rates, and price your bid at or slightly above the going rate if you actually want the batch to fill rather than sit open indefinitely.

Step 8: Build a Complete Rebalancing Script

Manual commands are fine for learning, but a real routing node needs something that runs unattended. Here’s a working Python script that checks every channel, flags imbalanced ones, and calls BOS to fix them within a fee ceiling:

#!/usr/bin/env python3
import json
import subprocess

MAX_FEE_PPM = 400
LOW_RATIO = 0.25
HIGH_RATIO = 0.75

def get_channels():
    raw = subprocess.check_output(["lncli", "listchannels"])
    return json.loads(raw)["channels"]

def ratio(ch):
    local = int(ch["local_balance"])
    cap = int(ch["capacity"])
    return local / cap if cap else 0

def main():
    channels = get_channels()
    drained = [c for c in channels if ratio(c) < LOW_RATIO]
    overfull = [c for c in channels if ratio(c) > HIGH_RATIO]

    for sink in drained:
        for source in overfull:
            print(f"Rebalancing {source['remote_pubkey'][:10]} -> {sink['remote_pubkey'][:10]}")
            subprocess.run([
                "bos", "rebalance",
                "--out", source["remote_pubkey"],
                "--in", sink["remote_pubkey"],
                "--max-fee-rate", str(MAX_FEE_PPM),
                "--avoid-high-inbound"
            ])

if __name__ == "__main__":
    main()

Save it as rebalance_bot.py and make it executable. It is deliberately simple: list channels, find the two extremes, call BOS, repeat. You can extend it with Slack or Telegram alerts (BOS already supports Telegram natively from Step 2) once you’ve confirmed it runs cleanly for a week.

Step 9: Add Safety Guardrails and Test on Regtest

An unattended script that moves money needs hard limits, not optimistic defaults. Add three guardrails before you trust this with real sats: a maximum fee rate per rebalance (400 ppm in the script above), a maximum number of rebalance attempts per run so a stuck loop doesn’t retry into the ground, and a daily spending cap tracked in a local file so the script refuses to run once it’s spent too much in fees for the day.

Before pointing any of this at mainnet funds, run it against a local regtest network using Polar or LND’s built-in simnet mode. Spin up two or three simulated nodes, open channels between them, deliberately skew the balances, and confirm your script detects and corrects the skew exactly as expected. Lightning Labs’ own documentation is candid about the tradeoff you’re automating around: “Balancing channels is time intensive and comes at a cost.” Testing on regtest first means you find out how expensive your assumptions are before mainnet does.

Step 10: Schedule the Script and Track Your ROI

Once regtest testing passes, schedule the script with a systemd timer instead of cron, since systemd gives you logging through journalctl for free:

# /etc/systemd/system/rebalance.timer
[Unit]
Description=Run Lightning rebalance bot every 2 hours

[Timer]
OnCalendar=*-*-* 0/2:00:00
Persistent=true

[Install]
WantedBy=timers.target

Then track whether the automation is actually worth running. Spark’s channel management research documents one node operator’s real before-and-after: spending 542 ppm on rebalancing while earning only 140 ppm in routing fees, a losing trade until the operator retuned the strategy and cut rebalancing cost to 137 ppm, flipping the math back in their favor. That’s the number to watch: total ppm spent rebalancing versus total ppm earned routing. If the first number is consistently higher than the second, your fee policy from Step 4 needs tightening, not your rebalancing frequency.

Putting the Whole System Together

At this point you have four pieces running at once, and it helps to see how they divide the work. Charge-LND runs every 30 minutes and quietly nudges fees so the network self-corrects most imbalance before you ever have to intervene. The Step 8 Python script runs on a systemd timer every two hours and handles the imbalance Charge-LND’s fee changes didn’t fully prevent, using BOS under the hood with a hard 400 ppm ceiling. Lightning Loop sits in reserve for channels where circular rebalancing keeps failing outright, typically once every few weeks rather than on a schedule. Pool sits even further in reserve, for the rare case where a channel’s liquidity problem is structural rather than something routing fixes can solve.

That layering matters because each tool costs more than the one before it. Charge-LND’s cost is opportunity cost, a few routed payments you might not win at a slightly higher fee. BOS rebalancing costs real ppm on every run. Loop costs an on-chain transaction fee on top of its service fee. Reaching for the expensive tool first, before letting the cheap one do its job, is the single fastest way to turn a profitable routing node into a break-even one.

Treat this layering as a checklist whenever a channel looks unhealthy. Ask first whether a fee adjustment alone would fix it over the next few hours. If not, try a manual or scripted circular rebalance within your fee ceiling. If that fails repeatedly, move to Loop. Only reach for Pool when the problem keeps recurring across weeks rather than days, since that’s the signal that you’re facing a structural liquidity gap rather than a temporary routing imbalance.

Common Pitfalls When Rebalancing Lightning Channels

  • Setting fee caps too high. A --max-fee-rate of 2,000 ppm or more will clear almost any route, but it can quietly eat more in fees than the channel earns back in routing revenue. Start low, watch what succeeds, and raise the ceiling only after you’ve confirmed your routing income can absorb it.
  • Rebalancing channels that don’t need it. A channel sitting at 20% local balance with a peer that never routes outbound traffic through you anyway doesn’t need fixing, it needs closing. Rebalancing a channel nobody uses just burns fees for no routing benefit.
  • Ignoring peer reliability. Routing a self-payment through an unreliable or offline hop wastes time and sometimes locks up funds in a pending HTLC until it times out. Nodes with a history of slow or failed forwards make poor intermediate hops even when they technically have the liquidity you need.
  • Running BOS and Charge-LND with conflicting fee logic. If BOS is trying to drain a channel while Charge-LND is simultaneously raising that channel’s fees to attract more inbound, the two tools fight each other and you end up paying for rebalances that get undone by your own fee policy within hours.
  • Skipping the macaroon security step. An admin macaroon with rebalancing permissions is as sensitive as a hot wallet key, so treat the file accordingly. Store it outside of version control, outside of world-readable directories, and outside of any container image you might push to a public registry.
  • Over-automating before you understand manual behavior. Running the Step 8 script before you’ve watched a handful of manual bos rebalance calls succeed and fail means you won’t recognize when the automation starts misbehaving, since you have no baseline for what normal output even looks like.
  • Forgetting that rebalancing fees compound with on-chain fees. If you lean on Lightning Loop too often instead of reserving it for channels circular rebalancing genuinely can’t fix, the on-chain fee from every swap adds up fast during periods of high mempool congestion.

Troubleshooting Guide

  • “No route found” from bos rebalance. The network currently lacks a path with enough liquidity between your chosen channels at the amount and fee ceiling you specified. Lower the amount first, since smaller payments route far more easily, and only raise the fee ceiling if a smaller amount still fails.
  • Rebalance succeeds but fees are higher than expected. Check whether you set --avoid-high-inbound. Without it, BOS may route through channels that are themselves imbalanced, inflating the fee because those intermediate hops charge a premium to move liquidity they’re also short on.
  • Charge-LND isn’t updating fees. Confirm the cron job is actually running with grep CRON /var/log/syslog, and check that your macaroon path in the config points to a readable file. A silently failing cron job is the most common reason a fee policy looks configured correctly but never actually applies.
  • Loop Out stuck “pending.” This is normal while waiting for on-chain confirmations, especially during periods of high mempool congestion when your chosen conf_target pushes the transaction toward a lower fee tier. Check progress with loop swapinfo rather than resubmitting the swap, which would just create a second, redundant transaction.
  • BOS can’t connect to the node. Verify the macaroon and TLS cert paths in ~/.bos/config.json match your actual LND data directory, especially after an OS or disk migration where paths commonly change.
  • Script keeps rebalancing the same pair in a loop. Add a cooldown timer per channel pair in your automation so it doesn’t retry a route that just failed moments ago, since repeated immediate retries against the same failed route rarely succeed and just waste time.
  • Pool order never fills. Batch auctions clear on a schedule, not instantly. Check pool orders list to confirm your bid’s fee rate is competitive with the current batch, and remember that a bid priced below the market clearing rate can sit open indefinitely without ever executing.
  • Channel balance looks wrong after a force close. Force closes lock funds until the timelock expires, which can take anywhere from hours to days depending on the channel’s configured CSV delay. Use lncli pendingchannels to confirm what’s actually recoverable versus what’s temporarily frozen.
  • litd dashboard shows stale data. Restart litd after any LND restart, since the two processes need to resync their gRPC connection and litd won’t always detect a backend restart automatically.
  • Charge-LND and manual BOS runs disagree on a channel’s health. This usually means the balance ratio thresholds in your Charge-LND config don’t match the thresholds you’re using manually in Step 1. Align both to the same 30%/70% band so the two tools agree on what counts as imbalanced.

Advanced Tips for High-Volume Routing Nodes

Once the basics run reliably, a few refinements separate casual routing nodes from ones that consistently turn a profit. First, segment your fee policy by peer type rather than using one flat rule. Large, well-connected peers like ACINQ can usually absorb tighter fee margins because they route high volume, while small or rarely-active peers justify higher margins since each rebalance against them is more expensive per sat moved.

Second, if you’re running Taproot Assets alongside standard Lightning channels, keep rebalancing logic for asset channels separate from your BTC channels, since Taproot Assets Daemon v0.8.5 handles liquidity accounting differently and mixing the two in one script invites bugs. Third, watch for upstream security patches on whichever implementation you run. Several 2026 fixes across LDK, Core Lightning, and Eclair, detailed in our Lightning Network security patch roundup, landed within days of each other, and a node running outdated software is a worse risk than any rebalancing fee. CLN operators specifically should also check the lockdown period covered in our Core Lightning lockdown report before assuming automated rebalancing will behave identically across implementations.

Finally, revisit your fee curve every month rather than setting it once. Network capacity moved from a December 2025 peak of 5,637 BTC down toward roughly 4,898 BTC by May 2026, and liquidity conditions that justified a given fee ppm six months ago may no longer apply.

It also helps to think about peer selection as a rebalancing strategy in its own right, not just a channel-opening decision you made once and forgot about. A channel to a well-connected hub like ACINQ rebalances easily because the network has deep liquidity flowing in and out of it constantly, which means your circular payments almost always find a route. A channel to a small, rarely-online hobbyist node rebalances poorly no matter how well you tune Charge-LND, simply because there isn’t enough surrounding liquidity for BOS to borrow from. If a specific channel consistently resists every rebalancing technique in this tutorial, the underlying problem may be the peer you chose rather than your configuration.

Rebalancing Tool Comparison

ToolBest forCost modelAutomation level
Balance of SatoshisManual and scripted circular rebalancingRouting fees only (ppm)Manual or scripted via cron/systemd
Charge-LNDOngoing fee-policy automationNo direct cost, shapes routing revenue indirectlyFully automated via cron
Lightning LoopFixing channels circular rebalancing can’t reachOn-chain fee plus Loop service feeManual, triggered on demand
PoolStructural inbound/outbound liquidity shortageBatch auction clearing feeManual bidding, batch-cleared

Frequently Asked Questions

How often should I rebalance my Lightning channels?

There’s no fixed interval that works for every node. A small node with a handful of channels might only need a manual check once a week, while an active routing node pushing meaningful volume benefits from the Step 10 systemd timer running every one to two hours. Watch the ratio data from Step 1 rather than a calendar.

Is circular rebalancing safe?

Yes, in the sense that it’s a standard HTLC payment like any other Lightning transaction, with the same atomic success-or-refund guarantee. The risk isn’t security, it’s cost. A poorly capped rebalance can pay more in routing fees than the liquidity shift is worth.

Do I need Lightning Loop if I already use BOS?

Not always. BOS and Charge-LND handle the majority of day-to-day rebalancing without touching the blockchain. Reach for Loop specifically when circular rebalancing fails repeatedly because the network simply doesn’t have a route with enough spare liquidity, which tends to happen on isolated or low-connectivity channels.

What’s a reasonable max fee rate for rebalancing?

It depends entirely on what you earn routing through the channel you’re fixing. Spark’s documented case study showed a node operator paying 542 ppm to rebalance while earning only 140 ppm routing, a losing setup corrected down to 137 ppm. Start conservative, around 300 to 500 ppm, and adjust based on your own routing fee income.

Can rebalancing fail and lose my funds?

No. Lightning payments, including self-payments used for circular rebalancing, either complete fully or roll back fully thanks to the underlying HTLC mechanism. A failed rebalance wastes time and, in rare cases, briefly locks liquidity in a pending HTLC until it times out, but it does not result in lost sats beyond the routing fee for whichever hops the payment actually traversed.

Does Charge-LND work with Core Lightning instead of LND?

Charge-LND, as the name implies, is built specifically against LND’s gRPC API. CLN operators looking for equivalent automated fee adjustment should look at CLN-native plugins instead, and should also review the recent lockdown and patch history for their implementation before relying on any automation layer.

Why do different sources report different Lightning Network capacity numbers?

Public capacity figures only count announced channels, and different crawlers, including mempool.space, 1ML, and Spark, sample the network at different times with different node coverage. Treat any single capacity figure as a dated snapshot rather than a constant, and always check the measurement date before citing it.

Should I rebalance before or after adjusting my fee policy?

Fix the fee policy first. If your Charge-LND configuration from Step 4 already discourages the traffic pattern that causes imbalance, you’ll need to run manual or scripted rebalances far less often, which saves you the routing fees that circular rebalancing costs.

What happens if I never rebalance at all?

Nothing catastrophic happens to your funds, but your usefulness as a routing node declines steadily. Channels drift toward one extreme or the other as traffic flows through them, and once a channel is fully drained in one direction, it can only route in the other direction until something, whether a payment you receive, a payment you send, or a manual rebalance, shifts the balance back. For a node that’s purely used for personal spending and receiving rather than routing fee income, this may not matter much. For a node trying to earn routing fees, it means steadily shrinking usefulness over time.

Can I rebalance a channel that’s part of a Taproot Assets setup?

Standard BTC-denominated rebalancing tools like BOS and Charge-LND work on the base Lightning layer and don’t natively understand Taproot Assets balances layered on top of a channel. If you’re running Taproot Assets Daemon v0.8.5 alongside regular channels, manage asset-channel liquidity separately through Taproot Assets’ own tooling rather than assuming the BOS and Charge-LND workflow in this tutorial applies identically to asset balances.