Ark is the third major Layer 2 protocol with some form of unilateral exit or enforcement mechanism on the base layer to approach the point of launching on Bitcoin. Lightning came first when C-Lightning went live in the Reckless campaign in 2018, Statechains in 2021 when Mercury Wallet went live, and now Ark Lab’s coming Arkade wallet implementation of clArk (covenantless Ark) is approaching the same goal line.

clArk has some shortcomings compared to a full Ark implementation, namely the requirement in a trustless version for every user inside of an individual Ark to collaboratively sign the exit transactions in a massive n-of-n multisig when it is created. If we had CTV or another equivalent covenant, users would not need to participate in an interactive signing process, and the Ark Service Provider (ASP) could simply create the Ark using a covenant and users could be sure they have total control of their funds after it is confirmed.

Ark presents an interesting trade off in comparison with the Lightning Network, both require participants to have excess liquidity in order to receive payments. In the case of Lightning however, it is a complicated game of individual users having to figure out where to allocate their own liquidity and how to source liquidity from others in order to functionally send and receive. It is an individual problem that each user is left alone to solve. With Ark, any ASP can freely assign some of its liquidity to any of its users. They still need to solve the problem of sourcing it, but there is no longer the per-user problem of deciding whether it is worth it to allocate liquidity in that direction, it can simply be done in the moment as any individual user needs it out of a common liquidity pot.

There is still a problem with Ark’s liquidity issue though. For every payment floating on an Ark that hasn’t been closed yet, the ASP must front liquidity for those payments to allow users to receive them into a new Ark. When the ASP gets to a point where it is running out of liquidity, its fees must necessarily start skyrocketing in order to manage that issue until they are able to reclaim locked up liquidity by closing Arks.

I think a way to address this tail curve of higher fees could be to explore some lessons from Lightning, namely a routable topology. This would be incredibly simple compared to Lightning. Lightning requires mapping and routing through liquidity paths established between pairs of individual users, whereas with Ark it is simply ASP to ASP.

An ASP experiencing a liquidity crunch could “punt” payments from their own Arks to another ASP with more liquidity available, establishing the ATLC linkage between their own Ark the payment is originating from to another ASP’s Ark to be received, saving users fees. In turn as they are able to claw back liquidity as they close existing Arks and their own fees come down, other ASPs then experiencing a liquidity crunch could “return the favor” by punting payments back in their direction.

This could establish a sort of round robin and easily analyzable “I scratch your back, you scratch mine” dynamic between ASPs, that while leaving some revenue on the table during high fee liquidity crunches, would overall create a more predictable and affordable experience for their users.

This does come with the risk that payments across ASPs like this essentially interlink Arks across different ASPs, meaning non-cooperative closes would necessitate the closure of Arks operated by multiple entities, but given that cooperative closes depend on user behavior I don’t think this fundamentally changes the risk profile absent ASPs intentionally griefing each other. This could be viewed as analogous to the channel jamming problem of Lightning though.

There are some upsides, and potential downsides, but I think this is a concept that is worth exploring in terms of ameliorating Ark’s liquidity crunch issue. 

Custodial Lightning has clearly achieved product market fit. Users benefit from instant Bitcoin payments and minimal fees, while custodians manage the complexities of channel and liquidity management. Major platforms like Coinbase, Cash App, Kraken, and Binance provide over 200 million users with direct access to Lightning payments. While the Lightning Network excels at facilitating payments between custodial wallets, doing so for mobile, self-custodial users is more challenging, particularly during periods of high transaction fees. As Roy Sheinfeld, CEO of Breez, wrote earlier this summer, this challenge is analogous to the “last-mile problem” observed in various transportation networks—from telecommunications to roads to airlines—where extending services to remote users is significantly more costly and offers lower returns on investment than infrastructure serving dense, central areas.

As Bitcoiners, we believe in the maxim “not your keys, not your coins,” so it is important to build last-mile solutions for self-custodied users. Two major areas of user experience (UX) improvements are needed to bring non-custodial Lightning UX on par with custodial UX.

The first area of UX improvement is wallet interactivity. In today’s LN, the receiving node needs to be online to sign a hashed time-locked contract (HTLC) to complete a Lightning payment. This is trivial for custodial wallets, as the custodian is in charge of keeping the node online and connected 24/7, but it is a particularly high burden for self-custodial mobile users. The LN community is making great strides in mitigating this issue. ACINQ and Breez have delved into mobile OS background notifications and generally seem happy with the current state. The Async Payments initiative proposes to let always-online Lightning Service Providers (LSPs) help without introducing trust, minimizing the lifetime of active HTLCs in the network by only forwarding the payment once a client has woken up. Additionally, the Atomic Multi-Path Payments (AMP) standard in LND allows for static invoices that the receiver can settle payments to without interacting with the sender at all (beyond the normal pre-image reveal).

