How Coldcard Was Hacked — and Why a Firmware Update Won’t Fix Your Seed

On July 30 at 01:10 UTC, the Coldcard hack began: in just 41 minutes, someone completely drained 1,196 Bitcoin addresses. No phishing, no physical access to the devices, and no transactions signed by users.

The cause came down to a single line in Coldcard’s firmware configuration, which caused the wallet to generate seeds with a software pseudorandom number generator instead of the hardware RNG for five years.

Below, we break down the Coldcard hack: how the RNG vulnerability worked, who it affects, what to do right now, and what every hardware-wallet user should learn from it — even if they have never owned a Coldcard.

Coldcard hack: from the first sweep to the fourth wave

Wave one: 41 minutes, 1,082 BTC

Early reports pointed to 594 BTC (about $38 million) drained from roughly 500 single-sig wallets in 25 minutes. But that was only part of the picture.

Galaxy Research matched the transactions by their shared pattern and reconstructed the full wave: 1,196 addresses were drained completely, with 1,082.65 BTC (about $70.2 million at the time) moved between 01:10:20 and 01:51:26 UTC on July 30, across nine blocks — from 960,183 through 960,191.

Chainalysis found that the attacker was not sweeping at random: the largest balances were drained first, with more than $30 million collected in the first ten minutes. One victim lost about $1.8 million. Trezor’s Josef Tětek identified the largest drained address, which held 51 BTC.

The transaction pattern pointed to an automated tool: every sweep (draining an address in a single transaction) paid the same unusually high fee of 30 sat/vB — 30–75 times the median fee that week — and left no change output.

Coinkite’s first public warning appeared roughly 30 hours after this wave.

The second, third, and fourth waves

The second wave ran on July 31 between 04:54 and 08:36 UTC, moving 76.16 BTC from 1,478 addresses. The third stretched from July 31 into August 1 and took 207.73 BTC from 1,912 addresses.

The average amount per victim fell with each pass: in the first wave it was almost one full bitcoin; by the third, it was around 0.1 BTC. Galaxy’s Alex Thorn put it simply: the larger addresses in the reachable key space had already been cleaned out, leaving smaller balances behind.

A fourth wave began on August 3, and Thorn warned about it live while the transactions were still sitting in the mempool. This time, the attackers used RBF-enabled transactions, meaning that before confirmation a victim could theoretically replace the attacker’s spend with a higher-fee transaction and move the coins first.

The rate was 13.8 sweeps per block, compared with 0.3 during the control period before the incident.

As of August 4, Galaxy estimated with high confidence that 1,596 BTC had been moved from roughly 7,300 addresses: three confirmed waves plus 14 smaller incidents. That already put the total above $100 million. If the fourth wave is confirmed, the overall figure reaches 2,055 BTC — about $130 million.

Around 90% of the stolen funds still have not moved. Galaxy shared roughly 600 suspicious addresses with federal investigators and compliance firms and is working directly with 73 victims.

What Coinkite did

Rodolfo Novak (NVK), co-founder of Coinkite, apologized on July 31 and took full responsibility for the bug, acknowledging that the company’s internal review had missed it.

The company released fixed firmware for every affected model and release branch, destroyed inventory that still carried vulnerable firmware, and emailed instructions to customers whose devices had already shipped. TAPSIGNER, OPENDIME, and SATSCARD use a different codebase and were not affected.

How the Coldcard vulnerability worked: one macro, five years of exposure

How seed generation is supposed to work

When you create a new wallet, the device takes 32 bytes from a hardware random number generator — a dedicated physical block inside the microcontroller that draws on physical noise and does not depend on application code. Those bytes are turned into a 12- or 24-word BIP-39 phrase, providing 128 or 256 bits of entropy.

The entire security model rests on one assumption: those bits are truly random and no one else can reproduce them. Brute-forcing 2¹²⁸ possibilities is effectively impossible.

What went wrong

Coldcard has its own wrapper around the STM32 hardware RNG, so its board configuration includes the line #define MICROPY_HW_ENABLE_RNG (0). The intention is deliberate: “do not compile MicroPython’s built-in implementation; we have our own.”

The libngu library used in the generation path checked this macro with #ifndef, which only asks whether the macro exists at all — not what value it has. Because the macro is defined, libngu assumes the hardware path is available and links to rng_get().

