Losing your seed phrase is perhaps a bitcoiner’s biggest fear. And for good reason.

When seed phrases came into existence more than a decade ago, they were a vast improvement in user experience compared to managing raw private keys—strings of hex buried in files or password managers. They gave users a compact, portable, human-readable way to manage keys, a straightforward way to recover lost wallets, and they made the impossible possible—for instance, crossing a hostile border with your wealth memorized. 

But they also created something of a community-wide blind spot. 

Because they’re flexible and theoretically empowering, they became the default solution to every self-custody problem. The industry now treats seed phrases not just as a recovery mechanism, but as the very definition of responsible self-custody.

Implicit here is the assumption that ordinary users can—and should—be the ones responsible for building their own secure and resilient custody solutions from raw cryptographic materials. At each level, security breaks down to some version of “you’re on your own.” For most people, even hardcore bitcoiners, better solutions exist.

Seed phrases hand users the hardest part of the problem: securing them.

You know that, when you set up a hardware signing device, that device securely generates your private key and gives you a seed phrase as backup, so you can recreate those private keys if needed.

Your actual keys are exceptionally secure inside your hardware: purpose-built for security, isolated from networks, physically hardened, access-protected, and able to erase itself after too many intrusion attempts. 

But your seed phrase is none of these things. It’s plaintext, human-readable, physically vulnerable, and instantly becomes the most sensitive part of your entire setup. If it’s ever exposed—even momentarily to a camera or another person—your bitcoin is gone.

So what do you do with it?

Store it at home, and you’re covered against device malfunction, but vulnerable to theft, fire, natural disaster–even something as innocuous as aggressive tidying up. Store it elsewhere, and you mitigate some risks but introduce new ones—loss, surveillance, compromise. Multiple copies means more resilience, sure, but it also means a larger attack surface. 

This is the position a seed phrase places users in. And rather than admit we as an industry have handed them the hardest part of the problem, we call it “personal responsibility”—as if it were a moral virtue, not a design failure. In truth, much of the industry has offloaded the most complex part of the security model onto individuals least equipped to carry it.

Beyond physical security, seed phrase management becomes primitive multisig. 

Faced with the burden of securing what can be meaningful wealth, users are forced to develop their own, homespun solutions.

To mitigate against theft and compromise, users layer on additional protections like encrypting the seed, splitting it into parts, or appending a 25th-word passphrase–turning what was a 1-of-1 system into a 2-of-2 system.

At first glance, these strategies look like thoughtful improvements. But under scrutiny, they all reduce to variations of the same 2-of-2 structure. You now have two secrets—call them A and B—and both must be present to recover your wallet. You have what is essentially a primitive, fragile multisig setup, with none of the recovery benefits of traditional multisig.

The downside is obvious: you’ve created two single points of failure. And more single points of failure are still single points of failure. Lose either secret and game over, your funds are gone.

Improvised or protocol-level, multisig compounds the usability problem.

To mitigate the risk of multiple single points of failure, users fall back on redundancy, creating backups for each secret. A and B become AABB—two 1-of-2s nested inside a global 2-of-2. 

Now you’re designing and maintaining a more complex, highly customized, but still essentially improvised multisig system, whether you’ve intended to or not. But what exactly have you built? How should you reason about the recovery and security properties of that arrangement?

And if that’s where this journey leads, you might as well use the real thing: a protocol-level 2-of-3, enforced by the Bitcoin network itself. But that solution brings its own complexity. Now a user is forced to manage three seed phrases and a wallet descriptor—which, in a way, brings us back to where we started: what do you do with it all? 

Far from improving usability, we’ve compounded the problem.

Even “perfect” multisig has usability problems, particularly for your heirs.

Say you’ve done everything perfectly. You’ve set up a 2-of-3 multisig wallet and secured all the pieces. Everything is working as intended.

Then you lose one key. 

One of my favorite questions to ask bitcoiners is, “Do you rebuild the wallet using the two remaining keys and a new third, or generate three new keys from scratch?”

This isn’t a security question. Both approaches are valid. It’s a usability question—probing which path is better supported by today’s wallets.

The answers are revealing. Most users have never executed a lost-key recovery. Not once. Not even as a dry run. And even under ideal conditions, everyone agrees: it’s hard.

But then comes the real question: “Which approach do you think the person someday inheriting your bitcoin will choose?”

Because the truth is, by giving users seed phrases and expecting them to construct secure, recoverable, inheritance-ready custody systems, we’ve quietly outsourced all the hardest parts of bitcoin ownership not just to users—but to their friends, family, and heirs.

Bitkey represents a new model for safety.

This is the fundamental mistake our industry keeps making: we’ve conflated theoretical security with actual safety.

We treat human error as a personal failing rather than a design constraint. And we call the whole setup empowerment, while it quietly demands users become security engineers, disaster planners, and inheritance experts.

We’ve built systems where the success case is “perfect user behavior” and the failure case is “you lose everything forever.” But bitcoin is meant to be held for lifetimes. And over a lifetime, everyone eventually slips.

That’s why we built Bitkey.

Because systems—not individuals—should bear the weight of security.  Bitkey rejects the assumption of a perfect operator. We refuse to offload cryptographic and operational risk onto users, because that’s not empowerment—it’s abdication. And it’s irresponsible.

Seed phrases are powerful cryptographic primitives, but they are not, in and of themselves, self-custody. Security systems that are defeated by their own usability stop being security. 

We built Bitkey to be practically reliable in real life.  Because the safest place to store your bitcoin should make you feel like an expert—it shouldn’t require you to become one. 

Want to learn more about Bitkey? Visit bitkey.world

Share this post