Greatly oversimplified short version

The Bitcoin Lightning Network failed because it has an unacceptably high rate of transaction failures. Ballpark figures are as follows¹:

Microtransactions (~US $0.05 or smaller) are extremely likely (>99%) to succeed.²
Starbucks tier transactions (~US $10) succeed roughly 90% of the time
Grocery store tier transactions (~US $200) succeed about 50% of the time
Furniture store tier transactions (~US $1000) succeed roughly 25% of the time
Rich people furniture store tier transactions (~US $10,000) succeed roughly 5% of the time.

Essentially, Lightning trades away throughput (bandwidth) for speed (latency).

Obviously these rates of transaction failures are comically unacceptable for a practical business. There is a ton of nuance to the statements above being sanded over (very recklessly), all in the interest of saving your time.

Introduction: The Lemonade Stand

At the time of writing (April 2026), the central problem in the world of cryptocurrency is that of The Lemonade Stand: can a 7-year-old use your cryptocurrency to operate a lemonade stand?

If the answer is no, your project is probably useless.

The barnacles in the crypto industry would like us to think that the central problem in our industry is how to achieve quantum-resistant protocol-level zk-snark data availability validation of cross-chain hyper-tokenized fungible assets on layer-2 networks from the perspective of the non-compliant custodial layer-6 hyperdimensional time warp without assuming connectedness of spacetime or that numbers exist.

This is largely a smokescreen to distract from the fact that our industry has given up on solving the lemonade stand problem. No chain other than Gajumaru has a serious answer for that extremely elementary use case.

This problem emerged mostly by historical accident, and the failure of Lightning is a very important chapter of that story.

Most serious software engineers have looked into cryptocurrency at some point or another since the Bitcoin whitepaper was published. From a programmer’s perspective, cryptocurrency sounds like a dream: I can just accept money, I control it, and I don’t have to deal with any nonsense with banks or financial institutions or use some proprietary third-party service. I can just use it.

The first thing our programmer does is make a little tutorial project wherein he solves the lemonade stand problem for himself. Just get something working, he thinks. Then, slowly, over the course of a few hours, or maybe a few days, he discovers that the lemonade stand problem is in fact not solvable with the tools available at his disposal. The feeling is something akin to trying to build a chair out of popsicle sticks and scotch tape. It’s theoretically possible, but the chair is obviously going to implode as soon as someone tries to sit in it.

Then he looks at different crypto projects. And he finds the same thing everywhere: everyone has a lot of big ideas. Many of them are genuinely interesting and very promising. Most of them are stupid. But crucially, nobody has any practical solutions. No crypto project (other than Gajumaru) can meet the practical business needs that Suzie (7F) has for her lemonade stand.

Wow. Well that’s useless, the programmer says to himself. And then he moves on, and doesn’t think about cryptocurrency ever again.

Thus, by selection, the human capital present in the technical side of our industry became composed mostly of programmers whose interest in cryptocurrency centers around something other than the “currency” part.

This selection effect on human capital constructively interfered with the post-2008 infinite money printing problem. Investor dollars (and therefore talent) went into hype, scams, shitcoins, FOMO, rugpulls, NFTs, etc. Over time, these little parasitic cottage industries became the crypto industry nearly in its entirety.

The story mirrors the dotcom bubble quite faithfully. Most of the big dotcom ideas from the time exist now as successful profitable businesses. For instance, pets.com is a meme, but I spend $200/month on prescription cat food on chewy.com. Netflix (the streaming service, not the DVD-rental-by-mail service) was an idea within the realm of popular conception in 1998, but it wasn’t until the early 2010s that consumer broadband connections were good enough that streaming high-definition videos was feasible.

The same basic problem presents itself in the cryptocurrency industry today: everyone is focused on fantastical far-out ideas that are cool and often even good, but the boring, basic nuts-and-bolts infrastructure required to manifest these grand ideas into practical reality has simply been ignored.

The Lightning subplot is so pivotal in this story, because it started as a bona fide attempt to solve Suzie (7F)’s business needs. When it failed, the crypto industry took away exactly the wrong lessons from the story, and proceeded down the garden-path of layer 2 networks. The Lightning Network is the canonical example of a Layer-2 network, in the same way that Bitcoin is the canonical example of a blockchain.

In hindsight, it seems to be the case that Lightning failed because it is trying to solve a problem that is overconstrained; that is, if you conjoin the list of requirements that must be met by a workable Layer-2 solution, there is no solution.

More recent attempts to make the Layer-2 network concept work (e.g. Plasma, zkSync) essentially consist of taking the basic pretense of the lightning network, but trying to add constraints so that the specific failures that killed previous layer-2 projects are impossible.

In other words, every Layer-2 project fails because it is trying to solve an impossible problem. Each successive Layer-2 project has failed or will fail because it is adding constraints to an already overconstrained problem.

