The COLDCARD hack explained: what happened, who is affected, and what to do

On the morning of 30 July 2026, someone emptied 1,083 bitcoin out of COLDCARD wallets in forty-one minutes. The owners had done nothing wrong. They had not clicked a phishing link, not typed their recovery phrase into a website, not lost the device. Most of them were asleep.

This is the failure mode that hardware wallets are supposed to make impossible, and it is worth understanding properly, because the lesson is not the one most people are drawing from it.

What happened, in plain terms

A hardware wallet has one job above all others: generate a secret that nobody, including the manufacturer, can predict. Everything else follows from that. The PIN, the secure chip, the screen that shows you the address — all of it assumes the underlying secret was drawn from a pool so large that guessing is hopeless.

For COLDCARD devices set up between March 2021 and late July 2026, that pool was not large. On the Mk2 and Mk3 it was roughly 40 bits, meaning about a trillion possibilities. On the Mk4, Mk5 and Q it was roughly 72 bits. The design target is 128 bits.

Those numbers look close together written down. They are not. Each bit doubles the work. Going from 40 bits to 128 bits is not three times harder, it is around 300 billion billion billion times harder. Forty bits is a search an ordinary computer finishes. One hundred and twenty-eight bits is a search nothing finishes.

So the attack required no access to any device. The attacker ran the same flawed randomness on their own machines, produced the seeds those machines would have produced, derived the bitcoin addresses, and looked up which ones held money. Then they swept them.

The thefts have come in waves. The first, on 30 July, took 1,083 BTC. A second on 31 July took 594 BTC in about twenty-five minutes. Smaller waves followed. As of 3 August 2026, blockchain analysts put the total near 1,816 BTC, about USD 116 million, across more than 5,200 addresses. Different outlets have published different totals on different days, which is what you would expect while an attack is still running.

The bug itself, and why it went unseen for five years

In March 2021, Coinkite migrated the firmware to use Bitcoin Core's cryptographic library. As part of that work, seed generation moved from one internal function to another. The new path was meant to reach the STM32 chip's hardware random number generator. It did not. It resolved instead to MicroPython's built-in software fallback, a pseudo-random generator seeded largely from device state and timing.

The reason is small enough to be painful. The developer had set the switch that disables MicroPython's own random number code to zero, expecting that to turn it off. But the compile-time check tested only whether the switch was defined, not whether it was set to anything meaningful. Defined-as-zero still counts as defined. The fallback stayed compiled in, sitting quietly behind the name the seed generator called.

The fix, released within days, removes the fallback object entirely and adds a build check that fails the build unless the real hardware generator is linked. That is the right shape of fix: it makes the same mistake impossible to repeat rather than merely correcting this instance.

Coinkite has said it has to assume someone used AI to review old firmware versions and find the flaw. That is the company's supposition rather than an established fact, and no attacker has been identified. It is worth sitting with, though. Code that survived five years of human review is a different kind of target when reviewing five years of code becomes cheap.

Which devices and firmware are affected

Take these version numbers from the manufacturer's own advisory rather than from any summary, including this one.

What matters is the firmware version the device was running when the seed was first created, not the version it runs today. A device updated last week still holds a seed made under the old code. This is the single most misunderstood point in the whole episode.

The Mk2 and Mk3 are the worst placed, at roughly 40 bits. The newer models mixed in entropy from their secure elements, which lifted them to roughly 72 bits — better, and still far below what is needed.

Why dice rolls made the difference

COLDCARD has always allowed you to add your own randomness at setup by rolling physical dice. The device hashes your rolls together with its own entropy. That design decision is the reason a large number of owners are unaffected.

Because your rolls were mixed in rather than replaced, they carried their full strength even while the device's own contribution was weak. At least 50 fair, independent rolls that nobody saw and nobody wrote down contribute more than 128 bits on their own. Ninety-nine or more contribute around 256 bits.

A strong BIP-39 passphrase does the same job for the same reason: it is a secret the attacker's simulation never had.

There is an uncomfortable lesson here for the whole industry. The optional, slightly tedious feature that power users were mocked for bothering with is the one that held. Defence in depth is not theatre.

What to do, in order

If you set up a COLDCARD between March 2021 and 30 July 2026 without dice rolls and without a passphrase, treat the seed as compromised and move first. Read afterwards.

1. Move the coins now if the amount matters. Any wallet you control that was not made on affected firmware will do for the moment. Speed beats elegance while an attack is live.
2. Update the firmware to the fixed version for your model from the table above, and verify the installation.
3. Generate a completely new seed on the updated device. Add dice rolls this time.
4. Write down and verify the new backup before it holds anything.
5. Check the receive address on the device screen, not only in your software.
6. Send a small test amount and confirm it arrives and can be spent.
7. Move the rest, and keep the old backup somewhere safe until you are certain nothing was left behind.

Do not skip step 3. Updating firmware does not touch a seed that already exists. A patched device with an old seed is exactly as exposed as it was before the patch.

What this does and does not say about hardware wallets

It would be easy to read this as proof that hardware wallets do not work, or that one brand is careless. Neither conclusion survives contact with the detail.

The secure element did its job. The PIN did its job. The screen did its job. The device never leaked anything. What failed was a single line of build configuration upstream of all of it, in the one place where a mistake cannot be caught by any of the other protections. A wallet cannot verify that its own randomness was random; that is the nature of randomness.

What the episode does say is more uncomfortable and more general. Open source did not catch this for five years. Neither did audits. The manufacturer disclosed quickly, shipped a fix in about two days, and published a technical explanation that does not flatter them — which is roughly the best a company can do once the damage is done, and better than several larger firms have managed.

If you own any hardware wallet, the practical takeaway is not to switch brands. It is to use the entropy features your device already offers, keep a passphrase on meaningful holdings, and treat firmware advisories as things you read rather than things you dismiss.

Common questions

I updated my firmware already. Am I safe?
Not unless you also generated a new seed and moved your coins. The update fixes future seeds only.

I used dice rolls. Do I need to do anything?
If you entered at least 50 fair, independent rolls that were never recorded or seen by anyone, this flaw does not expose you. Fewer than 50, or rolls you wrote down, is a different situation.

I have a BIP-39 passphrase. Am I exposed?
A strong, private passphrase protects you from this attack. A weak or guessable one does not.

My COLDCARD was set up before 2021. Am I affected?
Seeds created before firmware 4.0.1 used the hardware generator and are not affected by this flaw.

Can the stolen coins be recovered?
Realistically, no. Bitcoin transactions are final. Coinkite has offered to provide transaction data to help with police reports and insurance claims.

Does this affect Ledger, Trezor, Tangem or any other brand?
No. This was a specific bug in specific COLDCARD firmware versions. It says nothing about the randomness in other manufacturers' devices.

Buying in Thailand

SIAMBC does not stock COLDCARD, so there is nothing for us to sell you off the back of this. If you own one and you are not sure whether your seed was made on affected firmware, message us on LINE at @siambc and we will walk through the version check with you. We would rather someone else's customer kept their coins.

The general advice we give every customer applies here without modification. Buy from a distributor rather than a marketplace listing. Generate the seed yourself, on the device, in front of you. Add dice rolls if the device supports them. Put a passphrase on anything you would be upset to lose. And read the advisories your manufacturer publishes, because this one was public for hours before most owners saw it.

One rule stays true whatever the brand. Anyone who asks for your recovery phrase is a scammer, and that includes anyone contacting you about this incident. There will be fake COLDCARD support and fake recovery services in the days ahead. Neither Coinkite nor SIAMBC nor anyone else will ever need those words.