Catch 22 of Lightning Network: Inbound Capacity

Egor Homakov
Jun 21 · 5 min read

Catch-22s often result from rules, regulations, or procedures that an individual is subject to, but has no control over, because to fight the rule is to accept it. Another example is a situation in which someone is in need of something that can only be had by not being in need of it (e.g, a bank will never issue someone a loan if they need the money).

Catch 22 is kind of a scenario where a problem cannot be solved because the solution to this problem implies a contradictary condition (like, not having this problem to start with).

Here is me talking about inbound capacity:

Now, once the problem is obvious to everyone, we see some newer articles:

All the “solutions” shown there have been proven to not work in real life. Lightning Network has been dysfunctional, even though the total network capacity, number of nodes and channels has gone up — those can be artificially increased very easily and don’t demonstrate its actual usage.

The main functionality of a payment network is lacking in LN: most users are unable to receive payments due to lack of inbound capacity. That’s like saying “Youtube is going to grow soon, we just gotta figure out how to let users upload videos”.

What’s the catch?

For a new project to grow it must have a clear onboarding technique to increase adoption. To have an explosive growth it must work like a charm.

With Facebook or Twitter you just create an account and post something. Or follow someone in a click.

With Paypal or your bank accounts you just register it and receive the money.

With LN, nobody has an idea how new users join the network. There’s no “one size that fits all”. Unlike Paypal, original LN design does not allow a new user to receive a transfer.

In order to get a transfer the user must have some inbound capacity from other nodes (hubs).

Imagine, Mastercard/Visa were required to send $10k in cash every morning to every cafe, and in the evening get the leftovers back. This is not a scalable model, and no payment gateway has interest in risking their own assets. This bank->merchant workflow has been simple for centuries: first we promise, then we settle.

In LN the hubs have no incentive to invest in the new relationship.

The articles above suggest the tricks that are inherently catch 22: they cannot be implemented because they directly contradict themselves.

  • “Spend some assets to get an inbound capacity”. First, it implies the user having some assets to start with (an onchain transfer is required to onboard?). Second, in requires the user to spend when they might just want to receive. Does Paypal instruct me to spend $100 on T-shirts to get $100 for a freelance job I’ve just done? I just want the money, now!
  • “Buy/rent the capacity from some hub”. Thor, LNbig, LightningTo.Me and a few other services suggest to pay them a small fee to rent the inbound capacity towards your node. First, it again requires you to have some assets to start with (catch 22). Second, the hub will never have enough funds to satisfy everyone’s inbound capacity needs, and their liquidity can be routinely exhausted. Third, would you use Paypal if it charged you money _before_ you were able to receive some? Sounds like nonsense to me.
  • Autopilot. Autopilot is just sad. It doesn’t fix anything, doesn’t increase capacity to new users, rather to popular and already well connected nodes. I have no idea why it exists.
  • Submarine swaps. Again, they require you to have assets to start with.

The Solution: Credit Layer

After a year on mainnet, Lightning cannot grow. Not because the tech is bad, not because the UX is poor, but because of the fatal flaw in its design, a catch 22: new users cannot receive transfers until they spend themselves. This drastically limits network growth.

The users don’t care about subtle intricacies of the protocol. They want a working payment network that they can rely on to send money to anyone.

A payment network that’s incapable to transfer money and that doesn’t have a clear onboarding strategy is doomed to fail.

The answer to inbound capacity is using credit limits, as outlined in . XLN mimics the existing banking topology and uses both collateralized and credit promises, instead of relying purely on collateralized assets and being stuck in capacity.

XLN on BTC

Unfortunatelly, BTC design does not support standalone identity, debt database and therefore enforceable credit limits. Which means today, the only way XLN can be implemented is by adding fully custodial credit lines. This way the hub receives collateralized assets but sends custodial promise to the destination — kind of like .

The safer way to implement credit would be to introduce some kind of Debt Requests into the onchain layer. Similar to bank levies in the traditional banking: if you ignore your loan to bankB, they go to bankA and forcefully take your assets. Similar technology is required to ensure the hubs don’t cheat on its users and honor the signed custodial assets.

Bottom line: stop worrying will the network be centralized or not, make sure you develop a system that can grow and has a clear onboarding plan. Stop doing premature optimization and focus on smooth core features: paying and receiving. All those Watchtowers, autopilots, swaps and AMP are unnecessary features because at some point the network won’t have any user and the project will be forgotten.

Egor Homakov

Written by

Developing Fairlayer