Lightning Network 2026: Record Capacity, Unsolved Jamming Risk

Bitcoin’s Lightning Network is having two entirely different years at once. Public channel capacity has bounced back toward record territory, dollar-denominated stablecoins now settle over its channels, and large exchanges route a growing share of withdrawals through it instead of the base chain. By almost every headline metric, 2026 looks like the year Lightning finally became infrastructure rather than an experiment.

Underneath that headline, the picture is messier. The number of reachable public nodes has been falling for four years. A well-known attack called channel jamming still has no live, deployed fix anywhere on the network, seven-plus years after it was first described. And the liquidity that does exist is concentrating into a shrinking list of professional operators, exchanges and cloud providers rather than spreading across the thousands of hobbyist machines that gave Lightning its decentralized reputation in the first place. This piece looks past the capacity charts to the plumbing underneath them: what channel jamming actually is, why nobody has shipped a fix yet, why running a node stopped paying for itself, and what that means for the institutions now building payment products on top of all of it.

A network that keeps setting records, and keeps shrinking

Start with the numbers everyone quotes. Public Lightning capacity sat at roughly 4,898 BTC as of the most recent published reading, from May 2026, according to aggregated data cited by Spark’s 2026 state-of-the-network research. That is up from a trough of around 4,200 BTC in August 2025, though still below the all-time high of 5,637 BTC recorded in December 2025. At bitcoin’s price in late July 2026, hovering around $64,300 according to CoinGecko, that May reading works out to roughly $315 million sitting in public channels alone. Spark’s research estimates that private and unannounced channels, the kind mobile wallets and liquidity providers open without broadcasting them, hold at least as much again, meaning the true size of the network is probably double what public trackers show.

Now the other side of the ledger. The public node count has fallen to roughly 17,438, down from a 2022 peak near 20,700, a decline of close to 16 percent over four years. Public channels sit around 41,080, down from a rough peak near 43,000 at the end of 2025 and far below the 80,000-plus channels that existed at various points in 2023, before the network started favoring fewer, larger channels over many small ones. Put the two trends side by side and the story is not simple growth or simple decline. It is consolidation: more money, moving through fewer hands.

That consolidation is the throughline for the rest of this piece. It shows up in why channel jamming remains unsolved (the operators best equipped to defend against it are large, professional ones, not hobbyists), in why inbound liquidity is such a persistent complaint (new, small nodes are the ones who feel it most), and in why institutions like exchanges and custodians are becoming the network’s de facto backbone.

A quick refresher on how Lightning actually works

Lightning is a network of two-party payment channels, each backed by bitcoin locked in a shared on-chain address. Two participants open a channel by committing funds on-chain, then move that balance back and forth privately and instantly for as long as the channel stays open. To send a payment to someone you do not have a direct channel with, the network routes it through a chain of channels using hashed timelock contracts (HTLCs): each hop forwards the payment only if it can later prove it was completed, using a cryptographic preimage, within a set time window.

That timelock mechanism is what makes trustless routing possible without a central intermediary. It is also, as the next few sections cover, the exact mechanism a griefing attacker can abuse. Recent protocol work has made channels themselves more flexible: splicing lets operators resize a channel without closing it, taproot channels (production-ready since LND’s v0.21-beta release in June 2026) shrink a channel’s on-chain footprint, and BOLT12 offers give wallets reusable, static payment codes similar to a payment link. None of that changes the underlying HTLC mechanics that jamming exploits.

Larger or awkwardly-sized payments do not need a single unbroken path either: multi-part payments (MPP) let a sending wallet split one payment across several routes simultaneously, reassembled at the receiving end, which is part of why Lightning can settle larger transfers reliably even when no single channel along the way has enough capacity on its own. That flexibility is a big part of why usage has grown even as the number of people running their own nodes has not; the complexity of routing, splitting and rebalancing payments has increasingly moved into wallet software and LSP infrastructure rather than something an end user needs to think about at all.

