A routing node on the Lightning Network has a problem that has plagued it since the network existed: money flows in one direction, channel empties, and no more payments can be routed through it. For years, the fix was costly. Either pay to circular-rebalance the channel (a payment to yourself that costs actual sats), or move your sats on-chain, wait for confirmation, and open a new channel. Core Lightning v26.04, released today, offers a third option that is elegantly perverse: pay people to use your channel.
Negative routing fees—the named feature of today's Core Lightning release, tagged April 20, 2026—let a node set a channel fee rate to a negative value. When a sender looks for a route, the algorithm sees a channel that actually gives money back. The incentive is immediate: route through this channel, and the payment cost you less. From the node operator's perspective, the liquidity problem solves itself. Payments start flowing in the opposite direction, rebalancing the channel without anyone spending sats on circular rebalancing or waiting for an on-chain transaction.
This is not new theory. The Lightning Network white paper, published in 2015, mentioned this exact mechanism in a single sentence at the end of its fees section—a suggestion that negative fees could encourage routing on certain channels. It has taken eleven years and the maturation of the entire Lightning stack to make it real. The reason is not technical complexity but coordination complexity. Negative fees require nodes to gossip channel updates more frequently, require routing algorithms to handle negative values without breaking, and require the entire network to trust that fee updates are recent enough to be valid. Before today, only experimental flag holders could use them. Now it is a named, production-grade feature in the most widely deployed Lightning implementation.
The release comes at a moment when the network is reshaping its fee infrastructure more broadly. LND v0.21.0-beta.rc1, released April 17, completed the removal of older routing endpoints that had been deprecated since v0.19.0, forcing applications to migrate to new APIs that handle routing more explicitly. The base layer is also tightening: Bitcoin Core v31.0, released April 15, shipped a cluster mempool redesign and defaulted Tor and I2P broadcast, meaning Lightning nodes can rely on a more predictable mempool and better privacy. The timing matters. On-chain fees are currently 1 to 2 sat/vB—ultra-low—which means Lightning's fee advantage is less about absolute cost savings and more about user experience and payment reliability. If negative fees increase payment success rates by keeping channels balanced, they become a value proposition even when on-chain is cheap.
The problem negative fees solve is real. If all your inbound liquidity depletes because payments consistently flow through your channel in one direction, you cannot route any more. Operators who face this choose between three paths: buy more liquidity (pay someone else to rebalance), rebalance themselves (spend sats on a circular payment), or reduce outbound fees to discourage inbound routing. None are ideal. Negative fees flip the economics: instead of discouraging inbound routing, you incentivize outbound routing in the channels that need it. The liquidity problem becomes the routing algorithm's problem to solve, not the operator's. But this introduces a new failure mode that the brief names clearly: if a node's channel graph is stale and it routes based on an outdated fee, the payment fails because the sender did not account for the actual cost. Gossip propagation lag, which was an acceptable annoyance when fees were positive, now becomes a reliability issue. Every time a node changes its fee policy, it broadcasts a message. With negative fees, nodes will broadcast more frequently—at least twice per channel lifecycle as they enable the discount and then update it back to positive. More gossip means more bandwidth consumed by every node on the network.
Who benefits? Operators of nodes in positions of natural inbound traffic—regional hubs, exchange connectors, major routing nodes—benefit immediately. They can set negative fees on depleting channels and let the network rebalance itself, reducing operational overhead. Users benefit indirectly if more channels stay balanced, which increases route success rates. Who does not benefit? Nodes that are already in equilibrium gain nothing and may face more gossip overhead. Small nodes that do not have the leverage to set fee policy will not use this feature. And the network as a whole trades simplicity for complexity—it now has to keep fee updates synchronized across a much more dynamic landscape. The risk is that negative fees become a tool for larger nodes to optimize their positions further, widening the gap between sophisticated operators and passive participants. The gossip overhead is real, too. Every node that receives a channel update about a negative fee must validate it, store it, and potentially recompute routes. For a network already running at scale, this is not free.
Here is what actually matters: negative fees are a signal that Lightning is moving from a "do your best" network to an economically optimized one. The feature itself is sound—it automates something that was already possible but expensive. What changes the game is that this is now the default behavior for a major implementation, not an experiment. When LND ships negative fees in production (they are working on it), and when the broader network treats them as standard, the fee landscape becomes fundamentally more dynamic. Payment reliability will depend not just on knowing routes exist, but on knowing whether the fees advertised are fresh. This creates a new kind of channel-state fragility. Nodes that lag on updates become unreliable. Nodes that update too aggressively flood the network with gossip. The equilibrium point is somewhere in between, but finding it will require real operational discipline. I expect the first six months of negative-fee deployment will surface edge cases that force either a gossip protocol upgrade or a shift back toward less frequent updates. Watch for complaints about payment failures that trace back to stale channel states.
What to watch: First, whether payment failure rates increase in the weeks after this release as stale fee data causes route-finding to miscalculate. Second, how quickly LND moves negative fees out of beta and into a stable release—that is when the network effect becomes real. Third, whether gossip bandwidth consumption on a typical Lightning node increases measurably within 30 days. If it does, that is not a failure, but it means nodes will have to trade off between supporting dynamic fees and keeping resource consumption flat. That trade-off will shape how many operators actually enable negative fees.