Why Some Lightning Network Nodes Earn Negative Routing Revenue After Accounting for Channel Costs

You open a few channels, set a fee rate, and watch the dashboard. A green number climbs slowly in the corner of your node management interface, and for a while that feels like progress. Then, six months in, you run the actual accounting: fees earned in one column, everything else in another. The green number is real. It's just not the whole ledger.

This outcome isn't rare. It is, by any honest reading of how the network behaves, the majority experience for small and mid-sized operators who treat routing as a passive income stream. Understanding why requires looking at the full cost structure, not just the fee line.

The On-Chain Tax You're Already Paying

Every Lightning channel is a Bitcoin transaction. Opening one costs an on-chain fee. Closing one costs another. Those two fees are sunk costs your routing revenue has to outrun before you've cleared a single satoshi of net profit.

Put real numbers on it. Suppose on-chain fees at open and close average 3,000 satoshis combined per channel, a conservative figure during moderate mempool congestion. You allocate 1 million satoshis of liquidity to that channel. Your base fee is 1 sat per payment and your fee rate is 100 parts per million. A typical small payment routed through you is 50,000 satoshis, earning you 6 satoshis (1 base plus 5 ppm). To recover only the open-and-close cost, you need 500 successfully routed payments through that single channel. Not profit. Just break-even on the cost of existing.

If that channel routes two payments a week and you close it after a year, you've routed roughly 104 payments and earned about 624 satoshis. You spent 3,000 to get there. Net: negative 2,376 satoshis.

Every channel you open starts life in a hole.

Liquidity Rebalancing: The Hidden Second Bill

Channels don't stay balanced. Payments flow in one direction until your outbound liquidity drains to zero, at which point the channel can't route anything. So you rebalance: either by sending a circular payment through the network (paying fees to other nodes) or by using a submarine swap service to push liquidity in from on-chain funds.

Both cost money. Circular rebalancing typically runs between 50 and 500 ppm depending on path and market conditions. Submarine swaps add a service fee on top of the on-chain transaction cost.

Consider two operators, Marcus and Priya, who open identical 2-million-satoshi channels to the same well-connected hub. Marcus routes mostly in one direction, draining his outbound balance every two weeks, and rebalances via circular payments at an average cost of 200 ppm per sat moved. Over a year he rebalances roughly 24 times, moving about 1 million sats each time: 4,800,000 satoshis in rebalancing fees paid out against routing revenue of 3,100,000 satoshis. Underwater by 1.7 million sats before open-and-close costs even enter the picture.

Priya runs the same channel, same fee schedule. It happens to sit on a bidirectional corridor between two active merchants. Traffic flows both ways naturally. She rebalances twice the whole year.

Same channel. Radically different outcome.

Network topology matters far more than the fee rate you set. That isn't a soft observation about strategy; it is the determining variable, and operators who treat fee-setting as their primary lever are working on the wrong problem.

Why Low Fees Don't Fix This

The instinct when routing revenue disappoints is to cut fees. Competitive rates attract volume. Sometimes true. The math, though, turns against you quickly.

Drop your fee rate to 10 ppm to attract volume, and each 50,000-satoshi payment earns you 1.5 satoshis instead of 6. You now need 2,000 routed payments through a single channel just to recover that 3,000-satoshi open-and-close cost. Your rebalancing costs haven't moved, because those are set by other nodes' market rates, not yours.

There is a floor below which cutting fees accelerates the loss rather than reversing it. The routing fee market is nothing like an e-commerce price war where margin compression can be rescued by volume. Your costs are largely fixed per channel; your revenue scales with actual payment flow, which you cannot fully control. Think of it less like a price dial and more like a fixed-cost manufacturing line running at 30% capacity: cheaper output per unit doesn't help if the line is half-idle regardless.

Are you above 85% channel uptime and still losing money on net? The fee rate is almost certainly not your problem.

What Operators Actually Get Wrong

The most common mistake is measuring routing revenue without subtracting rebalancing costs. Most node dashboards show total fees earned in a pleasing green number. They do not subtract what you paid in circular rebalancing fees, because those appear as outgoing payments rather than costs in a straightforward accounting view. The presentation is not deceptive by design; it is simply incomplete, and operators who don't look past it are operating on a fiction.

Run the real calculation: fees earned, minus rebalancing fees paid, minus on-chain fees for opens and closes, divided by capital locked. That is your actual return on locked liquidity. For many nodes it is negative. For some it is deeply negative.

The second mistake is treating locked capital as free. A million satoshis sitting in a Lightning channel is a million satoshis not deployed elsewhere. The opportunity cost is real, even when it doesn't appear as a line-item loss on any dashboard.

Third: opening too many small channels. A 200,000-satoshi channel carries roughly the same fixed open-and-close cost as a 2,000,000-satoshi one, at one-tenth the capacity to generate fees before rebalancing is required. Small channels are expensive per unit of useful liquidity, and stacking several of them compounds the problem rather than diversifying it.

The Operators Who Do Come Out Ahead

Routing profitability isn't impossible. It is just not passive.

Operators who earn positive net routing revenue tend to share a few traits. They have mapped their node onto genuinely high-traffic corridors connecting large exchanges, active merchants, or wallets with real, recurring payment flow. They have sized channels large enough that fixed costs represent a small fraction of total capacity. They monitor liquidity ratios actively and rebalance surgically rather than on a schedule. They close underperforming channels rather than leaving them open as dormant cost centers.

Lightning routing is less like collecting rent and more like running a small logistics desk: thin margins, constant attention, returns accruing to whoever understands their actual cost structure.

The nodes losing money aren't necessarily misconfigured. They're operating under an accounting illusion, counting the green number while the unlabeled red ones accumulate quietly in the background. The routing strategy is a second-order question. Fix the accounting first, and the strategy either becomes obvious or the whole exercise gets correctly abandoned.