What channel jamming actually is

Channel jamming is a denial-of-service attack against Lightning’s routing layer, not against any individual’s funds. An attacker opens channels into the network, then sends HTLCs to itself through a target’s channels, deliberately withholding the payment preimage so the HTLC never settles. Each of those pending HTLCs ties up a slot and a slice of liquidity in every channel along the route until the timelock finally expires, typically hours to days later.

The attack is cheap because of a hard protocol limit: each channel direction can hold a maximum of 483 pending HTLCs at once, a cap tied to the maximum size of a Bitcoin transaction (since a force-closed channel has to fit every pending HTLC into one on-chain transaction). An attacker only needs to fill those 483 slots, not lock up large amounts of capital, to freeze a channel’s ability to route new payments. It is conceptually similar to other infrastructure griefing attacks that have plagued crypto systems (see how cross-chain bridges have their own recurring failure patterns), except that on Lightning it targets availability rather than funds directly.

Researchers studying the attack distinguish between two variants. Fast jamming floods a target with short-lived HTLCs that are canceled just before their timelock would expire, cheap to run but also easier to spot because it generates an unusual volume of failed forwards in a short window. Slow jamming is patient: an attacker holds a smaller number of HTLCs open for as long as the protocol allows, tying up capacity for hours at a time while generating far less obvious log activity, making it the harder variant to defend against with simple rate limits alone. Most of the mitigation work now underway, including the reputation and accountability-signaling approach described below, is aimed specifically at making slow jamming expensive rather than just rate-limiting fast jamming, since the slow variant is the one that actually threatens a well-run node’s liquidity for meaningful stretches of time.

Why jamming hasn’t been weaponized at scale, but still shapes the network

Here is the strange part: despite being cheap, well documented, and unsolved since it was first formally described years ago, large-scale jamming attacks are not something node operators report dealing with regularly in public. A few things explain that gap. First, jamming a small node accomplishes very little of value to an attacker; the interesting targets, high-capacity routing hubs, are also the best resourced to notice and route around unreliable peers. Second, the attack is more useful as a targeted tool (freezing one merchant’s inbound liquidity right before a payment) than as network-wide sabotage, and targeted attacks are harder to detect in aggregate statistics.

That does not mean the risk is priced at zero. A 2025 formal verification paper on arXiv modeled jamming systematically and confirmed the attack surface is real and measurable rather than theoretical. More importantly, the mere possibility of jamming shapes how professional routing nodes are run today: it is part of why serious operators reserve liquidity buffers, monitor peer behavior, and increasingly favor channels with other known, reputable counterparties over anonymous ones. In other words, jamming does not need to be actively exploited to push the network toward the same centralization outcome that unrestrained exploitation would eventually force anyway.

Inside the fix: reputation, accountability, and years of slow progress

The Lightning developer community has known about jamming since at least 2022, when Bitcoin protocol contributor Antoine Riard proposed one of the first serious mitigations: a system of Chaumian ecash tokens that nodes issue to their peers, described in detail by Bitcoin Magazine. Under that scheme, a sender buys tokens up front from each node along a likely route; a successfully settled payment earns a fresh token back, while a failed or jammed HTLC burns the token with nothing reissued. The idea was to make failed payments carry a real cost for the first time, without requiring nodes to track the identity of who is paying.

That proposal evolved into what is now called hybrid jamming mitigation: a combination of outgoing reputation (tracking how reliably a peer’s forwarded HTLCs actually settle) and accountability signaling that reserves a portion of a channel’s resources for low-reputation or unknown peers so they are not frozen out entirely, while protecting established, high-reputation traffic during congestion. The work is tracked publicly in the Lightning BOLTs repository, and as of the most recent update logged on GitHub issue #1218, it is still at the read-only, shadow-mode stage: implementations log what the system would have done without actually enforcing anything on live HTLCs yet. LDK has a working read-only build under review (pull request #4409), LND has its own implementation in progress (pull request #10919), and Eclair’s earlier experimental branch has seen no recent public activity. Core Lightning is participating in the broader specification discussion without a shipped implementation of its own yet.

