As a peer-to-peer (P2P) network, the Bitcoin mainnet has an uphill battle to scale up beyond store of value. Imagine having to spend extra (volatile) fees every time you transact with a dollar online. This is the cost of having decentralized money immune to severe central banking pitfalls.

And many consider it an acceptable cost. A perennial hot issue, Bitcoin block wars birthed Bitcoin Cash (BCH) and Bitcoin SV (BSV) with much larger block sizes to fit transactions, but they achieved little traction. A more likely scenario for Bitcoin scaling will come from layer 2 solutions like the Lightning Network.

Lightning Network addresses the Bitcoin scaling issue, without threatening its decentralization, via payment channels. Through them, on-chain transactions are conducted off-chain as much as BTC funding allows, only to be returned and settled as a batch on the Bitcoin mainnet.

Unfortunately, LN represents an intermediary step, which is itself an inherent obstacle for mass adoption in any human endeavor. Moreover, to transform Bitcoin into a frictionless money (negligible fees), LN has some compromises to overcome, one of which is the “last-mile” problem.

But as we examine it more closely, we can see that the original vision of Bitcoin as a “peer-to-peer electronic cash system” put forward by Satoshi Nakamoto is closer to materializing than ever before.

The Last-Mile Problem in Lightning Network 

For computer networks to be maximally efficient, they need to be maximally centralized. Because a single point of control can coordinate resources and records without having to reach consensus from multiple nodes, its response time is faster while its latency is lower. And if a bottleneck pops up, a centralized network can optimize load distribution to avoid congestion.

This is why a CBDC would be more efficient than Bitcoin as a frictionless money. With that in mind, Lightning Network has what it takes theoretically to equalize the playing field. So much so that the Federal Reserve Bank of Cleveland published a paper in June 2022 titled “The Lightning Network: Turning Bitcoin into Money”.

The paper concluded that “Lightning Network loosens a key technological constraint by allowing payments to be settled more quickly”. However, there is a problem inherent within LN. This “last mile” problem stems from the underlying network design. For instance, for fiber optic internet to be properly distributed from the central hub to individual homes, it has to have add-on infrastructure.

Likewise, distributing goods from a central warehouse, that received its load from trains coming from ports, adds an extra layer of logistical complexity and costs. LN’s last-mile problem comes from distributing liquidity through payment channels. 

When a user opens a Lightning Network channel, they do so by committing BTC funds. This is outbound liquidity that can be sent to the other party.

For a user to receive payments, they have to rely on BTC liquidity locked in LN channels connected to their node. This is inbound liquidity in the LN network.

The aforementioned Cleveland paper described this system as a “net settlement system appended to Bitcoin’s gross settlement system”, with a big caveat that it “economizes on liquidity, but introduces counterparty credit risk”. But why would that be the case?

Let’s say that there is more outbound liquidity across LN channels. This would mean the users’ ability to receive timely payments decreases, therefore erecting the last-mile problem. The solution is obvious - have a custodial wallet that manages users’ liquidity channels under the hood.

But that also means that users lose the key feature of Bitcoin - owning their own funds. For instance, Lightning Network’s Wallet of Satoshi is a custodial wallet that automatically rebalances inbound and outbound channel capacity. 

It can do so through partnerships with other LN nodes that readily provide liquidity infrastructure. Unfortunately, this kind of automated management necessitates relinquishing the control of private keys.

In other words, the custodial Wallet of Satoshi or Blue Wallet solve the huge problem of user experience for LN but they do so at the cost of “counterparty credit risk”. But at the end of the line, even the Cleveland paper admits that “if the LN had existed in 2017, congestion could have been 93 percent lower.”

Fortunately, solutions are on the horizon to address the last-mile problem within the self-custody realm.

Current and Emerging Solutions

As it currently stands, it is not reasonable to expect mass LN adoption, with self-custodial wallets, given the high degree of liquidity management required from users. Theoretically, users could hop onto private chat groups and arrange for channel rebalancing with trusted counterparties to alleviate this problem.

