Three days after Core Lightning shipped v26.04, Blockstream's QA team confirmed a protocol correctness bug in the negative routing fee logic. By April 25, the hotfix was live as v26.04.1. For node operators, this was not a routine maintenance release — it was a forced choice between upgrading or running non-compliant code on a payment network.
Core Lightning is the spec-focused Lightning Network implementation maintained by Blockstream. Negative routing fees were the headline feature of v26.04: the ability for a node operator to offer a discount (a negative fee) to push liquidity in a desired direction. In theory, this lets operators rebalance channels cheaply without closing them and settling on-chain. In practice, if the fee calculation is wrong, the node routes payments incorrectly or behaves out of spec with other implementations like LND or Eclair. Payment failures, liquidity misallocation, and economic losses follow.
The v26.04 release shipped with more than just negative fees. It included new splice commands to add and remove funds from channels without closing them, the ability to cross-splice between two channels in a single transaction, a `xpay` command with payer notes, and improvements to the `askrene` pathfinding algorithm. But within days, bugs in the negative routing fee implementation surfaced. The GitHub issues tracker shows multiple reproductions confirmed by Blockstream's team starting April 22. Three days later, v26.04.1 shipped to patch the correctness issues. For operators, the timeline was tight and the choice was immediate: upgrade or run broken code.
What made this particularly urgent was the on-chain fee environment. Bitcoin was processing transactions at 2 sat/vB — the lowest fee tier across all confirmation windows. At that price, closing and reopening a channel to work around the bug would have cost hundreds of thousands of satoshis in miner fees. Node operators had almost no economic escape route. A software patch was the only practical solution. The low-fee environment that usually benefits the Bitcoin network created a dependency: operators had to trust that Blockstream would fix the bug fast, and they had to trust that the fix was correct the first time.
Protocol correctness bugs in one Lightning implementation have a history of exposing edge-case incompatibilities across the entire network. If Core Lightning's fee calculation was wrong, it could cause LND or Eclair nodes to fail to route through CLN nodes, or to route incorrectly. The more node operators running v26.04 without the hotfix, the more payment failures propagated across the network. Operators who upgraded immediately benefited from correct protocol behavior. Those who waited or missed the announcement ran the risk of routing failures, liquidity getting stuck, or payments failing silently. Blockstream, as the maintainer, took the reputational hit for shipping a bug, though the speed of the fix — within days — suggests good internal QA and a tight release process.
The real story here is not that a bug was found and fixed. It is that negative routing fees, as a feature, are fragile enough that they broke the protocol contract within days of shipping. The feature is interesting: it is a market-based tool that could reshape how Lightning nodes manage liquidity. But the incident reveals that neither Blockstream's testing nor the broader Lightning ecosystem's testing of new features is tight enough to catch protocol correctness bugs before they reach mainnet. A node operator running v26.04 who did not upgrade for a week was, without knowing it, participating in a network-wide correctness test. That is not a feature of a mature protocol. It is a symptom of complexity outpacing testing discipline.
Watch the GitHub issues tracker for any remaining `26.04 bug`-tagged open issues after v26.04.1 ships. If the hotfix is incomplete, follow-on patches will follow, and the reliability question deepens. Watch Umbrel, Start9, and Raspiblitz package updates — home node operators using consumer dashboards will not get the fix until their app stores push v26.04.1, extending the window of non-compliant nodes on the network. Watch the Lightning-dev mailing list for any reports of cross-implementation payment failures in the days after the hotfix; those would indicate that the bug exposed deeper interoperability gaps. Finally, watch for adoption metrics on negative routing fees once v26.04.1 stabilizes. If operators actually use the feature and it works, it will reshape Lightning's liquidity economics. If adoption stays flat, operators may have lost confidence in Blockstream's testing process.