That is the honest state of the fix, four years after the current approach began taking shape and closer to a decade after jamming was first raised as a concern: still being tested in shadow mode, not yet trusted to actually intervene on real payments. It is not that nobody is working on it. It is that turning a reputation system into something that cannot be gamed by patient attackers, without also punishing new or low-volume peers unfairly, has proven to be a genuinely hard distributed-systems problem.

The other structural problem: getting paid requires inbound liquidity

Jamming is not the network’s only unresolved friction point. Spark’s research describes inbound liquidity as the number-one operational challenge facing node operators today, and the mechanics explain why. When a node opens a new channel, all of the channel’s initial balance sits on that node’s own side; it can send payments immediately but cannot receive anything meaningful until a counterparty sends funds back the other way, or it pays a liquidity provider for inbound capacity directly.

For a hobbyist running a single node, this is a real barrier to participating usefully in the network at all, and it is a large part of why liquidity service providers (LSPs) exist: rather than every wallet user managing their own channels and liquidity, a wallet provider manages one set of well-capitalized channels and issues just-in-time channels or virtual balances to its users on demand. That model is convenient and it works, and it is also, structurally, a step back toward custodial or semi-custodial arrangements for exactly the users Lightning was originally meant to make self-sufficient. HOGE Wire’s own look at how people actually use Lightning wallets day to day found the same pattern: most real usage now runs through LSP-mediated wallets rather than fully self-managed nodes, precisely because managing inbound liquidity yourself is still a specialist skill.

Node count keeps falling, and the economics explain why

Put jamming risk and inbound liquidity friction together and the four-year decline in public node count stops looking mysterious. Running a reliable, always-on, well-peered routing node takes real effort: monitoring channel health, rebalancing liquidity, watching for misbehaving peers, and eventually deciding whether a marginal channel is worth the on-chain fees to open and, someday, close. For a hobbyist competing against professional operators who can spread that overhead across a much larger capital base, the economics rarely work out. Spark’s research links the decline directly to that dynamic, describing a network where capital and volume are increasingly concentrating into fewer, larger, better-run nodes rather than spreading across thousands of hobbyist machines, many of which have quietly closed up shop or handed their coins to a wallet provider that manages channels on their behalf.

David Marcus, the former PayPal president who now runs Lightning infrastructure company Lightspark, made a version of this point explicitly back in November 2023, and it has only become more relevant since. As he put it in comments reported by Bitcoin.com News: “To be blunt, if you want full support for non-custodial Lightning with offline receive and want to make it economically viable, you have to accept some form of compromise on the trustlessness level of the solution.” That is precisely the trade the market has made. Custodial and LSP-mediated Lightning is booming. Fully self-sufficient, non-custodial node operation is shrinking.

Where the capacity actually lives now

It helps to see the concentration in concrete terms rather than as an abstract trend. A detailed snapshot of public channel liquidity compiled by Bitcoin.com News in August 2025 (using its own tracker, which counts total public capacity somewhat differently from Spark’s aggregation, illustrating just how much measurement varies by methodology and how badly private channels get undercounted across the board) found that the ten largest publicly identifiable node operators controlled roughly 2,389 BTC between them, about 62 percent of the network’s total public capacity at that moment. The table below shows the operators with the clearest disclosed figures from that same snapshot.

Four of the six names in that table are exchanges (Binance, Bitfinex, Kraken) or a major payments company (Block), not dedicated routing businesses. That lines up with the broader pattern this piece keeps returning to: Lightning’s liquidity is increasingly held by organizations that operate nodes as a feature of a larger custodial business, exactly the arrangement Marcus described as the practical compromise, rather than by independent routing operators trying to earn fees. It is a similar dynamic to what played out in Ethereum liquid staking, where a handful of protocols and operators ended up holding an outsized share of a supposedly decentralized system simply because scale is where the operational efficiency is.