This also isn't reasonable to expect as a standardized practice. But an evolution of this early approach is already here.

Lightning Channel Marketplaces

Obviously, there is a demand for liquidity providers within the Lightning Network. For their P2P payment routing service, they receive incentives via fees. But how does the end user know which fee is best? As always, the solution comes from a marketplace that prices available competing demand. 

Case in point, Magma marketplace has a Lightning explorer Amboss that allows users to buy or sell LN channels across all client types. It has been quite successful so far, having provided 178.96 BTC worth of liquidity over 3672 opened channels.

Although this process is streamlined, it can be argued it is another laborious step detracting from user experience. This is where wallet interactivity comes in.

Wallet Interactivity Innovations

At the time of this article, LN participants who prefer the self-custodial approach have to deal with an extra step beyond liquidity management. Every time users want to complete an LN payment, the receiving node has to be online in order to sign a hashed time-locked contract (HTLC).

True to P2P Bitcoin origin, HTLC makes intermediaries redundant by having conditional transactions. Hashlock requires the recipient to provide a cryptographic proof, as secret preimage, to claim sent funds. On top of it, timelock sets the deadline for the transaction. If the deadline is not adhered to, the sender automatically gets a refund of their BTC funds.

Suffice to say, HTLC significantly minimizes counterparty risk as a trustless mechanism, making it a critical cog of self-custody. On the other hand, custodial LN users can enjoy 24/7 node availability. To equalize the experience, one of the top priorities is to develop Async Payments.

Async Payments initiative would make it possible to initiate transactions even if the recipient’s node is offline. Their load would be taken over by an intermediary node, which only activates once the recipient reconnects to the Lightning Network.

To counter the obvious trust problem of this added layer, Matt Corallo proposed a solution in the form of always-online Lightning Service Providers (LSP). This would work by utilizing LNURL. As its acronym implies, LNURL is an added protocol on top of HTTP that facilitates communication between LN clients. 

LSPs would use LNURL to signal online/offline status of payment recipients. Specifically, LSPs could hold the payment until such signal is received. Once the LNURL signals recipient’s reconnection status, only then the “locked” funds would be forwarded, preserving the self-custodial approach while achieving always-online usefulness.

Because LSPs would not technically custody funds, but only relay the payment forwarding to avoid deadline expiry, they couldn’t even be classified as custodians in legal terms.

Lastly, a new development to improve wallet interactivity comes via static payments. Already possible by v.0.13.0-beta of Atomic Multi-path Payments (AMP), this feature allows users to fragment single payments, then relay them through multiple payment channels.

Because the fragments are simultaneously transmitted, and the recipient can only claim all fragments, the transaction either fails or is fully settled. AMP is a significant way forward because fragments circumvent liquidity limitations of channels. At the same time, a user can issue a static invoice because it can be fulfilled through multiple smaller payments.

Blockchain Interactivity Solutions

While wallet interactivity solutions are promising, even if they are resolved self-custodial LN users still have to deal with the initial setup. Again, custodial LN users have zero costs when their wallets are live because they rely on the pre-established infrastructure.

In contrast, to get going with their first payment channel, self-custodial LN participants, using Phoenix, Zap, Breez or Muun wallet, have to commit to an on-chain transaction, exerting blockchain fees. After all, it is up to them to provide liquidity to be processed off-chain.

The implication of this is that if more payments need to be made to different merchants, self-custodial LN users would have to pay for more on-chain fees, which doesn’t sound like a frictionless money scaling.

The critical remedy to address this problem is the long-standing channel factory proposal, first introduced in 2017’s paper “Scalable funding of Bitcoin micropayment channel networks” by Conrad Burchert, Christian Decker and Roger Wattenhofer. 

