Why Lightning Was Always the Wrong L2

May 25, 2026 · 6 min read

Paul Sztorc has been calling Lightning a dead end since at least 2022. His "Lightning Limitations" essay catalogued the onboarding problem, the routing problem, the liquidity problem, the watchtower problem, the channel-rebalancing problem, and the fact that all of them compound. His "Lightning Blackpill" follow-up noted that even Lightning's original developers had quietly moved on.

The standard rebuttal is that Lightning is early, that the user experience will improve, that better tooling is coming. This rebuttal has been recycled for eight years. At some point, "early" stops being a defense and becomes a diagnosis.

The deeper truth is that Lightning's failure was not a deployment problem. It was a category error. The Lightning Network was built to solve a problem Bitcoin doesn't have, while ignoring the problem Bitcoin actually does.

What Lightning was designed to do

Lightning is a payment channel network. The original 2015 design assumed that the bottleneck in Bitcoin adoption was payment throughput — Visa-scale transactions per second for coffee purchases. Open a channel, route micropayments off-chain, settle to the L1 occasionally. Brilliant cryptography in service of a specific use case: high-frequency, low-value, point-of-sale payments.

If Bitcoin's only problem were "we need to buy coffee with sats," Lightning would be a reasonable answer. But that has never been Bitcoin's problem.

Bitcoin's actual problems, in order of severity, are:

  1. The security budget collapse as the subsidy halves toward zero
  2. The experimentation bottleneck preventing new use cases from being tested
  3. The miner alignment problem as off-chain activity grows
  4. The onboarding problem for the next billion users

Lightning addresses none of these. It actively worsens the first three.

How Lightning makes the real problems worse

On the security budget: Every transaction routed through Lightning is a transaction that does not pay an L1 fee. Lightning was explicitly designed to keep fees off the main chain. This is celebrated as a feature ("cheap transactions!") but in security-budget terms it is the disease, not the cure. A Lightning network handling a billion payments per day pays Bitcoin's miners essentially nothing.

On experimentation: Lightning is not a programmable execution environment. It cannot host prediction markets, privacy pools, smart contracts, tokenization platforms, or any of the use cases that drove altcoins into existence. It is a single-purpose payment rail. So Lightning's success does nothing to absorb the demand for experimentation that currently flows to Ethereum, Solana, and every other competing chain.

On miner alignment: A successful Lightning network creates a powerful interest group — channel operators, LSPs, custodians — whose revenue depends on routing fees, not on Bitcoin's security. Foundry running a custodial Lightning service does not pay Bitcoin's miners; it pays itself. The political coalition this creates is hostile to anything (like drivechains) that would route fees back to the hashrate.

The custodial endgame

Sztorc's most devastating observation is that Lightning, in practice, has become a marketing label for custodial services. Wallet of Satoshi has tens of millions of users. None of them are running channels. None of them have unilateral exit. None of them custody their own keys. They are using a centralized exchange and calling it "Lightning."

This is not a bug in the rollout. It is the equilibrium the design forces. Self-custodial Lightning requires:

The vast majority of users will never do this. They will use a custodian and pretend it is Bitcoin. The Lightning brand provides cover for what is, structurally, the rejection of everything Bitcoin was built to oppose.

"Custodial is a rejection of everything Bitcoin stands for — we are literally telling people, NOT to use Bitcoin." — Paul Sztorc

What a real L2 looks like

A real Layer 2 should accomplish four things:

  1. Move computation off the L1 so the main chain stays lean
  2. Preserve self-custody so users actually own their coins
  3. Pay the L1's miners so security scales with adoption
  4. Allow experimentation so new use cases can be tested without launching new monetary assets

Drivechains do all four. Lightning does only the first, and even then only for users sophisticated enough to run their own infrastructure.

A drivechain sidechain hosts arbitrary computation — privacy, contracts, prediction markets, anything its designers want. Users hold BTC on the sidechain through a cryptographic two-way peg, not a custodian. Miners earn fees from sidechain activity through blind merged mining. And because each sidechain is independent, experiments can succeed or fail without endangering the L1.

This is what Bitcoin's L2 architecture should have looked like from 2015 onward. Lightning was a detour. Drivechains were the road.

The cost of the detour

Eight years of developer attention, hundreds of millions of dollars in research and engineering, an entire generation of Bitcoin conferences dominated by Lightning talks — and the result is that Bitcoin handles fewer transactions per second than it did in 2017, while custodial alternatives capture the volume.

Meanwhile, the experiments that should have happened on Bitcoin sidechains happened on altcoins instead. Ethereum got smart contracts. Monero got privacy. Polymarket got prediction markets. Each of these is a use case Sztorc identified as appropriate for a Bitcoin sidechain before the corresponding altcoin existed. The opportunity cost is staggering.

The defenders of Lightning will say this is unfair, that the technology was promising, that the developers worked in good faith. All of that may be true. But promising technology that fails to ship for eight years, while the problems it was supposed to solve get worse, is not a success story. It is a cautionary tale about what happens when a community commits to the wrong architecture and refuses to admit it.

Ecash starts from the right architecture

The reason to fork is not that Lightning is bad. It is that the commitment to Lightning has become an obstacle to the better path. Every developer hour spent on Lightning routing optimization is an hour not spent on drivechain implementation. Every conference panel celebrating Lightning's "growth" is a panel not held on sidechain design. The opportunity cost compounds.

Ecash resolves this by starting fresh. Drivechains are active from genesis. Lightning channels can still be opened — nothing prevents it — but they compete with mined L2s on a level playing field, instead of being the only sanctioned option. In that competition, Lightning will find its actual niche, which is probably: a small number of high-volume merchants handling specific payment flows. Useful, but bounded.

The grand vision of Lightning as Bitcoin's universal scaling solution will quietly retire. Not because anyone bans it, but because the alternative finally exists.

That is the gift Ecash gives the Lightning project: an honorable exit from a job it was never going to finish. The energy currently spent defending the indefensible can finally flow to building what works.