The cloud concentration problem

The consolidation is not just financial, it is infrastructural. A widely cited analysis using Mempool Space data, reported by Bitcoinist, found that roughly 48 percent of all Lightning nodes were hosted on just two cloud providers, Amazon Web Services and Google Cloud, at close to a 29 percent and 19 percent split respectively. Later reporting through 2025 has put the combined figure in a broadly similar mid-to-high-40s percent range, suggesting the concentration has eased only marginally even as the wider conversation about centralization has intensified.

The appeal is straightforward: a node needs to be online essentially all the time to avoid missing payments, catching force-close attempts, or losing peer reputation, and a managed cloud instance is the cheapest way to get that uptime without running physical hardware. The tradeoff is that a huge share of a network marketed as decentralized and censorship-resistant now depends on the continued goodwill, and continued uptime, of two American technology companies. It is the same structural irony that shows up whenever a permissionless network reaches for centralized infrastructure to solve an availability problem, whether that is Lightning nodes on AWS or, in a different part of crypto entirely, mining pools concentrating hashrate through a handful of coordinators.

That matters beyond simple business risk. Part of Lightning’s original appeal was that no single company or government could easily censor payments across it, since routing did not depend on any one operator’s infrastructure staying online. A network where nearly half of all nodes share two corporate landlords narrows that guarantee considerably: a policy change, a legal order, or even a routine outage at either provider would ripple across a disproportionate share of the network at once. It is not a hypothetical unique to Lightning either. Bitcoin mining has faced a similar critique for years as hashrate concentrated into a handful of large pools, and the debate in both cases lands in the same place: the technology remains permissionless in principle, while a shrinking set of operators controls enough of the practical infrastructure to matter in a crisis.

Quantum computing and other long-tail risks

Jamming and centralization are near-term, structural concerns. A longer-tail one surfaced publicly in April 2026, when Taproot Wizards co-founder Udi Wertheimer argued in a widely shared post that the Lightning Network is “helplessly broken” in a post-quantum world and that little could be done to fix it before a cryptographically relevant quantum computer arrived.

CoinDesk’s Bobby Shell pushed back directly in an opinion piece the same month, arguing the real mechanism is narrower and more conditional than Wertheimer’s framing suggested: a force-closed channel briefly exposes a public key on-chain, and only a sufficiently powerful quantum computer, acting within the hours-to-a-day timelock window before that transaction confirms, could theoretically derive the corresponding private key and steal the funds. As Shell put it in the piece, published on CoinDesk: “The Lightning Network is not helplessly broken. It faces the same long-horizon cryptographic challenge as the entire digital financial system.” No cryptographically relevant quantum computer exists today, and Bitcoin’s own post-quantum signature proposals are still being actively drafted. It is a real long-term item on the risk register, not an active vulnerability, but it belongs in the same conversation as jamming and centralization: another example of a problem the network has identified well before it has actually solved it.

That has not stopped Bitcoin’s developer community from starting the work early. Proposals for post-quantum signature schemes, including hash-based approaches and new tapscript opcodes designed to eventually replace the elliptic-curve signatures Lightning relies on today, have been circulating in Bitcoin research channels since late 2025, though none has been adopted into a shipped BIP with production-ready post-quantum signatures as of mid-2026. The realistic timeline being discussed by cryptographers is measured in years rather than months, both because migrating every wallet, exchange and Lightning implementation to new signature schemes is a coordination challenge on its own, and because nobody wants to rush a cryptographic transition this consequential. For now, the practical takeaway for Lightning users is the same as Shell’s: this is a shared, long-horizon problem for all of Bitcoin and traditional finance alike, not a Lightning-specific flaw.

Do channelless rivals like Ark and Spark sidestep the problem?

