What was public, and when
A dated reconstruction of the public record. It separates on-chain events, published statements, later corrections and unresolved ordering.
No code. Written to be actionable.
This page records what a reader could find in public sources at each stage of the incident. It does not infer intent from a correction or treat a later statement as though it was available earlier. Earlier page states recovered from the Internet Archive are labelled as such.
This is the dense reconstruction of 30 and 31 July, at second-level resolution where the capture record supports it, with later vendor revisions added as they enter the held record. The incident timeline is the sparse spine running from the 2021 source transitions to the model-specific hotfixes, and is the better starting point for how the defect arrived.
On-chain activity before the advisories
30 July: initial scope disagreement
The record establishes the disagreement and the wording of each statement. It does not establish why the analyses differed or what any individual owner read before acting.
31 July: corrections, releases and wider accounting
3238f6fd9977eed786012d0034a04d888c3263bb followed at
05:19:10 UTC. The release wording states that new entropy will be
generated correctly; it does not repair already generated seeds. This
project verified the source and release records, not the contents of the
distributed binaries.
1 August: the advisory's third and fourth revisions
Resolved: whether the Mk2 was in scope. This archive carried the Mk2 as an open question for several days. The vendor's legacy release track still recognised the model, and its downloads page listed 4.2.0 as current for "COLDCARD Mk3 and Mk2", but every advisory state through 13:35 UTC on 1 August named only the Mk3 in the affected range and in the fixed release. This site could therefore place the Mk2 inside the hotfix only by pointing at a downloads listing rather than at the advisory. The 18:35 UTC revision of 1 August states it in the advisory text itself: the Mk2 is inside the affected firmware range and inside the fixed release. What that revision does not change is the lower bound, which remains 4.0.1 for the Mk2 exactly as for the Mk3, so the difference with the v4.0.0 source and release evidence stands as it did before.
This is the fourth revision of the advisory recorded here. The first, held at 07:30 UTC on 31 July and recovered from the Internet Archive, widened the affected scope to Mk4, Mk5 and Q. The second, in the state held at 00:17 UTC on 1 August, announced fixed firmware for every affected model and release track. The third narrows and sharpens at once: the vendor now publishes the conditions under which funds are at risk, the dice exception and the passphrase, in place of a blanket warning, while the banner carried across the rest of the site moved from "may be at risk" to "are at risk". The fourth changes which devices the advisory speaks about rather than what it says about them, adding the Mk2 to the affected range and to the fixed release everywhere the earlier text named the Mk3 alone. Taken in order, the four move the published account outward in scope, then to a shipped fix, then to stated conditions, then to a second model. The record states what changed and when; it does not infer why.
Published updates, side by side
| Subject | Earlier publication | Later publication |
|---|---|---|
| Affected models | Coinkite's 30 July advisory said Mk4, Q and Mk5 were not affected based on early analysis. | The backgrounder's state held on 1 August included Mk4, Mk5 and Q in the affected scope. The page displays a 30 July publication date; the expanded scope's first appearance time is unresolved. |
| Mk2 coverage | Through the state held at 13:35 UTC on 1 August, the advisory named only one model: "The issue is present on Mk3 firmware versions 4.0.1 through 4.1.9 inclusive", with the fixed release given as "Mk3: version 4.2.0 or later". | The 14:35 EDT update of 1 August names both: "The issue is present on Mk2 and Mk3 firmware versions 4.0.1 through 4.1.9 inclusive", with the fixed release given as "Mk2/Mk3: version 4.2.0 or later". The lower bound of 4.0.1 is unchanged. |
| Mk3 firmware | The 31 July advisory said Coinkite was exploring whether it could safely publish one final Mk3 release, contingent on validating a sufficiently safe upgrade path, and warned users not to wait for it. | Firmware 4.2.0 was published for Mk3 at 13:43 UTC on 31 July. |
| Who is at risk | Through the state held at 00:17 UTC on 1 August, the advisory said Coinkite was "warning all users who generated a seed using a Mk3 on version 4.0.1 (March 2021) thru 4.1.9 (inclusive) that their funds may be at risk". | The 09:35 EDT update of 1 August states that funds are at risk "if the seed was created without at least 50 fair, independent, private dice rolls and the funded wallet is not protected by a strong, unique BIP-39 passphrase". The blanket warning becomes two published conditions. |
| Passphrase guidance | The earlier text said a strong, unique BIP-39 passphrase "adds an independent barrier" and that "the risk depends on the strength of the passphrase", with short, common, patterned, quoted or reused passphrases not to be assumed low risk. | The same section now says the reduced seed entropy alone is not enough to reach funds in that wallet because "an attacker must also discover the passphrase", and separately that a strong passphrase "does not repair the affected seed", that passphrase users "should also migrate as soon as practical", and that an uncertain passphrase means treating the funds as at risk and migrating immediately. |
| Site-wide banner | The banner carried on the downloads and terms pages read "Seeds generated on firmware 4.0.1 or later may be at risk". | The same banner reads "Seeds generated on firmware 4.0.1 (2021 or later) are at risk". |
| Attributed transaction accounting | Early public figures described the 500-transaction, approximately 594.5 BTC set. | Galaxy later published a wider 1,082.65 BTC attribution including 695 additional transactions. |
The affected-models and Mk3-firmware rows quote page states recovered from the Internet Archive: the affected-model wording from the 01:56 UTC state of 31 July and the Mk3 firmware wording from the 07:30 UTC state. This project's own capture of the Coinkite advisory began on 1 August 2026, so neither earlier state is one it collected at the time. The Mk2-coverage, at-risk, passphrase and banner rows compare two states this project holds directly, so both sides of those rows are its own captures.
These are changes in public scope, release plans and attributed transaction sets. The table records them without assigning motive or treating a broader estimate as proof of common control. The Mk3 row records an evaluation that resolved into a shipped release, not a stated refusal that was reversed.
Unresolved as of 2 August 2026
- The reported Mk4-class sweep. Kevin Loaec of Wizardsardine reported on 1 August that Mk4, Mk5 and Q wallets were being actively drained, quoting a third-party account of a deliberately funded honeypot seed swept overnight. A community tracker's held captures record the named destination as a 1 August vault, then record the Mk4 attribution as withdrawn in favour of an Mk3-origin seed. The device model behind a sweep is not visible on chain, and nothing held here settles it.
- Backgrounder ordering. The page displays a 30 July publication date, but the first appearance of its expanded model scope relative to the 31 July 05:19 UTC hotfix commit remains unknown.
- The wider transaction attribution. Block's captured preliminary thread and the privacy-safe recheck support the 695-transaction counts and arithmetic, but no complete primary transaction list is published here and the arithmetic does not establish common control.
- Later clusters. In their states checked on 1 August, two community trackers included a separately reported 45.9 BTC cluster in wider headlines. Its relationship to the principal incident set remains an attributed lead rather than a verified extension of the total.
- Original discovery method. AI-assisted discovery remains an inference; AI-assisted post-disclosure reproduction is separately reported.
- Number of affected people and seeds. Addresses are not people, and no captured source supplies the total number of seeds generated on affected firmware.
How to check the reconstruction
Each source page shows what we hold: the excerpted text, the hashes and the diffs between one check and the next. Social posts link to the original. Anything recovered from the Internet Archive rather than captured here is labelled as such, so an inherited copy is never presented as one this project took at the time.