Bitcoin is a long game. Consider these 21 moves to make during the downturn.
In the world of bitcoin, we often like to think of ourselves building a totally new world of finance, unlocking the power of programmable money. But when we look at the value that’s being built on top of bitcoin today, are we seeing a technological revolution or simply an evolution of pre-existing models? What I would like to argue for is that we should consider that programmable, self-sovereign money gives us the opportunity to build more than just the same business models that we had before with a different asset swapped in.
A true technological revolution is when people and businesses start to create new habits, engaging with technology in entirely novel ways. Building bitcoin-native infrastructure means providing new ways in which clients can engage with financial services. This in turn means you don’t just have new economic activity in terms of net new businesses, but businesses and relationships that weren’t even possible before.
To model what can be possible, let’s start by walking through the evolution of keys.
In the beginning, there was an unlinked cluster of public and private key pairs, and it was… not great. They were hard to back up and recover. There was no way to interact with them in a programmatic way without direct access to the raw data.
Then came HD Wallets and Extended Public Keys (aka xpubs) and for a time it was good. Backups with human-readable seed phrases became possible. You could separate the information you needed to keep secure (private keys) and allow the more public data (public keys) to be more portable. Code could also now interact with keys in more creative ways.
P2SH (Pay-to-Script-Hash) gave us new ways to interact with our keys, most importantly multisignature. By building on top of the power of HD Wallets, we get a different mental model for the interplay between keys for creating even more complex wallets.
More recent developments in standards such as miniscript and descriptors helped unlock the power of existing opcodes in more robust ways allowing for even more complex relationships between keys, for example across not just seeds but even time.
Naturally, as the modeling of the public/private keys that secure our bitcoin evolved, so too would we expect how we leverage those technologies to custody our bitcoin.
In the beginning, everything was self-custodial and, for a time, it was pretty good. This was, and remains, the highest agency form of custody. But, with great power comes great responsibility. When all of your bitcoin is backed up by a wallet.dat file, you are responsible for keeping that data safe. This means no one can confiscate your bitcoin (absent force) but it also makes the risk of loss much higher (just ask those of us dumpster diving for lost harddrives).
The risk and complexity of securing bitcoin keys on our own led to the rise of the Wild West of fully custodial service providers. This made it easier to onboard non-technical newbies, but it also centralized risk largely amongst inexperienced and irresponsible actors, resulting in some very high profile losses.
But of course, markets inevitably evolved over time and as the market for bitcoin custody evolved, service providers matured. Loss from theft or software error at large, regulated exchanges is near zero and for the most part these entities can be trusted with your bitcoin. Security best practices have improved with better internal and client-facing security protocols coming to market. There’s even insurance now that consumers can get as a backstop.
Single points of failure in this model however still largely remain. From online account compromises to government seizures to social engineering attacks, it’s a dangerous world out there. Furthermore, no matter how the custodian secures the actual private key data, this custody model is still fundamentally a single signature form of custody: your login and account access functions as the private key in that it controls access to the funds.
From account level addresses and balances we move to vaults built on top of collaborative custody. If you’re reading this, you’re probably here on your custody journey. Collaboration with a key agent leverages the security of multisig combined with the convenience of a custody partner. Many commercial frameworks, including those at Unchained, put a trusted third party as a minority holder of keys, establishing a partnership for security, recovery, and institutional safeguards.
While the account itself may no longer be a single point of failure as the ability to login or prevent login does not in and of itself dictate control of funds, the account holder themselves still is. Vulnerability to social engineering attacks remains a serious threat as does catastrophic loss from negligent storage of key material (a risk that does not exist in the traditional custodial model).
The true strength of collaborative custody comes when we move beyond the static vault and into the dynamic realm of open standards and networks. A system built on networks, i.e. relationships between distinct and distributed nodes, is more portable, more composable, and ultimately more robust.
What does it mean to build the infrastructure for a technological revolution in this context? Just as networked communications with the Internet brought about entirely new ways for individuals and institutions to interact, in bitcoin custody they can allow platforms to move beyond simply the guarantor of your security into enabling it in ways that fit your needs.
Let’s look at some of the ways in which longstanding technologies and standards in bitcoin can help us build these totally new business models.
Trust is often treated as a dirty word by bitcoiners. But it doesn’t have to be this way. One of the strengths of networks is in how they introduce redundancy. You are no longer as weak as the weakest link in your security posture. When you leverage trust by establishing a network of key holders with different security postures, risk becomes distributed while the security compounds.
By tapping into one’s network for key security, you can remove the risk that exists at the account holder level. Someone who believes that they might be at risk of social engineering attacks can tap a family member (the proverbial Uncle Jim) to be one of their key holders. This family member’s security may not be as strong as an institution that’s securing billions of dollars worth of bitcoin, and there is a dependence on a certain amount of trust in this individual, but in a 2-of-3 arrangement, multiple leverage points would need to be targeted to carry out a successful attack. With social engineering attacks usually relying heavily on manufactured urgency or carefully building trust over time, this becomes orders of magnitude harder to pull off across different people and contexts.
Perhaps even more importantly, viewing bitcoin custody through the lens of networks allows us to completely rethink existing business models and how to build a platform that can enable them. Consider a Donor Advised Fund where, rather than just trusting them with your funds, you join their network, sharing your own key that helps secure the funds to be distributed not just for making charitable donations but even paying fees. The network makes you an active partner rather than a passive observer of your donations.
Security through composability isn’t just about the “Who” of your network, but it’s also about the shape of it. When designing your quorum, less is often more. In the majority of cases, 2-of-3 is more than sufficient, and multi-agent key sharing can make this model even more robust. There are some scenarios, however, where different quorum topologies make sense.
We can think of this set of tradeoffs as a comparison between Sovereign Access (you can move funds independently) vs. Agent Failsafe (a key agent can act independently). Sometimes a security posture of a quorum that is both self-managed and agent managed, i.e. a 2-of-4 arrangement, where you can recover funds without 3rd party assistance but the key agents also can manage a recovery on their own, has its benefits.
Unlike with the traditional banking system, bitcoin native financial services means building a platform on top of open standards and open source code. Platforms should not require you to access their walled garden in order for you to interact with your money. The more portable the interactions, the broader and more robust your network can be, and the more aligned are the incentives
An example is building custody on top of standards such as descriptors, which allow users to take their wallet anywhere that speaks the same language. The ability to interact with your wallet without access to the walled garden of your account means being able to:
PSBTs, or Partially Signed Bitcoin Transactions, are another example. If transaction data, i.e. inputs, outputs, and signatures, can be transmitted using an open serialization standard rather than relying on proprietary APIs, it further expands the way you can engage with your bitcoin custody. Our recently developed PSBT-upload-based transaction creation (available by request only) means that you can not only engage with your wallet anywhere, but also with transactions themselves anywhere. This can enable air gapped transaction creation and signing, sending transactions over email, or the ability to create and sign transactions externally while still able to tap into your platform-based key agent network to request signatures. These new standards bring to bitcoin infrastructure what TCP/IP brought to the internet. Now we have a standard way to network Bitcoin-native institutions so that individuals can now incorporate institutional security in our own custody.
The important throughline for all of this is that a truly bitcoin native platform for financial services is built on open standards and shouldn’t force users into a model or platform. The endstate for true open infrastructure is the development of user experiences and businesses that couldn’t have been possible before.
With the caveats that this is not legal advice and purely hypothetical, let’s envision a business and client relationship that couldn’t exist without bitcoin native solutions.
Let’s say you’re building a company that provides client-controlled, bitcoin-backed HSAs. You believe that the most secure option for your target client base, who is not very technical, is 2-of-4. You want to provide sovereign access so clients can always spend on their own, but also provide them with an agent fail-safe such that their funds can always be accessed were anything to happen to the clients’ keys. You want to reduce your own liability of having unilateral ability to move funds, sharing key agent responsibilities with the platform provider (i.e. Unchained as we do with DAFs).
The setup process involves you as the service provider asking a client to share two public keys with you. Since the public keys can be shared publicly, clients can share keys that are actually controlled by other people or entities. The client could decide they want to further delegate one or both keys to someone else entirely and share the xpubs of those keys with you. Once you have the keys, you create the vault and manage funding strategy out-of-band.
But how might clients interact with your business? You could have it all within the service provider’s ecosystem (i.e. unchained.com) but you think it would be better to have a more tailored experience for the day-to-day. So you ask your trusty AI coding agent assistant to throw together an app that supports the import of JSON wallet configuration files. You want this setup to connect to your own bitcoind instance via RPC rather than trusting someone else’s node. It should be able to generate new addresses and can create tax reports at the end of each year based on balance changes.
What if you need to collaborate on signatures with a provider that isn’t onboarded into your system? That’s where PSBTs come into play. PSBTs can be created anywhere by anyone with access to the available UTXOs. Your system can be responsible for building out transactions for signing and even gathering the first signature before bringing it over to the Unchained system to request additional signatures.
There’s a lot more you could do here, like variable quorum options, device-less xpub sharing that decouples the user from key sharing even further, or even the business sharing their key with the clients enabling more privacy for the client, only sharing wallet details as necessary. The power of networks and open standards is pretty clear. Bitcoin flipped the script on monetary power dynamics. Networks of bitcoin users can do the same for our financial system.
