Over the past few years Bitcoiners went from dismissing Lightning to cheering on custodial solutions. While many of those solutions have great properties and make sense for low-balance wallets, we shouldnât lose sight of the goal - great non-custodial UX that Bitcoiners actually *want* to use.
Luckily we have the tech for it (now), we just need the motivation and resources to build great wallets using it!
https://spiralbtc.substack.com/p/custodial-solutions-are-not-solutions
You can also read this on my personal blog if you want to avoid all the JavaScript and Substack tracking, though then you wonât get to read all the great other content from elsewhere at Spiral.
https://bluematt.bitcoin.ninja/2025/02/19/custodial-solutions-are-not-solutions/
Excellent post, and a timely one too (see my other notes today đ)
A self-custodial Ark wallet allows users to interface with Lightning payments via swaps in a perfectly non-custodial manner, without exposing them to the friction of channel or liquidity management, or overcharging them to abstract those.
It is the best self-custodial Lightning experience you can possibly create, bar none.
Every Ark builder is interested in complementing Lightning and leveraging the synergies between both technologies. It's a shame you can't recognize the potential here.
Except self-custodial Ark has LSP liquidity requirements wayyy too high to be practical. Instead, Ark is moving in the direction of building on the statecoin trust model, which is directionally custodial.
You clearly havenât given this much thought.
I can open a single channel towards an LSP and make unlimited number of payments, in Ark, without any liquidity requirement aside from the initial deposit.
Thatâs fine either way. Iâll work with people to build a Lightning enabled wallet that blows native ones out of the water then we can check back on the âliquidity issuesâ.
You can do LN-on-Ark, indeed, which addresses some of the Ark LSP liquidity issues (without the trust model tradeoff), though you still require somewhat more liquidity than lightning natively, which seems pretty expensive.
My understanding was that no one was bothering with that since statecoins-on-Ark was simplerâŚ
This is not LN on Ark this is just a normal spillman style payment channel.
I fail to see how this is more liquidity than LN. Itâs infinitely better for LSPs who donât have to tie up liquidity in channels with random users. Now that is expensive (Phoenix)
Indeed, thatâs a bit better, though itâs still not a lot less than LN. If a user receives X sats, the LSP has to allocate at minimum X sats for the Ark transaction (and needs to complete that Ark update pretty quick, maybe in under a second or so, but that doesnât require liquidity). Now if the user sends X/2 sats, the LSP is providing X/2 sats in liquidity (same as LN). Maybe itâs better because itâs a bit easier to under-allocate up front, but Iâm not sure that that was a major part of the total lightning LSP float to begin with.
That said, Iâm curious how you handle the ghettoization attack? That seems pretty nasty especially if youâre really strictly not over allocating liquidity.