The basic idea of Gajumaru Associate Chains is to look at this broader meta-problem, and remove constraints so that the resulting problem is solvable. The AC protocol does not dictate any one specific solution, rather it simply provides a set of basic constraints that solutions (individual associate chains) must follow.

How Lightning Works

In Why Proof-of-Work Works (in Theory), we mentioned the Bitcoin Scaling Problem:

The basic problem that plagues Bitcoin is that the process of the entire planet agreeing on a uniform view of changes to the ledger is orders of magnitude slower than the underlying economic processes that would motivate people to change the ledger in the first place. Very bluntly: Bitcoin can’t scale.

The first project that made a serious attempt to address this issue was Lightning. The idea of Lightning is extremely complicated and must be understood in stages.³

The concept here that we want the reader to notice is that of the optimistic rollup: the most recent state of the L2 is broadcast back to the L1, but no information about sequence is communicated to the L1. This broadcast is presumed to be correct and trustworthy (this is the “optimistic” part). There is a challenge period built in where wronged parties have opportunity to prove that the prior broadcast is fraudulent. If the wronged parties fail to notice or act on this opportunity, they get screwed.

Stage 1: A lightning network with 2 accounts

The first stage of the lightning idea is roughly as follows:

Alice the Alcoholic wants to transact with Bob the Bartender on a long-term basis
Their economic relationship involves many small transactions (individual drinks) which are kept track of off-chain (think of a “bar tab” as roughly analogous to the L2 state)
This L2 state is periodically “rolled up” and committed back to Bitcoin (Bob charges Alice’s card)
directly spending Bitcoin to each other on the Bitcoin network incurs too much overhead (analogy: Bob charging Alice’s card for each individual drink), both in terms of confirmation delay and transaction fees

Here is how it works:

Alice and Bob create a one-time account AliceBob-L1 on Bitcoin
on January 1, each deposit 1000 BTC into the AliceBob-L1 account, for a total of 2000 BTC
This is roughly analogous to cases such as buying gasoline with a credit card, in which your bank “places a hold” of $200 to cover any conceivable gas transaction. The remainder is refunded back to you after the transaction is complete.
The AliceBob-L1 account on the Bitcoin network is governed by a complicated cryptography scheme
Nobody (in particular, neither Alice or Bob) can access or reverse-engineer the private key for the AliceBob-L1 account
Alice and Bob can transact with each other privately, off-chain, using this complicated cryptography scheme
This is analogous to Alice and Bob updating the bar tab in private without committing the changes back to VISA
We will call this off-chain exchange “the AliceBob-L2 network” (not to be confused with “the AliceBob-L1 account”, which is an ordinary Bitcoin account)
Suppose on February 1, the state of the AliceBob-L2 network is such that Alice has 1500 BTC and Bob has 500 BTC.
at any time, either Alice or Bob can broadcast the most recent state of the AliceBob-L2 network back to the Bitcoin chain, and the AliceBob-L1 account automatically will disburse 1500 BTC to Alice and 500 BTC to Bob.
At any time, Alice and Bob can mutually agree to close the AliceBob-L2 network and have the funds disbursed back on the L1.

There is already a serious problem just with this simple case:

On February 1, the state of the AliceBob-L2 network was such that Alice had 1500 BTC and Bob had 500 BTC.
Suppose on January 23, the state of the AliceBob-L2 network was such that Alice had 1900 BTC and Bob had 100 BTC.
Suppose at 1:00 AM on February 1, Alice broadcasts the old state from January 23 back to Bitcoin.
If the AliceBob-L1 account on Bitcoin disburses its balance back to Alice and Bob according to the old view of their funds, Bob’s funds are lost.
In order to guard against this, the AliceBob-L1 account on Bitcoin is programmed with a challenge period.
This is roughly analogous to the “chargeback” function in credit cards.
Bob has until 1:00 AM on February 2 to prove that Alice’s state is no longer valid.
The cryptography scheme is designed such that Bob has this capacity.
However, this necessitates Bob watchfully spying the Bitcoin network to guard against Alice’s chicanery.
If Bob is victimized by a natural disaster that cuts off his internet for 24 hours, he’s SOL.

Already it should be obvious that the practical utility of this scheme is extremely limited, primarily on account of its complexity, and secondarily on account of its necessity for unrealistic user vigilance.

Stage 2: Onion Routing, Gossip, Discovery, and Network Topology

Image Source

If we limit the lightning network idea to the simple case of the 2-person network laid out above, it makes the settlement delay and transaction fee issues worse:

Alice and Bob have to pay L1 fees to deposit their funds into the AliceBob-L1 account, and pay L1 fees to disburse the funds once they wish to close the AliceBob-L2 network
settlement takes longer because of the challenge periods involved in closing the account