MicroPython, however, checks the value itself, sees zero, and compiles the Yasmarang software fallback instead of the hardware RNG path. The build succeeds without any error, and every random-number request ends up going through an ordinary pseudorandom algorithm.

On March 1, 2021, Coldcard moved seed generation to libngu (commit b18723dd), and on March 17 the change shipped in firmware 4.0.0. The code then remained public in the repository for more than five years.

What seeded the software fallback

Yasmarang is initialized once, on its first call, using three values: the low 32-bit word of the chip UID (XORed with the SysTick counter), the time register RTC->TR and the subsecond counter RTC->SSR. After that, no new entropy is collected at all: every subsequent value is just a deterministic state transition.

None of those sources is secret. The UID is a factory-set chip identifier that stays fixed for the lifetime of the microcontroller, can be read from memory, and is partially exposed in the device’s USB serial number.

SysTick is a counter that resets every millisecond: 80,000 possible values on Mk2/Mk3 and 120,000 on current models. On a cold boot of Mk2/Mk3, the selected RTC oscillator is disabled entirely, so the time-register values are very likely to be zero or static.

On top of that, libngu XORed the output with a second Yasmarang generator initialized from public constants stored directly in the source code. XOR does not create entropy: if both inputs are reproducible, their XOR is reproducible too.

The built-in RNG health check only rejected identical adjacent values, which a pseudorandom algorithm can pass without difficulty.

How much entropy was left

Coinkite estimates the impact at about 40 bits on Mk3 and about 72 bits on Mk4, Mk5, and Q instead of the expected 128. Block’s technical report paints an even harsher picture.

• Mk2/Mk3 on firmware 4.0.0–4.1.9: if the attacker knows the UID and the RNG call history, the result is deterministic, leaving a single candidate. Even with completely unknown timer values, the upper bound is below 2⁴⁰·⁷.
• Mk4, Mk5, Q: additional entropy from the secure element is mixed in at boot, but it is hashed and only four bytes are used, while the reseed function itself overwrites just one 32-bit state word. That produces at most 2³² distinct output streams, or roughly 2³¹ brute-force attempts on average.

The 2⁷³ ceiling sometimes quoted for current models comes with an explicit warning in Block’s own report: this is not 73 bits of cryptographic security. The timer fields are correlated, may occupy a much narrower range, and can be profiled by an attacker using an identical device.

Hashing does not fix the problem. SHA256d makes the output look statistically uniform, but it cannot increase the number of possible inputs: the number of candidates after hashing is the same as before. The BIP-39 checksum adds no entropy either.

To put that in perspective: 40 bits is roughly one trillion possibilities, a search space that can be brute-forced offline in a practical amount of time on ordinary hardware.

Candidate testing is cheap because a public address or xpub acts as an oracle: derive an address from a candidate and compare it with the blockchain. The physical device is not needed at all.

Why a firmware update does not save the seed

The patch fixes the generation of new seeds. It does not change a seed that has already been created: those words are already recorded and may already be computationally recoverable. Restoring the same seed on another device does not help either, because the weakness is in the words themselves, not in the hardware storing them.

Who the Coldcard vulnerability affects — and who it does not

The key rule is simple: what matters is not when you bought the device or even the model itself, but the firmware version on which that specific seed was generated.

Fixed firmware versions

• Mk2 and Mk3: version 4.2.0 or later.
• Mk4 and Mk5, standard branch: 5.6.0 or later.
• Q, standard branch: 1.5.0Q or later.
• Mk4 and Mk5, Edge branch: 6.6.0X or later.
• Q, Edge branch: 6.6.0QX or later.

Standard and Edge are separate release branches. A 6.x version number may look newer than 5.6.0, but that does not make an old Edge build safe. If you use Edge, you need the fixed Edge release for your specific model.

Dice rolls

The bug affected entropy generated by the device itself. It did not affect independent entropy added by the user. On vulnerable firmware, Coldcard hashed the device-generated seed together with every roll entered through Add Dice Rolls:

• 50 to 98 independent, private rolls: the dice alone contributed at least 128 bits;
• 99 rolls or more: about 256 bits;
• fewer than 50 rolls, or you do not remember exactly how many: assume the seed is compromised.