Part of the reason Lightning’s structural issues matter now is that alternatives are emerging that avoid some of them by design. Ark (built by Ark Labs, whose Arkade implementation went live on Bitcoin mainnet in October 2025) uses a round-based, shared-UTXO model instead of individually managed payment channels, so there is no equivalent of a two-party HTLC channel for an attacker to jam directly. Spark, built by Lightspark using a statechain-based design, works similarly: users do not manage inbound liquidity or peer channels themselves at all.

Mechanically, Ark works by having users hold virtual UTXOs that an Ark Service Provider batches into shared on-chain transactions at regular intervals, letting many users transact off-chain between those batches without each pair needing its own dedicated channel. Ark Labs raised a $5.2 million seed round backed by Tether in March 2026 to build out a multi-asset and stablecoin framework on top of that base layer, a sign that the same institutions pushing dollar tokens onto Lightning are hedging across more than one settlement design.

Neither is a free lunch. Both replace channel-management risk with a different kind of trust: users depend on a coordinating operator (an Ark Service Provider, or Spark’s operator set) to behave honestly and stay solvent, which is a materially different security model from Lightning’s trust-minimized routing, even if it is operationally simpler. Both are also still far smaller than Lightning in production terms. The honest framing is that Ark and Spark do not solve jamming so much as change which problem a user is exposed to, trading a routing-layer griefing risk for an operator-trust risk. Given how slowly Lightning’s own jamming fix has moved, that trade is clearly appealing to some builders regardless.

What this means for the institutions now building on Lightning

None of this has stopped serious institutional money from building on top of Lightning over the past year, and that is arguably what makes the underlying fragility worth taking seriously rather than dismissing as a hobbyist concern. Custody providers now offer Lightning-based products to institutional clients, exchanges route a rising share of bitcoin withdrawals over Lightning rails instead of the base chain, and stablecoin issuers have built dollar-denominated payment rails directly on top of it. Every one of those products inherits Lightning’s routing-layer characteristics, jamming exposure, inbound liquidity friction, and cloud and exchange concentration, whether or not the institution offering the product advertises that fact.

Some of that infrastructure is already live and named. BitGo added Lightning custody to its platform through a partnership with infrastructure provider Voltage, and Voltage itself has built a revolving, dollar-settled credit line against Lightning cash flows for merchants who would rather not hold bitcoin on their balance sheet at all. Products like that are a reasonable, even sensible, response to real customer demand. They are also, by construction, another layer of custodial abstraction sitting on top of a routing layer that has not yet solved jamming or fixed its liquidity problem, which means the institutions offering them are underwriting operational risks that the protocol itself has not resolved.

That is also exactly why so much of the interesting activity is happening at the custodial and LSP layer rather than the base protocol: it is far easier for an exchange or a wallet provider to manage jamming risk and liquidity centrally, across its own well-peered infrastructure, than to expect a retail user to do the same. The same logic is playing out across other parts of crypto infrastructure right now, from AI agents that need instant, sub-cent settlement rails to transact autonomously and are increasingly routed through the same custodial Lightning infrastructure rather than raw peer-to-peer channels, to exchanges competing on how seamlessly they can abstract Lightning’s operational complexity away from end users entirely.

The regulatory backdrop nobody’s watching fix

The stablecoin flows now riding on Lightning sit inside a regulatory framework that is itself unfinished. The GENIUS Act, signed into law in July 2025, gave the OCC, FDIC, NCUA, the Federal Reserve, and Treasury’s FinCEN and OFAC arms one year to finalize implementing rules for payment stablecoin issuers. That deadline passed on July 18, 2026, and none of the six bodies had issued a final rule; the OCC’s own proposal remains exactly that, a proposal, according to its official rulemaking bulletin. A statutory backstop still applies regardless: the law’s substantive requirements take effect automatically 18 months after enactment, in January 2027, or 120 days after final rules are issued, whichever comes first.