The next trick up the sleeve of this cryptography protocol is onion routing.

Alice and Bob agree to transact (on the L2) via an intermediary Isaac
Alice sends money to Isaac, who takes a cut, then forwards the remainder to Bob.
1. Bob bills Alice for 99 BTC
2. Alice sends 100 BTC to Isaac, specifying that 99 is to be forwarded to Bob
3. Isaac sends 99 BTC to Bob and keeps 1 BTC for himself
The cryptography scheme is such that either the transaction completes and everyone gets their cut, or the transaction fails entirely and nobody gets their cut
Specifically, Isaac has no capacity to simply accept Alice’s funds and then disappear.
There can be an arbitrary number of intermediaries, and the same constraints apply: either the transaction completes in full or the transaction fails entirely.
Alice is responsible for discovering and specifying the sequence of hops that the money is to take.
Each intermediary between Alice and Bob knows only about the prior hop and the next hop.

So if there are 3 intermediaries:
```
Alice -> Xavier -> Yolanda -> Zach -> Bob
```
then Yolanda only knows about Xavier and Zach, and has no information about Alice or Bob.

The term onion routing comes from Tor, which is a peer-to-peer internet traffic anonymization protocol utilizing the same premise:

The Bitcoin Lightning Network therefore carries some privacy gains over the plain Bitcoin network.

Regarding the routing problem. There is a straightforward analogy to be made with airplane routing:

If I am traveling between two major cities with little distance between them (e.g. Los Angeles to New York), it is easy to find direct flights from point A to point B.
If instead I am traveling between two minor cities (e.g. Naha, Japan to Hartford, Connecticut), I will need to take a much more complicated route with multiple stops along the way.

The first model is called the point-to-point model, and the second model is called the hub-and-spoke model.

Stage 3: Routing and Capital (Why the Lightning Network Failed)

The principal source for this section is Payment-failure times for random Lightning paths by Abedesselam et al.

Let us return to our multi-intermediary example:

Alice -> Xavier -> Yolanda -> Zach -> Bob

Any reader who has sufficient experience with airline travel knows that lost luggage, extreme weather events, emergencies, multi-hour delays, missed flights, lost/damaged luggage, mechanical failures, and diversions are simply facts of life. Analogous outcomes (i.e. loss of funds) are entirely unacceptable in the context of a payment network.

So suppose Alice wants to send 100 BTC to Bob via this sequence of intermediaries. The lightning network’s cryptography scheme is designed in such a way that either Alice’s funds make it all the way to Bob, or the transaction fails entirely. There is the additional detail of intermediary fees which we will include for the sake of illustration

Alice ->  Xavier ->  Yolanda ->  Zach -> Bob
      103        102         101     100

The manner in which the lightning network prevents loss-of-funds outcomes requires Xavier, Yolanda, and Zach to each front sufficient capital to perform their portion of tranaction themselves. Meaning, Xavier must have 101 BTC to spare that he can set aside specifically for this transaction. Similarly, Yolanda must have 100 BTC that she can set aside. Et cetera. There is the additional detail that all parties (including each intermediary) are required to be online at the time the transaction is to take place, else the transaction fails.

In essence, larger transactions are more likely to fail because it is more difficult to for Alice find a sequence of intermediaries who have sufficient capital and network connectivity to perform the transaction.

By analogy:

it is possible and pretty trivial for Alice to find a route from Naha to Hartford for 1 passenger
it is unlikely that Alice’s luggage will be lost, even with multiple hops
If Alice wants to take her family (5 total passengers) on the flights, the probablity of some delay or luggage loss (i.e. transaction failure) increases slightly but it is still feasible
if Alice’s party includes 50 total passengers, the probability that someone’s luggage is lost, or some member of the party misses a connecting flight, etc approaches 100%.

Suppose Alice and Bob are two random accounts on the lightning network. A 2025 theoretical and empirical analysis by Abedesselam et al showed that, with the real-world topology of the Lightning Network, the network is de facto incapable of performing any transaction for Alice and Bob greater than 100K SAT (roughly $89).

Real economic transactions do not generally occur between two entirely random people on the globe, so the problem is not quite that bad. A February 14, 2025 X post by Amboss (a commercial lightning network explorer service) claimed that in practice a $100 lightning network transaction will fail 23% of the time. That figure is still comically unacceptable for a practical payment service.

References

Assuming an exchange rate of roughly US $50,000 / 1 BTC. Source ↩︎
This is probably why most Lightning Network demos are video games with microtransactions.↩︎
This brings up the more important point: all great ideas are simple. The Lightning Network is extremely complicated, therefore it is not a great idea. Lightning failed because it is not a great idea.↩︎

Why the Bitcoin Lightning Network Failed