The second major area for UX improvement is blockchain interactivity. Once a custodial wallet is live on the network with channels opened, there is nearly zero marginal cost for onboarding new users. For self-custodial users, onboarding requires one on-chain transaction (generally confirmed on-chain within minutes), which can be expensive depending on fee market conditions. Additional liquidity operations like using submarine swaps to move funds from on-chain to LN, or splicing to resize a channel, also generally require an on-chain transaction (though some cost savings is possible by batching multiple swaps or splices into a single transaction today). ZmnSCP has written a great Twitter thread describing the blockchain interactivity requirements for these liquidity operations today. There are various solutions in progress to mitigate blockchain interactivity for self-custodial LN users.

This essay assumes that wallet interactivity as a UX improvement is solved and focuses instead on the blockchain interactivity aspect of last-mile solutions for LN. First, it will outline the ideal solution, then examine the various attempts in the market today, and finally make recommendations about paths forward.

Channel Factories: The Holy Grail

The most capital-efficient way to run a non-custodial LN wallet business would be to leverage the mythical channel factory (first introduced by Christian Decker, Conrad Burchert, and Roger Wattenhofer in 2018). Imagine a Lightning wallet company and a partner liquidity provider running routing nodes that are already broadly connected to LN. They jointly instantiate a channel factory on-chain by each contributing 5 BTC into a special 2-of-2 multisig wallet. Every time a new user creates a wallet, they are instantly opened a direct channel with one of the routing nodes from within that channel factory UTXO, without requiring any on-chain confirmation at all. Additionally, every time a user needs more inbound liquidity, or the LSP wants to reclaim liquidity from inactive users, the channel splice operation to reallocate that liquidity around can occur without requiring any direct on-chain confirmation. The routing nodes would periodically want to spend the factory UTXO to batch confirm all the off-chain updates, achieving 1000x or more economies of scale compared to today’s operations. Any user that wanted to upgrade to full self-sovereignty on-chain could do so by paying the routing nodes to create them a channel on-chain directly, exiting the factory.

Essentially, imagine Phoenix’s, Breez’s, or Zeus’s UX today if on-chain fees and confirmation times were completely removed from the equation for end users because their routing nodes were able to make channel-related operations off-chain and confirm them in massive batches on-chain when convenient and economically rational. This is the Holy Grail for self-custodial LN.

The ideal channel factory design has not been built yet because it requires covenants. At bitcoin++, Brandon Black presented on the many different ways to make bitcoin scripts that support channel factories with the various covenants proposals, and determined they were all fairly similar in size whether using OP_CAT, OP_CTV and OP_CSFS, or Sighash_ANYPREVOUT. It’s possible that similar UX could be accomplished without covenants by adding a co-signer to the channel factory output with the routing nodes, who would need to be trusted not to collude with them to steal any funds. Instead of waiting for these designs to make it into production, wallet developers have been exploring other solutions.

Ecash: The Chaumian Ecash Bitcoin Banks

Mutiny Wallet was an exciting new self-custodial mobile Lightning wallet. They felt the pain of onboarding users to new Lightning channels in high fee environments, and developed an interesting mitigation to the blockchain interactivity requirement. Instead of each new user immediately receiving their own Lightning channel (requiring an on-chain transaction), Mutiny Wallet defaulted to new users receiving ecash in a Fedimint until they hit a certain threshold, after which they are offloaded to their own Lightning channels.

This design approximated the UX of the above channel factory ideal in that users were onboarded without blockchain interactivity, and ongoing user maintenance (until they crossed the threshold) is abstracted from the blockchain as well. Users simply own a balance of coins with no inbound liquidity requirements, and can settle payments within seconds. Despite these upsides, however, Fedimints do introduce certain trust assumptions:

1. Ecash tokens are not bitcoin, lacking the auditability and verifiability characteristics that make bitcoin special
2. Each Fedimint depends on a federation of Guardian nodes for its operations, and users have no recourse if the federation steals their funds
3. If the federation of Guardian nodes lose data (fully or partial), it’s possible that funds can’t be spent at all

And the good news is that Fedimints work on mainnet bitcoin today! Just last week, Fedi announced that their mobile wallet is providing their users (at scale!) with a comparable onboarding UX to custodial Lightning. Cashu is a similar Chaumian ecash protocol with several wallets in development as well, though generally backed by a single custodian instead of a federation. This is to be applauded, though it is not the only last-mile solution in production today.

Sidechains: the Federated Bitcoin Banks

For years, developers have mused about connecting Blockstream’s Liquid sidechain to the Lightning Network. In 2024, those musings became reality when Aqua Wallet launched their Lightning integration powered by the Boltz submarine swap server. When a new user downloads Aqua Wallet and receives their first Lightning payment, they do not get their own Lightning channel (requiring a mainnet bitcoin on-chain transaction). Instead, Boltz receives a Lightning payment, and pays out LBTC on the Liquid sidechain to the user, who can then either make Liquid payments or pay Lightning invoices by swapping with Boltz again. Unlike with Mutiny, Aqua Wallet users are never expected to have their own Lightning channels, as it is a Liquid wallet with a Lightning integration via submarine swaps. Amboss recently launched the closed beta for a similarly architected wallet called MiBanco.

