Solving Bitcoin’s Self-Custody Trilemma

Last week, attackers started draining Coldcard wallets.

A firmware bug made its random number generator predictable, so attackers could recreate seeds without ever touching a device. Losses are past $130 million and still climbing.

My seed was originally generated on a vulnerable Coldcard. The only reason I didn’t lose my life savings is that, years ago when I set it up, I refused to trust its random number generator. I generated 256 bits of entropy on my MacBook, flipped a coin 256 times, and mixed all of it into the Coldcard’s own entropy on the device. Beforehand I did a test run, rewriting the Coldcard’s seed-derivation logic from scratch to verify my additional entropy sources would be combined correctly.

It is absolutely ridiculous that this is the level of paranoid schizophrenia required to not lose your life savings. Nobody should have to do this.

The immediate cause was a bug. The real cause is that our industry’s standard advice puts people’s entire savings behind a single device, and just hopes that its hardware, firmware, supply chain, and random number generator are all flawless, forever.

Everyone is now asking how we stop this from happening again. To answer that, you have to understand why every current option is broken.

Bitcoin’s self-custody trilemma

Today, you only get to pick two. There’s not a single self-custody solution on the market that delivers all three. Let’s walk through the options.

Singlesig (hot wallet or single hardware wallet) is trustless and easy to use. One device, tap to spend. But it’s also a massive single point of failure. One bug, one theft, or one bad backup away from total loss. Almost every Coldcard victim last week was on this edge of the triangle. And lost their life savings because of it.

Multivendor multisig is secure and trustless. It’s also miserable: multiple devices, multiple seed backups, multiple secure locations, multiple PINs to not forget, annual pilgrimages to check nothing has rotted. Recommend this to normal people and you’ll eventually lose more money to user error and lockouts than to hackers. It’s not a realistic option for most.

Collaborative custody (Casa, Bitkey) is where things get genuinely interesting. Casa made multisig something normal people can actually use. Bitkey took the UX further still: no seed phrase, phone-only spending up to a limit the hardware pre-authorized. You only touch the hardware for big withdrawals. It’s cold storage that feels like a hot wallet.

The problem is the trust model. The provider holds a cosigning key and controls the update channel for the phone app that holds one of yours. One malicious app update and they have two of the three keys. I’m not saying this is particularly likely, they’re clearly reputable companies and good actors. But imagine a 6102-style event where private custody becomes illegal and companies are legally compelled to assist with seizure. Their employees aren’t going to prison to protect my stack, nor should I expect them to.

If that threat model sounds absurd to you, Casa and Bitkey are probably the best options available today. They just don’t fit mine. My paranoia already saved my stack once. I’m going to keep listening to it.

Three edges of the triangle, three compromises every current solution makes. That’s the self-custody trilemma.

Introducing Anzen

Like many, I’ve barely slept since the Coldcard incident. My mind has been racing on how to stop something like this from ever happening again. I believe I’ve come up with a novel wallet design that solves for all three points of the self-custody trilemma.

Anzen is designed to be extremely easy to use and very difficult to mess up, it’s genuinely almost impossible to lose your money. It achieves equivalent security to a 2-of-3 multivendor multisig, yet feels as simple as using a hot wallet, and does so while remaining entirely trustless. No third parties required.

It’s a vault-like construct that works on Bitcoin today. No third-party cosigner. No servers. No soft fork. No new opcodes. Trustlessly enforced by Bitcoin’s consensus rules.

Anzen uses only two keys: a phone and a hardware wallet. The vault is your cold storage; the phone doubles as both a day-to-day hot wallet and a vault cosigner. Both keys must be compromised simultaneously to lose funds.

The Anzen vault script is deceptively simple:

Phone + Hardware wallet     immediately
OR
Phone alone                 after 14 months
OR
Hardware wallet alone       after 15 months

Anzen vaults realise Bitcoin’s intended use case of programmable money. They achieve this by composing the script above with varying chains of presigned timelocked transactions. They support:

• Monthly allowances. Each month, a fixed, pre-determined amount becomes available that your phone can optionally pull out of cold storage into its built-in hot wallet, all on its own.
• Emergency access. A larger withdrawal of predetermined size can be initiated from your phone at any time. It unlocks after a one-week delay, during which it can be cancelled. A thief stealing your phone and triggering it just starts a one-week alarm clock you can shut off.
• Revocations. Every pre-authorized allowance can be instantly and permanently cancelled by returning the funds to cold storage.

Think checking and savings. The hot wallet is your checking account. The vault is your savings account. The monthly allowance is an automatic transfer from savings to checking, same amount, 1st of each month. Emergency access is a big transfer request that takes a week to clear and can be cancelled anytime before it lands.

Once a year, ideally on the same calendar date, you re-approve the vault policy on your hardware wallet. This automates a signing ceremony between your phone and hardware wallet that rolls the vault forward (resetting the timeouts) and pre-authorizes an entire year of spending.

For the other 364 days of the year, your phone is all you need. That’s the point. The UX of a hot wallet, backed by cold storage.

Why the claims hold

I want to be precise here, I’m making some pretty strong claims. But I think each one is accurate and relatively easy to verify.

