Treat this as a capital-allocation system, not a “most-connected peers” contest.
1. Measure the real P&L per channel Every day calculate: net = routing fees + liquidity-lease income − circular-rebalance fees − swap fees − open/close chain fees − estimated capital cost. Track sats forwarded, earned ppm, failed HTLCs, uptime, local-balance ratio and net sats per deployed BTC. Volume without net profit is noise.
2. Select routes from your own flow data The public graph cannot reveal private channels or actual balances. Use it only to shortlist reliable, complementary peers: one side that tends to supply inbound flow and another that users actually pay toward. Avoid two highly connected peers that already share many cheap routes. Open a limited canary channel, observe 30–45 days, then enlarge only if it produces repeatable net revenue.
3. Use a guarded fee controller Run every 30–60 minutes with a 6–12 hour cooldown:
local balance >70%: lower outbound ppm gradually (10–15%) to attract flow;
local balance <30%: raise ppm (15–25%) and optionally reduce max HTLC;
between 30–70%: change fees only when the EMA of demand/failed HTLCs justifies it. Never run two fee bots simultaneously. For LND, use either LiT Autofees or a policy tool such as charge-lnd; LiT recommends starting high so the learner can lower prices safely: https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/autofees https://github.com/accumulator/charge-lnd
4. Rebalance only when the trade is profitable Do not target 50/50 blindly. Before a circular rebalance or swap, require: all-in rebalance ppm < expected routing ppm × expected number of future turns. Set a daily/monthly liquidity budget and stop automatically at the cap. Autoloop can enforce per-channel/peer thresholds and budgets; run its suggestion/dry-run behavior first: https://docs.lightning.engineering/lightning-network-tools/loop/autoloop LiquidOps is useful for balance/inactivity alerts and bounded auto-swaps: https://docs.bolt.observer/readme/liquidops
5. Acquire liquidity deliberately Routing needs usable inbound and outbound capacity, not merely nominal capacity. Loop moves liquidity between on-chain and Lightning; Pool can buy or sell inbound leases. Include every fee in the P&L: https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/channel-liquidity If a channel repeatedly drains in one direction, that is a pricing signal: raise the scarce direction’s fee before paying to rebalance it.
6. Operational rules SSD, UPS, monitoring, tested backups, watchtower, and near-100% uptime. Batch channel opens when the mempool is cheap. After the trial window, close or resize channels that have no settled forwards, persistent failures, or negative net P&L—but wait for low chain fees.
The winning loop is: measure → price → rebalance within budget → prune → redeploy. Profitable means net sats after every liquidity and chain cost, not a pretty forwarding chart.
Treat this as a capital-allocation system, not a “most-connected peers” contest.
1. Measure the real P&L per channel
Every day calculate:
net = routing fees + liquidity-lease income − circular-rebalance fees − swap fees − open/close chain fees − estimated capital cost.
Track sats forwarded, earned ppm, failed HTLCs, uptime, local-balance ratio and net sats per deployed BTC. Volume without net profit is noise.
2. Select routes from your own flow data
The public graph cannot reveal private channels or actual balances. Use it only to shortlist reliable, complementary peers: one side that tends to supply inbound flow and another that users actually pay toward. Avoid two highly connected peers that already share many cheap routes. Open a limited canary channel, observe 30–45 days, then enlarge only if it produces repeatable net revenue.
3. Use a guarded fee controller
Run every 30–60 minutes with a 6–12 hour cooldown:
Never run two fee bots simultaneously. For LND, use either LiT Autofees or a policy tool such as charge-lnd; LiT recommends starting high so the learner can lower prices safely:
https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/autofees
https://github.com/accumulator/charge-lnd
4. Rebalance only when the trade is profitable
Do not target 50/50 blindly. Before a circular rebalance or swap, require:
all-in rebalance ppm < expected routing ppm × expected number of future turns.
Set a daily/monthly liquidity budget and stop automatically at the cap. Autoloop can enforce per-channel/peer thresholds and budgets; run its suggestion/dry-run behavior first:
https://docs.lightning.engineering/lightning-network-tools/loop/autoloop
LiquidOps is useful for balance/inactivity alerts and bounded auto-swaps:
https://docs.bolt.observer/readme/liquidops
5. Acquire liquidity deliberately
Routing needs usable inbound and outbound capacity, not merely nominal capacity. Loop moves liquidity between on-chain and Lightning; Pool can buy or sell inbound leases. Include every fee in the P&L:
https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/channel-liquidity
If a channel repeatedly drains in one direction, that is a pricing signal: raise the scarce direction’s fee before paying to rebalance it.
6. Operational rules
SSD, UPS, monitoring, tested backups, watchtower, and near-100% uptime. Batch channel opens when the mempool is cheap. After the trial window, close or resize channels that have no settled forwards, persistent failures, or negative net P&L—but wait for low chain fees.
The winning loop is: measure → price → rebalance within budget → prune → redeploy. Profitable means net sats after every liquidity and chain cost, not a pretty forwarding chart.