Simply put, a channel factory expands multisig allocation of funds. For instance, if there is a 10-of-10 (10 users) multisig factory (address), parties within this shared liquidity pool could commit channels between each other. By doing so, they would not need to broadcast single on-chain transactions, thus evading associated fees.

Channel factory also introduces liquidity splicing, as users redistribute funds between each other, or add new participants, neither of which requires new on-chain transactions. Once they decide to close this shared pool, the final transaction is settled on-chain as a single batch of all the executed LN settlements. 

It is easy to see how such large pools could be erected to form around trading strategies, with trading alerts serving as triggers to commit payments.

Effectively, channel factory approach would remove self-custodial wallets’ on-chain fees and wait-times for on-chain conformations. Although checking all the boxes as the final self-custodial scaling solution, it does require covenants to be deployed.

Covenants as Precursors for Self-Custody at Scale

Because factories are signature-based, they create a UTXO bottleneck. If even a single user fails to sign, the entire channel factory falls apart. In turn, more added users add more failure points. 

The remedy for this are simple covenants with timeout-trees. Theoretically, this would facilitate the onboarding of channels for millions of users under a single UTXO umbrella. Such an approach accounts for casual users, who wouldn’t be required to commit with signatures, while also accounting for asynchronous recipients (they don’t have to be online 24/7).

Instead, these covenants would be managed with timeout-trees. Utilizing conditions and time-locks, users would receive penalties for attempting to put an old state on-chain. Covenant scripts could even be used for invoice data extractions from transaction reports, advanced risk analysis, automated reporting and more.

At present, the covenant-pushing envelope comes from Ark. This project bypasses the custodial trust issues within the Lightning Network by introducing virtual UTXOs (VTXOs). The virtual part is easy to understand through example:

For the deposited BTC, Alice receives a check with an expiry date (time-lock) of four weeks.

This virtual check serves as a payment vehicle, but without requiring interaction with Bitcoin mainnet.

By interacting with the Ark protocol, Alice renews the check’s expiry per monthly basis. Otherwise, the check is automatically redeemed for Bitcoin, on Bitcoin mainnet.

Although a covenant is not necessary for Ark to work, it perfectly complements it if conditions are added to the VTXO script, as off-chain representations of unspent Bitcoin UTXOs. This Ark-based construction of covenants includes a framework where a pre-signage is not even needed to onboard users. 

In other words, users wouldn’t have to interact with Ark Service Providers (ASPs), bringing the user experience on par with custodial wallets. 

Do Emerging Self-Custodial Solutions Matter?

Just like battery costs represent a hard obstacle for mass EV adoption, the Lightning Network faces the same problem when users encounter channel liquidity management. In a world in which most people are accustomed to simply waving Visa/Mastercard near a PoS unit, this is perfectly understandable. 

To resort to manual liquidity management is perceived as primitive and regressive. Therefore, this obstacle overrides the LN potential of upscaling Bitcoin to daily frictionless currency. Custodial wallets circumvented this by getting rid of Bitcoin’s core self-custody feature. 

Yet, users of such wallets are beneficiaries of always-online receive payments as they avoid the burdensome liquidity channels under the hood. With that said, solutions are clearly on the horizon to address both issues, including Zeus Pay that “hodls” invoices utilizing the aforementioned static invoice approach.

Another clever take came from Aqua Wallet by integrating Liquid sidechain with LN. The self-custodial wallet automatically swaps funds to Liquid, as L-BTC, whenever LN users receive funds. To even bolster UX further, Aqua’s Boltz takes care of the Lightning node maintenance.

Where does this leave the LN ecosystem as a whole? In tradeoff territory. Even Liquid sidechain is not comparable to Bitcoin mainnet’s sovereignty. Neither do other solutions provide a clearcut path towards self-custodial upscaling.

In the end, it is highly likely that custodial wallets will remain dominant, estimated at a 1:8 ratio in favor of custodial wallets. This trend aligns with all other human endeavors, where the path with least friction is the most treaded one.