Lightning Network Liquidity


Bootstrapping Problem

Note that routing nodes are not compensated on an ongoing basis, and are not compensated for anything other than a completed payment. As a result, many routing nodes may be allocating capital in a non-productive manner as they’ve speculatively opened channels to areas of the network where no true transaction demand exists. If the Lightning Network was a physical transportation network, then it would be as if eager contractors started building roads to seemingly random destinations, only to find that those roads weren’t actually demanded at all. This information asymmetry (where new channels are actually demanded) and the current inability for today’s network participants to exchange these key demand signals lies at the crux of the bootstrapping problems of the Lightning Network.

From the perspective of attempting to achieve a similar user-experience as a base Layer 1 system, the receiving constraint is the most challenging. Notice that a user cannot simply download a Lightning wallet and start receiving funds. Instead, they need to first solicit inbound capital to their node first. Many wallet providers such as Breez and Phoenix have started to overcome this issue by committing capital to the users themselves. This is essentially a customer acquisition cost: by providing this inbound bandwidth to users, the wallet becomes more attractive as it enables both sending and receiving. However, just receiving isn’t enough. A user needs to be able to send and receive. In addition to this required symmetry, a typical user also has all the same quality of service, and time-committed capital requirements as well.