Coldcard's seeds have been short of randomness since 2021, and 594 bitcoin have gone

A hardware wallet has one job that nothing else can do for it. It has to pick a number no one else can guess, and it has to do that inside a sealed device you are supposed to be able to distrust the rest of the world about. Coldcard, made by Toronto’s Coinkite, was one of the most respected devices in bitcoin for exactly that reason.

From March 2021, on the Mk3, it was picking that number with the wrong machine.

Coinkite published two posts on 30 July describing what went wrong. During a migration to a library called libNgU, seed generation moved from ckcc.rng_bytes() to ngu.random.bytes(). The new call, in Coinkite’s own words, “resolved rng_get() to MicroPython’s software fallback instead of COLDCARD’s hardware RNG implementation”. The device carried on reporting that it had made a seed. It had. The seed was drawn from a software pseudo-random generator rather than the true random number generator on the board.

The reason it went unnoticed for five years is one line of C.

#ifndef MICROPY_HW_ENABLE_RNG
  #error "hardware RNG required"
#endif

That guard asks whether the macro is defined, not whether it is on. The developers set it to 0. Zero is a definition, so the guard was satisfied, and per Coinkite “the #error did not stop the build”. The safety check written specifically to prevent this shipped the thing it was written to prevent.

Forty bits

The number that determines whether this is an inconvenience or a catastrophe is how much genuine randomness survived.

Coinkite puts the Mk3 “effective search space at about 40 bits”. For Mk4, Mk5 and Q it puts it at “about 72 bits”, because those boards mix entropy from their SE1 and SE2 secure elements into the generator’s state. The target, and what every buyer believed they had, was 128.

Those three numbers are not points on a line. 2^40 is about 1.1 trillion candidate seeds, which is a search an ordinary machine can finish. 2^72 is about 4.7 billion times larger, and remains out of reach. 2^128 is not a number anyone will ever search.

So the Mk3 sits on the wrong side of a threshold that the Mk4, Mk5 and Q sit on the right side of, by luck rather than by design, and only because two chips that were there for another purpose happened to stir the pot.

Fifteen minutes and eighteen seconds

Between 01:36:08 and 01:51:26 UTC on Thursday 30 July, 500 bitcoin wallets were swept into a single address.

Read directly off the chain this morning, bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0 has received 594.47723261 BTC across 501 outputs. Bitcoin traded between $63,866 and $64,238 through that window on Coinbase, so about $38m moved while it was moving.

The sweeps landed in four consecutive blocks: 63 in block 960188, 110 in 960189, 168 in 960190 and 159 in 960191. The median wallet gave up 0.40876419 BTC. The largest gave up 29.89245121 BTC, close to $1.9m from one person. Only seven of the 501 held less than 0.15 BTC, which tells you the attacker was not sweeping everything they could reach, or was working from a list where small balances had already been filtered out.

Then, in block 960191, in the same block as the last of the sweeps, one transaction with 341 inputs and a single output moved 562.01962301 BTC onward for a fee of 704,640 satoshis. Fifteen minutes from the first sweep to consolidation.

That money has not moved since. It sits at bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r, untouched, in full public view. The original address still holds the 32.45056320 BTC that arrived after the sweep transaction was already built. Onlookers have started sending dust to both addresses, including an unconfirmed 42,069 satoshis, which is the on-chain equivalent of a crowd gathering.

Nothing about this looks like laundering yet. Compare the Ostium attacker, who had 10,540 ETH inside Tornado Cash within days of taking $23.75m out of a liquidity vault. Whoever holds this bitcoin is sitting still with it.

What Coinkite has said

The advisory is careful. It says affected users’ “funds may be at risk”. It does not claim any theft has happened, and it does not connect itself to Thursday morning.

That reticence is defensible. Nobody has publicly demonstrated that the swept wallets were Coldcard wallets, and a correlation this strong is still a correlation.

The document’s own shape is worth reading, though. It is titled “Mk3 Security Advisory”, and its body says “seeds generated on Mk4, Q and Mk5 before the fixed firmware releases are also affected, with about 72 bits of entropy rather than the expected 128 bits”. The title names one discontinued model. The text covers the entire current range.

It also carries a timestamped amendment: “Updated July 31, 2026 at 9:33 a.m. EDT: Fixed firmware is now available. Mk4 and Mk5 users must update to version 5.6.0 or later. Q users must update to version 1.5.0Q or later. For Mk3, update to version 4.2.0 or later.” The warning went out on Thursday. The firmware that fixes it landed on Friday morning, roughly thirty hours later.

Who this reaches

Coinkite says “the issue is present on every Mk3 firmware version since 4.0.1”, which shipped in March 2021. Every Mk3 seed generated on the device since then is suspect. Mk4 and Mk5 seeds made before 5.6.0, and Q seeds made before 1.5.0Q, carry the weaker 72-bit version. Fixed builds now exist for all four: 4.2.0 for Mk3, 5.6.0 for Mk4 and Mk5, 1.5.0Q for Q.

There is one exemption, and it is the reason the dice feature exists. If you added your own dice rolls when you made the seed, your entropy came from the dice rather than from the broken generator. Coinkite’s wording: “If you entered at least 50 fair and independent rolls, and the rolls were not recorded or exposed, we do not consider the resulting seed at risk.”

The remediation is the unwelcome part. Updating the firmware fixes the generator for seeds you make in future. It cannot repair a seed that already exists, because the seed is already written down and already weak. Anyone affected has to generate a fresh seed on fixed firmware and move every coin to it, which means new backups, new descriptors, new everything, and an on-chain transaction for each wallet.

The part that should worry people who do not own a Coldcard

Coldcard is open source. The firmware is published, the builds are reproducible, and the device is scrutinised harder than almost anything in bitcoin. None of that caught this, because there was nothing to catch by reading the code: the code said #error and it looked correct. What failed was a build-time assumption about a macro, in a place where nobody thinks to look and no test could see the difference. A seed from a weak generator is a perfectly well-formed seed. It passes every check. It just happens to be guessable.

Randomness is the one property in this stack that cannot be verified after the fact by looking at the output. You can test a signature, you can test a derivation path, you can test a backup restores. You cannot test that a number was hard to guess, which is why the guard existed, and why the guard failing silently is worse than it never having been written.

Anyone holding bitcoin on a device whose entropy they cannot personally attest to has the same weekend job as everyone else: check the model, check the firmware version, check whether you rolled dice, and if in doubt, move.