At Stabolut, we have been following what happened with Coldcard quite closely over the past few days. Beyond the figures that have started circulating around the amount of bitcoin stolen, we think this is a particularly interesting case because it says a lot about where some of the real risks are when we talk about self-custody and cryptographic security.
The first thing that stands out is that this is not the kind of attack we usually imagine when someone loses funds stored on a hardware wallet. There does not appear to have been malware running on the victims' computers, phishing to obtain recovery words, or physical access to the devices in order to extract private keys. In fact, a Coldcard could have been switched off and sitting in a drawer for years while someone elsewhere was still able to reconstruct the keys associated with certain wallets.
The problem had happened much earlier, at the moment those wallets were created.
How a wallet is actually born
When we generate a new wallet, the 12 or 24 words we write down do not simply appear out of nowhere. Before getting to that point, the device needs to generate a value with enough randomness. From there, the seed is derived, then the private keys, and eventually all the addresses we are going to use. It is one of those processes we normally take for granted because it happens in a few seconds and, from the user's point of view, all that appears on screen is a list of words.
In certain versions of the Coldcard firmware, that process was not working as expected.
After changes were made to the software, one of the calls involved in generating random numbers ended up using a different implementation from the one developers believed it was using. What made the bug difficult to spot is that nothing obviously broke: the code compiled, the wallet was created, the words were valid, and users could receive and send bitcoin normally.
From the outside, there was no obvious way to distinguish a correctly generated seed from one created with the affected software.
24 words don't guarantee 256 bits
This is probably one of the most interesting parts of the incident, because we are used to associating a 24-word seed phrase with an enormous amount of security.
We see 24 words and instinctively assume that there are 256 bits of entropy behind them, but those words are only a representation of a number that was generated earlier in the process.
If that number comes from a source with poor entropy, converting it into 24 words does not solve the problem.
Running the value through SHA-256 or another cryptographic function does not magically create the missing randomness either. The output can look perfectly random, but a hash function cannot create possibilities that were not there to begin with.
If the original input could only take, for example, four billion different values, then after hashing it there are still only four billion possible starting points, even if every resulting output looks indistinguishable from a fully random 256-bit value.
How an attacker steals keys without touching the device
And this is where it becomes easier to understand how someone can steal funds from a hardware wallet without ever having the device.
If an attacker understands the behaviour of the faulty generator well enough, they can attempt to reproduce its possible internal states. For each state, they generate a candidate seed, derive the corresponding keys and calculate the Bitcoin addresses associated with them.
At that point, they have another significant advantage: the Bitcoin blockchain is public.
They do not need to know in advance who owns a wallet. They can generate candidates and check whether the resulting addresses have ever been used or currently hold funds. The blockchain itself effectively becomes a way of validating whether a reconstructed seed belongs to a wallet that actually exists.
Once there is a match, the attacker no longer needs the Coldcard, the owner's PIN or access to their computer. They have enough information to derive the private key and sign a transaction.
It is a fairly unintuitive type of attack because the device that exists today is not really what is being attacked. What is being reconstructed is what happened inside that device, possibly several years earlier, during the few seconds when the original keys were created.
The debate: 40 bits, 32 bits, or worse
From there, the technical discussion around how much entropy was actually left in the affected versions becomes more complicated.
Coinkite and Block do not interpret the situation in exactly the same way.
For some older models, Coinkite estimates an effective search space of around 40 bits. Block presents a considerably more concerning view and argues that, under certain conditions, once some internal values are known or sufficiently constrained, parts of the process may have been far more predictable than that figure suggests.
Later generations of Coldcard introduced additional entropy from Secure Elements, but another relevant detail appears there: part of that entropy was reduced to four bytes before being used to reseed the generator.
Four bytes means 32 bits, or just over 4.29 billion possible values.
That does not mean every affected wallet can simply be attacked by iterating through four billion possibilities. Other factors are involved, including timers, device identifiers, internal generator state and additional variables, which is precisely why the different technical analyses do not arrive at exactly the same effective search space.
Still, we think focusing too heavily on whether the final number is exactly 32, 40 or 72 bits risks missing the main issue. The security expected from those seeds was much higher and, once a serious weakness in the generation process has been demonstrated, continuing to keep funds on them no longer makes much sense.
Updating the firmware doesn't fix old seeds
There is also a very practical point worth clarifying: updating the firmware does not fix a seed that was already generated using a vulnerable version.
The update fixes the way the device will generate new keys from that point onwards, but it cannot change how the words you already have were created.
Importing the same 24 words into another hardware wallet does not solve the problem either.
Moving a vulnerable seed from a Coldcard to a Ledger, Trezor, SeedSigner or any other device does not change where that seed came from. The keys remain exactly the same.
In those cases, the real solution is to generate new keys using a proper source of entropy and move the funds to new addresses.
What actually changes the risk
There are, of course, some situations that can change the level of risk significantly.
Coldcard allows users to add their own entropy using dice rolls. Someone who used enough independent rolls when originally creating the wallet introduced a source of randomness that did not depend on the device's faulty generator.
BIP-39 passphrases can also add an important independent barrier, particularly when they are genuinely random, sufficiently long and not reused anywhere else. A properly generated passphrase is obviously very different from a conventional password or a word that can be guessed.
The multisig case is perhaps even more interesting because it highlights the difference between having multiple devices and having genuinely independent sources of security.
A 2-of-3 setup where the keys come from different manufacturers, different devices and different generation processes can tolerate one compromised key.
But if a multisig setup uses three identical devices, all three seeds were created under the same vulnerable firmware, and we assume that having three devices automatically removes the risk, then there is still a common-cause failure sitting underneath the architecture.
Physical redundancy does not always mean actual independence.
"Don't Trust, Verify" — and open source
There is another uncomfortable aspect to this incident because of the kind of product Coldcard is.
For years, Coldcard has built much of its reputation around advanced self-custody, air-gapped workflows, PSBTs, Secure Elements, the ability to add your own entropy and, above all, the "Don't Trust, Verify" philosophy.
The software was also available for public review.
But open source means a system can be audited. It does not mean it has necessarily been audited deeply enough across every critical flow.
Based on what we know so far, this flaw does not appear to have required breaking a cryptographic algorithm or discovering some particularly sophisticated mathematical weakness. One part of the implementation expected randomness from one source and, because of the way several pieces of software interacted, ended up getting it from another.
Everything else continued working around that mistake.
And that apparent normality is probably one of the reasons the problem was able to remain undetected for so long.
Bitcoin didn't fail — the implementation did
For us, that is one of the most important parts of the story.
Bitcoin did not fail.
SHA-256 did not fail.
BIP-39 did not fail either.
And we do not think it makes sense to turn this incident into a general conclusion that hardware wallets are unsafe.
Something far more familiar in engineering failed: the implementation.
When we work with cryptographic systems, we tend to spend a lot of time talking about algorithms, signatures, hashes, Secure Elements, hardware isolation and key lengths. But all of that security ultimately depends on the different pieces being connected exactly the way we think they are.
You can build a system on top of very strong cryptographic primitives and still lose much of those guarantees because a library ends up calling a different function, because a few bytes are truncated where they should not be, or because nobody verifies the complete path from the physical source of randomness to the final key used by the user.
Those kinds of mistakes, far more than the sudden collapse of the underlying mathematics, remain one of the real problems in cryptographic security.