HOGE Wire covered that missed deadline, and what it means for the dollar stablecoins now settling over Lightning channels, in a dedicated look at Lightning’s dollar rails going live before Washington’s rulebook was ready. The short version relevant here: the payment rail itself is neutral infrastructure, and the compliance questions sit with issuers, custodians and wallet providers rather than with Lightning as a protocol. But it is another example of the same pattern running through this entire piece, adoption and product-building moving well ahead of the underlying layer, whether that layer is the jamming-resistant routing fix or the finished federal rulebook, actually catching up.

The growth numbers, in one place

To see the full arc, it helps to put the network’s headline metrics side by side across their recent peaks and troughs, rather than reading any single snapshot in isolation.

The pattern across all three rows is the same: fewer participants, fewer channels, but more capital per channel and per node. LND, which still runs the majority of public nodes because it ships bundled with popular self-hosting packages, remains the holdout on natively supporting BOLT12 offers, running them only behind an experimental flag, even as Core Lightning, LDK and Eclair support them natively. That gap is a reasonable proxy for how unevenly the ecosystem’s own tooling is keeping pace with its usage growth. Nodes running with known Tor-only connectivity (8,975) still outnumber declared clearnet-only nodes (4,696) among the subset of nodes with published connection data, a reminder that even as institutions dominate the capital side of the ledger, a meaningful privacy-conscious hobbyist layer persists underneath it, just a shrinking one relative to the network’s overall size.

None of this argues that Lightning is failing. Payment volume, stablecoin settlement and institutional integration are all real and growing, and the base layer has absorbed all of it without a major outage or a successful large-scale jamming campaign making headlines. The more accurate read is that Lightning has quietly become critical payments infrastructure before finishing the parts of itself that were supposed to make it trust-minimized and censorship-resistant by default. That gap, between what the network does today and what it was originally designed to guarantee, is the story worth watching through the rest of 2026, more so than any single capacity chart.

Frequently asked questions

What is channel jamming on the Lightning Network?

Channel jamming is a denial-of-service attack in which someone sends payments to themselves through a target’s channels and deliberately withholds confirmation, tying up liquidity and HTLC slots (capped at 483 per channel direction) until the payment’s timelock expires. It does not steal funds directly, but it can freeze a channel’s ability to route other payments for hours at a time, and as of mid-2026 the leading mitigation proposals are still being tested in shadow mode rather than deployed live.

How many nodes and how much capacity does the Lightning Network have in 2026?

The most recent published figures, from May 2026, put public capacity at roughly 4,898 BTC across about 17,438 nodes and 41,080 channels, according to Spark’s research. Capacity is down from a December 2025 peak of 5,637 BTC, while the node count has fallen from a 2022 peak near 20,700, a decline of roughly 16 percent over four years even as capacity has recovered toward its highs.

Is the Lightning Network becoming more centralized?

Yes, on multiple axes at once. A 2025 snapshot found the ten largest publicly identifiable node operators, mostly exchanges and payment companies, controlled about 62 percent of public channel capacity, and separate research has put roughly 45 to 48 percent of all Lightning nodes on just two cloud hosting providers, Amazon Web Services and Google Cloud. The network is shifting toward a smaller number of large, professionally run nodes rather than thousands of independent hobbyist operators.

Can channel jamming be fixed?

Developers have been working on it since at least 2022, when Antoine Riard proposed an ecash-token-based mitigation. The current approach, a hybrid reputation and accountability-signaling system, is tracked in the Lightning BOLTs specification repository and has working read-only implementations in LDK and LND as of mid-2026, but none of the major implementations have moved from passive logging to actually enforcing the mitigation on live payments yet.

Is it profitable to run a Lightning Network routing node?

For most small, independently run nodes, generally not in any meaningful way. Inbound liquidity has to be acquired or earned rather than appearing automatically, channel-opening and closing costs real on-chain fees, and running reliable, always-online infrastructure takes ongoing effort. Spark’s research describes capital and volume concentrating into fewer, larger, professionally run nodes, which is why most casual users now rely on liquidity service providers or custodial wallets rather than operating their own routing node.

By Daniel Marsh, HOGE Wire