Self-Custody Found Dead in Miami Condo

Matt’s mad again, but for good reason. If you care about bitcoin’s promise, you should be mad, too.

Written by Matt Corallo

When we started Spiral, we had no interest in being another place where a handful of bitcoin developers wrote open-source software they found interesting. Our mandate was to have a larger impact on bitcoin by making it more open and accessible to everyone in a way that neither individual open-source contributors nor unstructured open-source development had before. This meant picking the hardest problem in bitcoin and throwing all we had at it.

After taking stock of the issues facing bitcoin, we concluded that the toughest but most important problem remained building a good experience around self-custody. To truly make bitcoin electronic cash, there had to be a decentralized, private option that offered instant, cheap transactions, genuinely competing with centralized and custodial platforms.

Making Self-Custody Work

Lightning, at least if we built the infrastructure for many competing wallets to flourish, was the only remotely practical candidate that checked all the boxes. We recognized, of course, that there was simply no path to meaningful adoption for something that required a new physical device, a server, or always-on connectivity. With all the challenges that brings, we needed to enable easy Lightning integration in mobile apps.

While we built, Lightning hype came and went. Many individuals spawned nodes and let them wither before shutting them down. Lightning was the future, it seemed. But when it arrived, it wasn’t perfect, so it was a disappointment. Despite this, we continued because a more compelling, decentralized, private, and self-custodial option didn’t exist. On the other hand, much of the bitcoin community, especially bitcoin developers, pivoted. Where there was once an obsession with peer-to-peer decentralized technologies that provide the best experience possible without compromising on bitcoin’s ideals, there is now only corner-cutting.

Trust Implies Centralization

It’s worth first discussing why open-source bitcoin developers, for the first ten years of bitcoin’s life, so rarely cut corners. In my very first post on my blog, I wrote about why decentralization matters. It is, ultimately, key to nearly all of the features that drive interest in and adoption of bitcoin; if we give up on decentralization, we lose the properties that make bitcoin bitcoin. Ultimately, when only highly centralized wallets exist, the inevitable outcome for bitcoin is that it becomes universally KYC and offers no censorship resistance.

Maybe the most pernicious issue is trust. Not only is the ability to transact without trusted intermediaries a key goal of bitcoin, but increasing adoption of trusted systems drives centralization, as trust does not scale. While it’s perfectly reasonable for many bitcoiners to use trusted intermediaries (leaning on trust, after all, makes many things more efficient), there will never be a world with many trusted options.

While a small group of people trusting a service run by a friend is possible, scaling this model to enough trusted services that it can be meaningfully considered “decentralized” is far-fetched. Instead, when counterparty trust is required, we inevitably see massive centralization as people prefer larger entities due to their accumulated social capital. For example, we see this in the financial system, where the vast majority of customer accounts and deposits are centralized in the top handful of institutions, and the long tail of banks and credit unions has comparatively little use.

Given all the excitement around bitcoin finding its “everyday money” moment, it’s no surprise that many are seeking to deliver the absolute best experience, centralization and trust be damned. But sadly, when the competition cuts corners, those who might not otherwise feel compelled to are forced to as well—the most trusted option is generally the most efficient. This seems to have created a vicious cycle where there are only a handful of systems bitcoin wallets are based on, but all of them require enough trust to be irredeemably centralized.

In this domain, Lightning’s lack of required counterparty trust (or at least its ability to operate without counterparty trust) means that it’s possible for there to be self-custody Lightning wallets that are truly peer-to-peer. But here, too, in the search for an ideal and reliable experience, every competitive mobile Lightning wallet relies on a centralized LSP.

The LSP Bottleneck

This centralized LSP isn’t just a theoretical chokepoint for regulatory overhead; it has become one in practice. Many are unwilling to operate an LSP because of perceived regulatory risk. At the same time, this regulatory risk applies equally (and often substantially more) to every other centralized bitcoin wallet technology; startups with new technologies are usually more willing to take on the risk, while those building carefully and deliberately are not. Worse, regulators have increasingly been referencing centralization, not (only) control, when talking about who has KYC and AML obligations. When this view inevitably comes into regulatory force, bitcoiners everywhere will be left picking up the pieces, with a fully-KYC bitcoin being the nearly-guaranteed outcome.

If every centralized wallet backend is required, in practice, to operate with full KYC and AML, any remaining non-compliant backends will increasingly be pushed underground. Bitcoiners migrating to use fully-trusted, often fully-custodial systems operated by anonymous third-parties is obviously absurd, which leaves every trusted system that sees use in practice compliant and antithetical to bitcoin’s principles. This may leave some bitcoin in decentralized cold-storage, but when the only platforms through which bitcoin can be transacted are entirely KYC and AML, such bitcoin is effectively value-less; what is the point of a bitcoin in self-custody if you can’t use it? You might as well keep your bitcoin on paper with an ETF. The only option with any hope is to build on systems that do not require counterparty trust, which can thus decentralize without resulting in substantial theft of funds.

While the push to deliver a flawless experience is generally positive, it can also lead to short-term reliance on centralized providers for liquidity or other features. There must be a clear plan for eventual decentralization to avoid long-term risks. At the same time, these centralized providers can play a useful role by demonstrating demand and attracting new entrants, making them an important step toward that decentralized future.

Relying on trusted services with no decentralized future cannot be our answer. With a new, highly-trusted wallet backend being announced weekly, the bitcoin community’s excitement for existential risk is maddening. While the marketplace will invariably reward the best customer experience, those who know better owe it to bitcoin to discourage this trend, let alone stop building it. The fact that only reckless trusted backends are willing to take regulatory risk isn’t exactly surprising, but this demands an answer from the bitcoiners doing so—why not take less risk and steer towards a sustainable bitcoin?

The Builder’s Responsibility

To the many bitcoin engineers working hard every day to build a future they believe in, how will you decentralize it?