When the Randomness Fails: The Coldcard Entropy Bug and What Two Devices Change

At the end of July 2026, attackers began draining Bitcoin from thousands of hardware wallets that had done nothing wrong. The owners had followed the advice. They had bought a dedicated signing device, kept the seed offline, never typed it into a website. None of it mattered, because the seed those devices generated had never been as random as it looked.

Roughly 1,816 BTC left more than 5,200 addresses across four waves. It became the largest hardware wallet exploit of the year.

This article is not a victory lap. The bug involved is one that could have happened to almost any wallet, including ours, and the interesting question is not who shipped it but what a wallet's architecture does when it happens.

What actually went wrong

A single commit, in March 2021.

Coldcard's design called for seeds to be generated from a hardware random number generator — a dedicated chip producing entropy from physical processes. That is the right way to do it. But a change in firmware 4.0.1 routed seed generation through a software pseudorandom number generator seeded from public, hardcoded constants instead.

A PRNG is deterministic by definition. Given the same starting value, it produces the same sequence forever. So a seed generated this way is not a number nobody can guess — it is a number drawn from a set small enough to search, using constants that were sitting in the published firmware the whole time.

The devices kept behaving normally. They displayed twenty-four words, wrote them down, derived correct addresses, signed valid transactions. There is no screen on any wallet that shows you how much entropy went into your seed. Every affected user had a device that looked and behaved exactly like a working one, for up to five years.

The window ran from firmware 4.0.1 in March 2021 to 4.1.9 in July 2026. Updating the firmware fixed generation going forward and did nothing whatsoever for seeds already created — those keys were already weak, and no update can retroactively add randomness to a number that has already been written on a card in someone's safe. Affected users had to generate a fresh seed and move their coins.

Why weak randomness is total, silent loss

It is worth being precise about why this class of bug is so severe, because it is not intuitive.

A 24-word BIP-39 seed represents 256 bits of entropy. Guessing one is not merely hard, it is unimaginable — there is no computer, present or future, that brute-forces that space. This is the foundation the entire self-custody model rests on: your key is safe because it is one of an incomprehensibly large number of possibilities.

That guarantee is not a property of the words. It is a property of the process that chose them. Twenty-four words drawn from a weak generator look identical to twenty-four words drawn from a strong one. They pass every checksum, produce valid addresses, and restore perfectly on any wallet. The only difference is that someone else can also arrive at them.

So the failure is invisible from the inside, and it is complete. Not "an attacker could steal from you if you make a mistake" — there is no mistake to avoid, no phishing link to decline, no confirmation dialog to read carefully. The money is takeable at the attacker's leisure, and the first sign anything was wrong is that it is gone.

What two devices change

Here is the part that matters architecturally, and I want to state it precisely rather than in marketing terms.

SSP is a 2-of-2 multisig. Funds live at an address controlled by two independent keys, generated on two independent devices — one in the browser extension, one in the SSP Key mobile app — and a transaction requires both signatures. The two-of-two arrangement is the whole basis of the wallet.

Now run the Coldcard scenario against that structure. Suppose the extension's seed generation had the same flaw, and an attacker can derive your browser key completely.

They still cannot spend anything. They hold one of two required signatures. The address does not release funds for one key, no matter whose key it is or how they obtained it. To move your coins they would need to independently and simultaneously break the key on your phone — a different application, a different operating system, a different entropy source, generated at a different moment.

That is the structural difference. In a single-key wallet, a weak seed is total loss. In a 2-of-2, a weak seed is a serious problem that is not, by itself, a loss.

The caveat, stated plainly

It would be easy to stop there and let you conclude SSP is immune to this. It is not, and pretending otherwise during someone else's incident would be exactly the wrong moment for it.

Both SSP applications use the same BIP-39 implementation — @scure/bip39, pinned to the same version in both. A flaw in that library itself would affect both keys. The independence SSP gives you is real but specific: two separate seeds, generated at different times on different devices, drawing entropy from different operating-system sources — the browser's Web Crypto on one side, the mobile platform's CSPRNG on the other. It is not the independence of two entirely unrelated codebases.

What that buys is protection against the failure mode that actually occurred at Coldcard: a device-specific implementation error in how one product generated its seeds. It would not protect against a defect in the shared cryptographic primitive underneath both.

That is a meaningfully weaker claim than "this cannot happen to us", and it is the true one. Anyone telling you their wallet is categorically immune to entropy failure is telling you about their marketing, not their architecture.

What to take from it

If you hold a Coldcard from that firmware window, the only safe assumption is that the seed is compromised, whether or not funds have moved. Generate a new one on patched firmware and migrate. A device that has not been drained yet is not a device that is safe.

If you use any single-key wallet, this is the risk you are carrying, and it is worth being conscious of rather than anxious about. Hardware wallets remain vastly better than the alternatives for most people. The lesson is not that they are bad; it is that a single key is a single point of failure, and every part of that key's history — including the moment it was born, years ago, in firmware you did not read — is part of your threat model.

And in general, prefer architectures where one thing going wrong is not sufficient. That principle is why SSP requires two devices, why some operations demand re-signing even when you are already authenticated, and why what actually stops a transaction is a question worth asking of any wallet you trust. The answer should never be "one secret, and the hope that it was generated properly."

For a wider comparison of the options and what each one really protects against, comparing self-custody options covers the trade-offs.