What the Coldcard Exploit Teaches Us About Self-Custody

There are ways to protect private keys that do not create single points of failure.

‍

The recent Coldcard firmware exploit drained more than $100 million from user wallets and is a blow to the credibility of self-custody generally (i.e. holding private keys in your own wallet).

A firmware bug weakened seed generation on some devices, so attackers could reconstruct candidate keys and use Bitcoin's public ledger to spot which wallets still held money. Some people lost heartbreaking amounts.

And unlike other exploits that we have seen, in this case many of the victims did exactly what security experts have told people to do. They bought what they thought was respected hardware, kept it air-gapped, never typed the seed into a computer, and never handed it to anyone. 

It is harder to persuade someone to take responsibility for their own keys when careful users can follow “best practice” and still lose their savings.

Coinkite, the company behind the Coldcard hardware wallet, disclosed the problem July 30 and published a detailed technical account. Those details matter. But the incident also points at something bigger than one product. 

Self-custody in 2026 still often comes down to one device holding one secret. This article looks at what that setup gets wrong, what should change, and how a different approach can protect users better.

One secret is too much to carry

With the Coldcard hack, very little had to go wrong for everything to go wrong. The key generation step produced a weak seed, a single key was enough for the hacker to move everything, and that one invisible flaw led to the losses.

There was nothing for the owners to catch either. Entropy (i.e. the degree of randomness, a critical factor when generating a cryptographic key) is not something you can easily inspect from the outside, and a mnemonic seedphrase from a weak source reads exactly like one from a strong source. There was no self-test to run before the first deposit.

This is a design issue more than a vendor problem. When one implementation, one device, and one secret carry an entire account, every single one of these components has to be perfect and stay perfect. It creates a single point-of-failure, so any error, big or small, can have dramatic consequences.

A single secret should not be the only thing standing between users and life-changing losses.

Self-custody should be layered

A better version of self-custody would not be monolithic and binary. Protection can be built in layers, so if one part fails, another can keep the account safe, or at least limit the damage.

Ideally, users keep cryptographic control of their money through more than one independently generated key. That way, a flaw in any single key is not enough to authorize a transfer, and an attacker who compromises one key still faces a threshold they cannot meet.

In fact, the Coldcard story comes with direct evidence that the multi-key part works. People who held their affected key inside a properly independent, multi-vendor multisig were protected, because that one weak key could not meet the signing threshold by itself. 

One important caveat: keys need to be independent. Two keys generated by the same implementation on the same kind of device can share the same flaw, which would defeat the purpose of adding another protection layer.

Privacy means targets are harder to find

Privacy also matters in this discussion. On Bitcoin's public ledger, a hacker could derive candidate addresses for each guessed key and immediately check which ones hold money, turning a pile of weak candidates into a sorted list of victims.

The visibility of balances gave the attacker a way to test each candidate and focus on the ones worth targeting. Without that public confirmation step, exploiting weak keys becomes a much less certain and more expensive exercise.

Keeping balances and account data private does not prevent weak key generation. It does, however, make vulnerable accounts harder to identify and exploit.

Privacy also needs to be programmable

Privacy makes accounts harder to target, but programmability lets wallets limit what happens if attackers still compromise a key. Accounts can enforce spending limits, delays before large transfers or key changes, and additional approvals for sensitive actions.

For instance, Bitcoin already supports multisig and timelocks, but its scripting model is not “programmable enough” for more advanced wallet policies.

Some vault designs can be built using Bitcoin’s existing protocol features and presigned transactions, yet more flexible vault policies would likely require proposed upgrades such as covenant opcodes or OP_CAT, an infamous opcode whose return has been debated among Bitcoin developers for years.

Whatever the mechanism, these controls should preserve privacy.

On Miden, accounts are programmable and private by default: account data stays on users’ devices, while the network verifies commitments and proofs rather than publishing it. For a more resilient form of self-custody, though, one more layer is needed: checks on both keys and transaction policies before funds move, without handing over control of users’ funds.

Adding protection without giving up self-custody

Miden's Guardian approach puts the layered self-custody model into practice. A simple reference setup uses three keys: a device-bound hot key for everyday use, a seedphrase-based cold key users keep for emergencies, and a Guardian operator key for co-signing and coordination, with 2-of-3 authorization.

For this reason, compromising the everyday device or hot key is not enough to move funds, because the Guardian key provides an independent second check.

Guardian operators cannot spend unilaterally either. Users keep an independent recovery path and can switch operators using keys they already hold. Added protection does not come at the cost of handing over custody.

Our architecture also opens a path to spending limits on an everyday key, delays on high-value actions or key changes, emergency freezes, and other policies based on users' preferences. Each of these can reduce the blast radius of a compromised device or key, without giving the operator unilateral control of the funds.

It is still self-custody, but a safer form.

Using Miden and Guardian together adds privacy, recovery, and protection from a single compromised key without taking the assets back into custody. After a terrible incident like the Coldcard exploit, this is an approach we hope more teams will consider and emulate.