Over the past 90 days, the Bitcoin Lightning Network's public channel capacity has contracted by roughly 2,400 BTC on a net basis, even as the raw count of public channels ticked modestly higher. More channels. Less capital. That divergence is not statistical noise.
I lead a quant trading desk, and my team treats Lightning less like a payments revolution and more like a directed liquidity graph with measurable failure modes. Capacity up on channel count while capacity down on capital tells a specific story: the network is absorbing dust. Small, low-value channels proliferate at the edges while the edges that route meaningful value are drained and abandoned.
That is the signature of a system that has stopped growing and started fragmenting.
The crypto commentariat oscillates between two positions — "Lightning is the future of money" and "Lightning is dead." Both camps are reading the wrong ledger. The network is neither. It is a structurally constrained settlement layer optimized, by its own mathematics, for a use case far narrower than its marketing, and the reason has almost nothing to do with adoption and everything to do with the immutable logic of directional liquidity.
Start with the base layer, because Lightning inherits every one of its constraints. Bitcoin's ten-minute block interval and fixed block weight are not bugs awaiting a patch. They are a settlement cadence. Lightning nets balances between two parties off-chain and touches L1 only to open and close channels. Two counterparties, one on-chain footprint. On paper, elegant settlement compression.
It is also directional, and that is the part the marketing loses.
A Lightning channel is a 2-of-2 multisignature UTXO holding an asymmetric balance. Fund a channel with 1 BTC on one side and zero on the other, and every sat can flow in exactly one direction — from the funded side to the unfunded side — until someone rebalances. The moment the unfunded party wants to send value back, or route a payment onward through the funded side, the edge has no outbound liquidity.
Lightning is not a payment network. It is a directed graph of finite liquidity budgets, and every edge runs dry in one direction eventually.
Before the rhetoric, the mechanics. A Lightning payment moves through a chain of hash time-locked contracts. The sender generates a preimage, hashes it, and locks funds to that hash along the route. Each hop posts an outgoing HTLC to the next hop and an incoming HTLC from the previous hop, setting the outgoing timeout longer than the incoming one so the intermediary is never exposed. The final recipient, holding the preimage, unlocks the entire chain by revealing it, and each hop settles backward in turn.
This construction is sound. It is also greedy in capital. Every hop along the route must lock real balance for the duration of the round trip, and the round trip is bounded by the slowest link — a Bitcoin block time that does not care how urgent your payment is.
When I audited first-generation Lightning wallet implementations in the late 2010s, the routing heuristics shared one baked-in assumption: liquidity would self-balance. The theory was tidy. Routing fees reward node operators, node operators rebalance to capture fees, the graph converges to equilibrium. I flagged it as fragile at the time. The assumption held for roughly eighteen months. It has been degrading ever since.
The trajectory tells the story better than any single snapshot. The 2018 to 2021 period was the build-out phase, when capacity grew in a near-straight line and every open channel looked like progress. The 2022 to 2023 period was the reality-check phase, when growth flattened and the composition of channels started to matter more than the count. The period since has been the sorting phase, where capital accumulates into nodes that can afford the overhead and bleeds out of everyone else. That arc is not a market cycle. It is a structure revealing itself.
The arithmetic that breaks Lightning fits on an index card. Routing fees typically run in the range of a few parts per million per hop, occasionally higher on scarce routes. A well-capitalized node forwarding substantial volume might clear a low-single-digit annualized return on deployed capital in a good year. That is the revenue side.
Now the cost side. Rebalancing a drained channel — restoring liquidity in the direction you want to sell — means either executing a circular payment that loops value back through the graph or executing a submarine swap that pushes capital to L1 and back. Both consume on-chain fees. Both expose you to swap spreads and to the settlement latency of Bitcoin blocks. The cost of a single rebalancing event commonly exceeds the fees that channel earned over the preceding month.
The result is structural negative carry: forwarding capital earns basis points annually, while restoring its directional capacity costs percent-level spreads per event. Rational operators do not rebalance. They abandon.
That is the mechanism behind the channel-count-up, capacity-down divergence. Nobody deliberately builds dead edges. But under negative carry, every operator's individually rational move is to let a channel drain in one direction, stop routing on it, and open a fresh one. Across thousands of operators, that behavior accumulates into a graph littered with unbalanced, unprofitable edges that still count as channels — inflating the headline number while the routable capacity underneath it contracts.
I have watched this on live books. When the cost of liquidity exceeds the fee it earns, the liquidity does not reprice. It exits.
To be concrete about what my desk actually tracks: over a rolling 30-day window I classify public channels by size, measure the share of each channel's balance sitting idle, and log open-versus-close events net of on-chain fees. The pattern is consistent. Small channels open and close at high frequency and route almost nothing of consequence. Large channels rarely churn, and when they do, the churn is a capital reallocation toward the nodes already holding the most liquidity. The distribution is not flattening out. It is steepening. When I run the same classification across a longer horizon, the slope is unmistakable: the network is not converging to a well-connected mesh, it is assembling a few well-capitalized hubs surrounded by a decaying fringe.
Probe the network — send small test payments along candidate routes and measure where they break — and you get a distribution that has been remarkably stable for years. A meaningful share of attempted payments fail on the first route and require retries, and the failure rate climbs with payment size.
The reason the number refuses to improve is structural.
Routing failures are not a bug to be fixed. They are the equilibrium of a network where most edges are unbalanced and most nodes will not pay to fix them.
When a payment fails mid-route, the failure is ambiguous. The HTLC carrying the payment can fail because a node lacks outbound liquidity, because a node is offline, because the offered fee was too low for some hop, or because a peer actively rejected it. From the sender's seat, all four look identical. The routing algorithm cannot diagnose which, so it guesses, retries another path, and burns latency. Each retry resets the clock on an already slow settlement.
Multi-path payments were supposed to solve this by splitting a large payment across several routes simultaneously. On paper, splitting raises the probability that at least one path has enough liquidity. In practice, splitting multiplies the number of hops involved, multiplies the number of edges that must succeed at the same instant, and raises total fees because each fragment pays the per-hop premium.
I have run the numbers on real flows. A payment that succeeds as a single route 70 percent of the time does not become a 95-percent success rate when split five ways. It frequently drops, because you have converted one probabilistic event into five correlated ones competing for the same scarce liquidity. The fragments are not independent; they are drawing from the same depleted pool, which is the exact scenario that made single-route failure likely in the first place.
Every in-flight HTLC holds capital hostage along its entire path until it settles or times out. The default time-lock budget on a multi-hop payment is generous — often dozens of blocks — because each hop needs margin for its own settlement. During that window, every intermediate node's liquidity is locked.
Almost nobody prices this. A routing node does not merely deploy capital across channels; it deploys capital with settlement latency attached. The effective capital efficiency of a Lightning node is far lower than the raw channel balance suggests, because a fraction of that balance is perpetually parked inside unresolved HTLCs.
Layer that on top of negative carry and the conclusion is unavoidable. Sophisticated capital does not route for strangers. It opens channels for its own payments — inbound liquidity it controls — and treats the rest of the graph as a fallback. Routing third-party traffic is a cost center, not a business.
Here is what running a profitable routing node actually demands, day to day. You monitor each channel's balance in both directions. You rebalance the ones that drift. You set minimum channel sizes, or you forfeit fees because small channels cannot carry meaningful payments. You handle peer churn — counterparties who go offline, who force-close, or who never route. You manage the on-chain fee environment so opens and closes do not stall during congestion.
And you defend against griefing. A Lightning channel is trustless in settlement but adversarial in operation. A counterparty can deliberately hold an HTLC open to immobilize your capital at near-zero cost to itself. This is HTLC jamming, and its economics are brutal: the attacker's cost is a locked HTLC and some bandwidth, while the defender's cost is immobilized liquidity across every channel exposed to the attack. The asymmetry favors the attacker, and it favors the attacker every single time the attack is repeated.
Probing is the softer version. A peer releases low-value payments to map exactly how much inbound capacity you hold, then routes around you — or targets you — based on the map. Balances that took months to cultivate become public intelligence in minutes. When I audited protocol code, one recurring lesson was that adversarial environments do not reward good intentions; they reward whoever pays the lower cost to inflict damage. On Lightning, that is the attacker, almost without exception.
If negative carry were merely a pricing problem, a market for liquidity should have solved it. The ecosystem built several. Their collective performance is the strongest evidence for the structural argument.
Lightning Labs shipped a liquidity marketplace explicitly designed to let nodes buy and sell inbound channel liquidity at market-clearing lease rates. For a time it worked, in the narrow sense that leases cleared. Then it wound down — because the demand that would have sustained it never materialized at prices sellers needed, and buyers could not justify paying for a product whose alternative was simply opening their own channel and routing for free.
Protocol-level liquidity advertisements pursued the same goal with less market machinery. Adoption remained thin for the same reason: the people who needed inbound liquidity could not afford the market price, and the people who could supply it found the returns uncompetitive against simply holding the asset.
The market that was supposed to solve Lightning's liquidity problem is the market that quietly decided the job was not worth doing.
This is why I treat the "Lightning needs better liquidity tooling" narrative with skepticism. The tooling was built. The pricing cleared at levels too low to attract capital. That is not a tooling failure. It is a signal about the underlying economics, and it is the same signal every quarter since.
The ecosystem has also shipped a steady stream of well-engineered protocol improvements, and they deserve credit. Just-in-time routing lets a receiver open a channel at the moment a payment arrives, avoiding pre-committed inbound liquidity. Trampoline routing offloads path-finding to larger nodes so clients need not hold the full graph. Splicing resizes a channel without closing it, cutting on-chain churn. Dual-funded channels let both parties contribute liquidity at open, easing one-directional drain at the start.
None of these attack the root constraint. JIT still requires the receiving node to commit on-chain capital and bear on-chain fee risk. Trampoline concentrates routing into a handful of large nodes — improving the client experience while making the graph more centralized and more fragile at its chokepoints. Splicing reduces churn but does not change the negative-carry arithmetic. Dual funding helps at open but not after months of one-directional flow.
Every upgrade improves the experience at the edges. None of them change the economics at the core, and the economics are the constraint. This is the immutable logic of a netting layer: value flows where liquidity already is, and liquidity stays put because moving it costs more than routing it earns.
The one development worth watching on a multi-year horizon is the arrival of assets beyond bitcoin on Lightning — stablecoins and Taproot Assets. These could change routing economics by diversifying the payment mix, but the directional constraint applies to them identically. A channel full of dollars is still a channel that drains one way. New assets expand the graph; they do not repeal its geometry.
Strip away the ambition and a clear picture emerges. Lightning excels at repeated, small, high-frequency payments between parties who share a channel or a tight cluster — streaming sats, tipping, machine-to-machine micropayments inside a controlled graph. It is excellent when counterparties are known and flow is roughly bidirectional over time, so channels self-balance through ordinary use.
It is mediocre at exactly what it was sold to do: open-ended, one-shot payments to arbitrary recipients across the public graph, especially at higher values. That is the use case where routing failure, negative carry, and channel management compound against the user.
This is not a defeat. It is a scope correction. Lightning is a settlement fabric for known counterparties, not a global payment rail, and the difference is a mathematical one, not a marketing one.
There is a measurement problem that corrupts almost every public debate about the network. The graph that researchers and dashboards analyze is the public channel set — the edges nodes have chosen to advertise. A large and growing share of Lightning's real activity happens over private channels that never appear in that graph, and much of it happens inside custodies that net internally and touch the public network only at the margins.
That means both camps are reading incomplete data. The bulls point at custodial settlement volumes and call it Lightning adoption. The bears point at the public graph's decay and call it Lightning's death. Neither number is describing the same system. The public graph is the part of Lightning that must balance itself honestly, and it is shrinking. The private and custodial layers are the part that scales by refusing to participate in that balancing act. When you read a headline about Lightning volume, the first question is not "how much," it is "on whose ledger."
Every alternative to Lightning makes a trade. Custodial rails move value trivially because a single entity holds every balance and netting is a database update. That is the trade millions of users make daily without noticing. Federated systems distribute that trust across a quorum, gaining censorship resistance at the cost of a committee that must stay honest. Newer layer-2 designs anchor to L1 and accept a different set of capital and latency constraints.
Lightning's bet was that it could have both — trustless settlement and open routing — by letting a market of node operators supply liquidity. The bet assumed that market would be profitable. It never was, and the immutable logic of directional channels plus cheap fees is the reason. The market that was supposed to solve Lightning's liquidity problem is the market that quietly decided it was not worth solving.
The popular narrative holds that Lightning is failing because adoption is slow, because users prefer custodial apps, or because the UX is bad. All three are true, and all three are downstream symptoms. The blind spot is treating throughput and adoption as the bottleneck when the real bottleneck is the unit economics of liquidity provision.
Here is the counter-intuitive part. Lightning's biggest successes have come precisely where the general-purpose routing model is bypassed. Custodial wallets that net internally, closed clusters that settle among known parties, streaming apps that pre-arrange channels — all work because they sidestep the open graph.
The network performs best exactly where it stops being the network.
Retail traders read this as "Lightning works, you just need the right app." The honest reading is the inverse: the app works because it avoids the part of Lightning that does not scale. Every headline about Lightning "handling" record transaction volume usually describes internal netting inside a custodial or near-custodial operator, not the public-channel truss the ideology is built on. The two numbers get blended, and the blend flatters the wrong one — the one that requires no liquidity graph at all.
I have argued elsewhere that capital does not lie about where it is deployed, and Lightning's channel distribution tells the same story. Routing capital concentrates into a shrinking set of large, well-capitalized nodes while the long tail decays — the opposite of the decentralized topology the design envisioned. Centralization is not being imposed on Lightning by anyone. It is being selected for by its own economics, one abandoned channel at a time.
Watch three metrics over the next two quarters, and ignore the rest. First, the ratio of routable capacity to total capacity — if it keeps falling, the network is cannibalizing its own edges. Second, the concentration of large channels among top nodes — if it keeps rising, the open graph is becoming a star topology wearing a mesh topology's name. Third, the fee paid on the marginal routed satoshi — if it stays pinned near the floor, the negative-carry problem is unresolved and the economics will keep selecting for abandonment.
Lightning is not dying. It is contracting into the shape its mathematics always implied. The only open question is whether anyone building on it will admit that the constraint was never UX. It was the immutable logic of directional liquidity, priced by a market that decided the job was not worth doing.