The word “private” matters here. The rolls must not be filmed, stored in a file, or entered on an internet-connected computer. The sequence of rolls is key material just like the seed itself.

What else used the same generator

The issue was not limited to wallet seeds. The same RNG call was also used to generate:

• private keys for paper wallets — the worst case, because the RNG output becomes the private key directly, with no BIP-39 or BIP-32 in between, while the printed address itself acts as an oracle for brute-force testing;
• random Seed XOR masks when splitting a seed (the deterministic split mode used by default was not affected by this bug);
• device-cloning keys and USB-session encryption keys;
• ephemeral ECDH keys and the five-byte secondary password used by Key Teleport;
• the TOTP secret and request keys used by Web2FA;
• passwords generated by the built-in generator in Secure Notes.

Multisig

Multisig only helps when an attacker cannot build the signing quorum from affected keys. A 2-of-3 setup in which all three devices are Coldcards running vulnerable firmware does not protect you: the attacker can recover enough keys to sign the transaction independently.

Block states this plainly in its report: the quorum must include enough devices that are not affected by the vulnerability.

What to do right now

Rushing the migration can create a bigger risk than the one you are trying to escape. The order of operations matters.

1. Find out which firmware version was used to create your seed. If you do not remember, assume the worst-case scenario.
2. If the balance is significant and the seed may be vulnerable, secure the funds first and clean everything up afterward. Temporarily, that may mean using another hardware wallet with sound entropy, a newly generated seed, or even an exchange deposit address followed by another withdrawal. Galaxy recommends this kind of sequence for users who do not have time to perform a careful migration immediately.
3. Before making any changes, verify the written backup of the old seed and confirm the wallet fingerprint (XFP). Losing access during migration leaves you with the same zero balance as a theft.
4. Install the fixed firmware for your model and release branch. Download it only from the official Coldcard download page and verify the version on the device screen after updating.
5. Generate a new seed on a device running fixed firmware. If you want to eliminate dependence on the manufacturer’s RNG entirely, choose Import Existing > Dice Rolls and enter at least 99 rolls of a fair six-sided die.
6. Write down and verify the new seed backup, confirm the wallet fingerprint, and verify the receiving address on the hardware wallet’s own screen — not only in the desktop app.
7. Send a small test amount, wait for confirmation, and only then move the rest.
8. Do not destroy the old backup until the full balance has arrived in the new wallet and the transaction has confirmed.

If Mk3 is your only device

Firmware 4.2.0 can generate a correct new seed directly on the Mk3, so you do not need to buy another device solely for this migration.

The inconvenient part is that you will have to switch between the old and new seeds on the same device: verify the old backup and XFP, update the firmware, generate a new seed on the wiped device, record its backup and receiving address, restore the old seed, send a test amount, restore the new seed and confirm that it arrived, then restore the old seed again and move the remaining funds.

It is tedious, but it works without a second device. If you do have another device running fixed firmware, using it is easier.

Passphrase: when it helps and when it does not

A BIP-39 passphrase, often called the 25th word, is not your device PIN. It is a string that combines with the seed to produce a different wallet with different addresses. An attacker who recovers your seed gets only the base wallet without the passphrase and cannot see the wallet protected by it.

The problem is that the passphrase can be brute-forced alongside the seed. If the seed space has collapsed to a few billion candidates and the passphrase is “Bitcoin2024!”, a birth date, or a line from a favorite song, the combined search can still be practical. A weak 25th word is not a meaningful barrier in that situation.

A strong passphrase in this scenario has several specific properties: it is a random string rather than a phrase built around human patterns; it is not reused anywhere else; it has never been entered on a website or an untrusted computer; and it was not generated on the vulnerable device, because Secure Notes’ built-in password generator used the same broken RNG.

There is a downside as well. A passphrase cannot be recovered from the seed, must be stored separately from the seed words, and its existence needs to be known by whoever may inherit access. We have seen more wallets lost to forgotten passphrases than saved by them.

Most importantly: a passphrase reduces the urgency, but it does not fix the seed. Coinkite explicitly recommends that passphrase-wallet users migrate as well — just without the same first-night panic.

How to protect yourself from this class of attack

Dice

This is the only way to remove dependence on the manufacturer’s random-number generator entirely. 50 independent, private rolls of a six-sided die provide 128 bits; 99 rolls provide about 256.