As secure as 2-of-3 multisig. In a 2-of-3, an attacker needs to compromise two of your devices. Your security equals your two weakest devices. Anzen requires compromising both of two fully independent keys on fully independent devices. It’s the same bar, but with fewer things to manage. And like a 2-of-3, it survives loss or exposure of a single key. Anzen even has an optional social recovery path that allows recovering from losing both devices. This is even stronger loss protection than a 2-of-3 multisig.

Whatever goes wrong with one key, the other key wins:

You really have to try hard to lose your money with Anzen. As long as you don’t walk down the street blindfolded, arms outstretched, unlocked phone in one hand, unlocked hardware wallet in the other, you should be good.

Trustless. There is no third key, no cosigning server, no company update channel with power over your funds. Even the recovery mechanisms add no trust. The cloud backup is your phone key, encrypted so that only your hardware wallet can decrypt it. Social recovery just adds another copy in your cloud, encrypted to a trusted contact’s key: they hold nothing, and don’t even know they’re your recovery contact unless you tell them. They just help you decrypt your cloud backup if you lose both devices. Even then, a recovered key still has to wait out the vault’s timelocks.

Every way the money can move is written into a Bitcoin script you can read, or a transaction your own hardware signed. Nobody can be subpoenaed into your wallet, because nobody else is in it.

Easy to use. With a well-configured policy the hardware wallet needs one approval a year. Every other action is controlled from your phone. That makes Anzen less effort than a singlesig hardware wallet, which needs the device in your hands for every single spend. Day to day, Anzen approaches hot mobile wallet usability.

“But pre-signed transactions sound complicated”

Under the hood, yes: the annual ceremony splits the vault into chunks and pre-signs a carefully structured set of transactions. But none of that ever needs to reach the user. This is purely an engineering problem, and a very solvable one. The same way nobody needs to understand how to perform Diffie–Hellman key exchange to use HTTPS, no one needs to understand how to manage a presigned transaction chain to approve a vault policy with Anzen.

The real gap is hardware. No hardware wallet today properly supports this class of design, because they’re all built around one primitive: sign this transaction. The primitive we need is: approve this policy. Your phone drafts the plan, the hardware wallet’s screen shows you the whole thing in plain language. The vault policy screen on your hardware wallet is to Anzen what the green padlock is in the browser to HTTPS.

Anzen Annual policy

Vault balance 2.1 BTC

Monthly allowance 0.1 BTC

Emergency access 0.5 BTC1-week delay

Approve?

Reject Approve

One button press pre-signs the entire year. Here’s exactly what the above would output:

Every transaction the vault can need for the next twelve months, signed in one press: the monthly allowances, the revocations that can cancel them, and the emergency package. The phone stores them encrypted and uses them to run the vault for the rest of the year, the hardware wallet goes back in the drawer and is not needed again until the same day next year.

Where do we go from here?

This is not just an idea. I have a working prototype running on mainnet with real funds, with all vault functionality and recovery paths fully implemented. It’s definitely not production ready, it’s very early, but it is (just about) usable if you want to test with small amounts of money.

There is also an extensive end-to-end test suite that runs on regtest if you want to see the full functionality without risking funds, and an interactive CLI that fully emulates a phone, a hardware wallet, and all operations between them.

Here’s my mainnet vault, you’re warmly invited to try and rug it:

bc1pvaultn3953ns47dw6rpm6ahfpz449vcnns5rpnr5v2d0u55fekxq39v257

I would welcome technical peer review and I’m open to any feedback. The repo is very scrappy for now, but feel free to point your agent at github.com/lukechilds/anzen and ask it to walk you through the design.

While it’s just a CLI for now, I’ll be working on a full-stack reference implementation for Anzen to fully demonstrate how slick the UX can be. This will likely be an iPhone app and a custom sideloadable companion Ledger app.

My goal is to develop both the reference implementation and the open Anzen protocol. The idea is that anyone can implement the protocol. If I can validate the use case with the reference implementation and people see value in this and it gains any traction, potentially we could see a future where you could create an Anzen vault on a vanilla Ledger paired with Ledger Live. Or a Trezor as the hardware wallet signing side and BlueWallet as the hot wallet side. Or Bitkey supporting an optional sovereign mode that replaces their cosigner with Anzen’s consensus-based alternative.

Anzen is being developed as a personal side project, unaffiliated with Umbrel, open source and MIT licensed.

Credit where credit is due. Thanks to Casa, Bitkey and Liana for dragging Bitcoin self-custody into the modern age. Anzen’s design is heavily inspired by tricks pioneered by those three teams.

Final thoughts

The Coldcard situation is extremely sad because the Coldcard users did everything right. As far as I’m concerned, the industry standard recommendation was a singlesig hardware wallet. While this issue manifested as a firmware bug in the Coldcard, this is ultimately a catastrophic failure of the Bitcoin technical community. We have done users a disservice and failed to provide good high quality self-custody tools.

Since the incident I’ve seen people claim self-custody is not suitable for most users. I’ve seen people claim everyone should be moving to multivendor multisig. I’ve seen people claim it’s the user’s personal responsibility to educate themselves on secure entropy generation. This is disappointing. We are repeating the same mistake.

Bitcoin’s scripting capabilities are limited, but they are not that limited. Vault-like constructs are criminally underexplored.

We have the tools to build better self-custody solutions. We just need to start using them.