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<\/a>, this challenge is analogous to the “last-mile problem” observed in various transportation networks\u2014from telecommunications to roads to airlines\u2014where extending services to remote users is significantly more costly and offers lower returns on investment than infrastructure serving dense, central areas.<\/p>\n As Bitcoiners, we believe in the maxim \u201cnot your keys, not your coins,\u201d 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.<\/p>\n The first area of UX improvement is wallet interactivity. In today\u2019s 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<\/a> 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<\/a> that the receiver can settle payments to without interacting with the sender at all (beyond the normal pre-image reveal). <\/p>\n 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<\/a> 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.<\/p>\n 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.<\/p>\n 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<\/a> 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\u2019s 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.<\/p>\n Essentially, imagine Phoenix\u2019s, Breez\u2019s, or Zeus\u2019s 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.<\/p>\n 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<\/a> 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\u2019s 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.<\/p>\n Mutiny Wallet was an exciting new self-custodial mobile Lightning wallet<\/a>. 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.<\/p>\n 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: <\/p>\n Ecash tokens are not bitcoin, lacking the auditability and verifiability characteristics that make bitcoin specialEach Fedimint depends on a federation of Guardian nodes for its operations, and users have no recourse if the federation steals their fundsIf the federation of Guardian nodes lose data (fully or partial), it’s possible that funds can’t be spent at all<\/p>\n And the good news is that Fedimints work on mainnet bitcoin today! Just last week, Fedi announced that their mobile wallet<\/a> is providing their users (at scale!) with a comparable onboarding UX to custodial Lightning. Cashu is a similar Chaumian ecash protocol<\/a> 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.<\/p>\n For years, developers have mused about connecting Blockstream\u2019s Liquid sidechain to the Lightning Network. In 2024, those musings became reality when Aqua Wallet launched their Lightning integration<\/a> 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<\/a> for a similarly architected wallet called MiBanco.<\/p>\n Similar to Mutiny\u2019s 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:<\/p>\n Sidechains are operated by a federation, like Fedimints, and users have no recourse if the federation steals their funds.Sidechains are blockchains, so the \u201cblockchain interactivity\u201d 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.<\/p>\n 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 \u201cspiderchain\u201d, already has an open source project<\/a> 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. <\/p>\nChannel Factories: The Holy Grail<\/h2>\n
Ecash: The Chaumian Ecash Bitcoin Banks<\/h2>\n
Sidechains: the Federated Bitcoin Banks<\/h2>\n
Ark: the Self-Custodial, Supply Auditable Bitcoin Bank<\/h2>\n