The method is verifiable: Coldcard documents the math, so you can check the result yourself. The trade-off is time and discipline: do not photograph the rolls, save them to a file, or enter them on an internet-connected computer.

Multisig with devices from different manufacturers

The point of multisig is not the number of keys; it is independent failure domains. A 2-of-3 setup built from Coldcard, Trezor, and BitBox can survive an entropy failure at one manufacturer because the attacker still cannot assemble a quorum. A setup made from three identical devices does not protect against this class of failure.

The cost is complexity: you need to store the wallet descriptor alongside the backups, recovery takes longer, and heirs need more instructions. For an amount whose loss would materially hurt, the trade-off can be worth it. For a wallet holding a few hundred dollars, probably not.

How other manufacturers generate entropy

This is not an advertisement for competitors; it is a useful way to evaluate a device’s security architecture before buying it.

• Trezor: the final secret is never derived from the device alone. The final seed is SHA-256 of 32 bytes of device entropy concatenated with 32 bytes supplied by the host operating system’s CSPRNG (cryptographically secure pseudorandom number generator). A complete failure on either side still leaves the full entropy of the other.
• Ledger: a certified hardware TRNG inside the Secure Element provides 256 bits of entropy for a 24-word recovery phrase.
• BitBox02 and BitBox02 Nova: use multiple independent entropy sources and their own firmware; they do not share this part of the Coldcard codebase.

The lesson is straightforward. An architecture with a single source of randomness can fail completely because of one integration mistake, and the user will not see anything wrong: the words will look normal, the checksum will validate, and the device will show no error.

An architecture with two independent entropy sources can survive this class of failure. So the right question when evaluating a device is not “does it have a hardware RNG?” but “what happens if that RNG silently stops working?”

All three manufacturers are available in Ukraine, and new Coldcard devices now ship with fixed firmware. But checking the firmware version on the device before generating a seed should become a permanent habit, regardless of brand.

Open source in 2026

Coldcard’s source code was public for all five years, and that fact was repeatedly presented as a security advantage. No one spotted the bug.

NVK has suggested that the attacker may have run old firmware versions through AI. He also acknowledged an uncomfortable fact: Coinkite had audited the code with one of the best available models only weeks before the incident, and it found neither this bug nor anything else serious. After disclosure, a developer on Reddit reproduced the finding with Claude Code in eight minutes.

The practical lesson for users is simple: “the code is open and nobody has broken it for years” is no longer a security argument on its own. Public code from older releases can now be analyzed by automated tools faster than security teams can review it manually.

What matters more is how quickly a manufacturer responds, whether it publishes a technical postmortem, and whether the device architecture can tolerate a failure in a single component.

Does the Coldcard hack mean hardware wallets do not work?

The Bitcoin protocol worked exactly as designed. The signatures were valid, and the network processed what it was given. What failed was the randomness used during key creation — a different layer of the stack.

This incident is not an argument for keeping funds on an exchange either: exchanges have lost far more user funds for much more ordinary reasons. We covered the trade-offs in our article “Hardware Wallet vs Exchange: Where Is It Actually Safer to Store Crypto?“.

The important distinction is elsewhere. If a vulnerable seed has already been created, no non-custodial wallet — hardware or software — can replace it remotely without action from the owner. A hardware-wallet manufacturer likewise cannot reach into an air-gapped wallet (a device physically disconnected from the network) or repair a seed that has already been created.

The same autonomy that protects against freezes and seizures also makes this kind of failure impossible to fix without the owner’s involvement.

The practical takeaway is to treat key generation as its own risk boundary. Add your own entropy with dice, spread trust across manufacturers when the amount justifies it, and verify the firmware version before generating a seed — not after a vulnerability makes the news.

Bottom line

If your seed was created on a Coldcard running vulnerable firmware, do not delay migration whether you used a passphrase or not. The exception is a seed that had at least 50 independent, private dice rolls added during creation.

A firmware update fixes new seed generation; it does not fix old seeds.

The broader lesson will outlive this particular incident. Trusting a single source of randomness is a single point of failure that users can mitigate themselves: with dice-generated entropy or multisig using devices from different manufacturers.

If you are still getting the fundamentals in place, start with our guide “How to Store a Seed Phrase: 5 Safe Methods in 2026“.