Similar to Mutiny’s Fedimint integration, this design approximates the UX of the above channel factory ideal in that users are onboarded without mainnet bitcoin blockchain interactivity, and ongoing user maintenance (until they cross the threshold) is abstracted from the bitcoin blockchain as well. Users simply own a balance of coins with no inbound liquidity requirements, and can settle payments within minutes. Sidechains do have their downsides though:

1. Sidechains are operated by a federation, like Fedimints, and users have no recourse if the federation steals their funds.
2. Sidechains are blockchains, so the “blockchain interactivity” requirement is not removed. Liquid has low fees and 1-minute block times, but at scale fees will go up and Boltz is only able to provide instant swaps by taking zero-confirmation risk.

Many more bitcoin sidechains like Liquid will be launching in the coming 18 months (most hoping to use the BitVM project as a way to minimize the trust required in the bridge from the main chain to their sidechain environment), and I expect all of them to support a similar Lightning integration for their users. Botanix, the company building the “spiderchain”, already has an open source project from a community developer implementing such a submarine swap server as a Lightning bridge for any EVM-based sidechain. Hopefully, these sidechains bring many new users to bitcoin, all of whom get a custodial Lightning-esque UX with only the following trust assumptions: their federation is an honest majority, their LN swap server is well-maintained, and that their sidechain does not get congested.

Ark: the Self-Custodial, Supply Auditable Bitcoin Bank

Ark is a relatively new proposal for a Lightning last-mile solution, ideally leveraging covenants opcodes that currently exist on the Liquid sidechain, but would require a bitcoin soft fork on the main chain. Ark’s design depends on a trust-minimized Ark Service Provider (ASP) accepting deposits (either on-chain or via the Lightning Network) from users, processing their transactions off-chain as virtual transaction outputs (VTXOs, which can be thought of as auditable and redeemable ecash proxies), and allowing unilateral withdrawal on-chain. The ASP handles all liquidity constraints, allowing users to receive off-chain without first needing direct inbound liquidity, and periodically refreshes the state of the off-chain system by making just a single on-chain transaction.

Ark designs that are able to leverage covenants opcodes most closely approximate the UX and trust assumptions of the ideal channel factory design. Users can receive to an Ark address from any bitcoin wallet without any interactivity requirements, and the ASP just needs to manage the total liquidity of the system, rather than the liquidity of each channel with each user, simplifying operations. The downside of this design is that the total liquidity requirements put on the ASP scale with the off-chain transaction volume, as VTXOs cannot be reused once spent until the ASP has refreshed the state of the system. This means that if $10M of volume is expected in a one week period, the ASP needs to supply at least $10M of capital for its users (contrasted with LN, where capital can be reused). This downside could be partially mitigated by making each VTXO a Lightning channel, which would make Ark nearly indistinguishable from the ideal channel factory specified above (except for the fact that users would still need to sign on to refresh their VTXO channels periodically).

Ark without covenants, colloquially known as clArk, is also possible but will not provide a comparable UX to today’s custodial LN wallets as it will have significant end user interactivity requirements:

1. Depositing funds into the clArk requires cooperation, so sending directly to a clArk address from a bitcoin wallet that is not running any clArk software will not be supported
2. Receiving VTXOs in clArk is asynchronous as long as the sender cooperates with the ASP in a model similar to statechains (where the coordinator server can steal funds by colluding with a previous sender), but trustless receives require both sender and receiver to be online at the same time
3. VTXO holders must store pre-signed transactions to guarantee their unilateral exit and must come online to sign each refresh period to prevent the ASP from being able to take their coins. The duration of this refresh period is up to each ASP, so the implications for the average user is unclear.

In a way, Ark is a proto-channel factory design. Similar to Ark, channel factories could be built on bitcoin today, but the designs are significantly improved with covenants. It will be interesting to see how the clArk implementations coming to market in the next year or two function as Lightning last-mile solutions, and will certainly help inform those looking at future channel factory designs as well.

Conclusion

The winning last-mile solution for Lightning usage will be the one that provides the simplest UX, the greatest payment reliability, and the lowest cost (both to the user and the wallet operator). Each will require its own integration with the Lightning Network, and there will likely be a power law effect in terms of users onboarded, so speed and go-to market strategy will really make a difference. Today, the simplest UX, greatest payment reliability, and lowest cost generally belongs to custodial Lightning wallets, but there are exciting developments with ecash, sidechains, and Ark that promise to enable a competitive self-custodial Lightning experience. Covenants both enable the platonic ideal channel factory experience, and improve all of these different last-mile solutions. Bitcoin and Lightning are already succeeding in growing into the default value transfer networks for the world, especially with Taproot Assets now available on Lightning (which all of these last-mile solutions will support), but if we want self-custodial users to be first class citizens in this future, we should rally around this vision and continually invest in these last mile solutions.

This is a guest post by Ryan Gentry. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.