How this was put together
How claims are classified, how sources are checked, and how to request a correction or reply.
No code. Written to be actionable.
Who publishes this
This site is published pseudonymously by an independent researcher. It is not affiliated with, funded by, or coordinated with Coinkite, Block, or any hardware-wallet vendor, custody provider or exchange, and it carries no advertising. The footer lists Bitcoin donation addresses; nothing else is solicited or sold here. Corrections, replies and questions go to [email protected].
The pseudonymity is deliberate, and it is the reason the archive is built the way it is. Material claims carry evidence labels naming how they are known, quotations are checked against captures held in this archive, and the source register and change record are published as machine-readable data at /record/sources.json and /record/changes.json. Public evidence is linked directly. Where privacy limits publication of capture bodies, the source page states that boundary and publishes the available integrity and capture metadata.
How evidence labels work
Material claims and claim groups are labelled where the evidence distinction affects how they should be read. Each marker names the exact claim, table or figure it applies to. The label describes the evidence for those words, not whether a person or organisation is credible.
There are four evidence bases. They are mutually exclusive: a claim is marked by the strongest description that accurately reflects how this archive knows it. Repetition does not turn a reported claim into a verified one, and verification of a quotation does not verify the proposition inside the quotation.
- Verified
- Checked directly against the cited source code, repository file, transaction data or captured publication. This verifies the scoped claim, not every inference that could be drawn from it.
- Reported
- A dated, attributed statement whose publication has been checked. Recording it documents what was said and does not adopt the underlying claim as fact.
- Derived
- Calculated or inferred from stated inputs. The method and assumptions are shown so the result can be challenged on its merits.
- Unverified
- Could not be confirmed from the evidence available. This means unresolved, not false, and the missing evidence is stated where possible.
Contested is a separate dispute state, not a fifth evidence basis. It appears alongside a basis when relevant sources disagree about the same claim. A statement can therefore be both reported and contested, or a directly checked artefact can be verified while its interpretation remains contested.
- Contested
- Relevant sources disagree. The marker identifies the disputed claim and the archive presents the positions and their assumptions without selecting a winner.
Core primary sources
- Coinkite's entropy technical backgrounder and Mk3 security advisory, for the vendor's technical account, affected ranges and response.
- Block Engineering's disclosure, for the code-path analysis and conditional candidate-space scenarios.
- COLDCARD firmware, libngu and COLDCARD MicroPython, for source and release-history verification.
- LLFOURN's attack-cost model and follow-up posts, for explicit UID, timing and call-position assumptions.
- Rob Hamilton's preliminary chain accounting and Galaxy Research's wider flow map, for the two published transaction sets.
- Clay Garrett's preliminary chain-accounting thread, for the earlier-wave counts, fingerprint method and unconfirmed-attribution caveat, and his later three-part statement, for Block's report about the operator's use of a paid blockchain-services account.
- Gregory Sanders' public confirmation, Praveen Perera's targeted recovery report, Kevin Loaec's threshold analysis and Talip's tentative Mk4 model. Each is scoped to what its captured post actually states.
- Unchained's client guidance, Rob Hamilton's migration warning and Peter Todd's direct-submission explanation, for attributed incident-response advice.
Checks performed against source
The technical review used local clones of the three source repositories checked on 1 August 2026, plus the relevant historical commits and release files. The checks include:
- The pre-v4 wallet-generation path used the STM32 hardware RNG directly. Commit
b18723dddb6d751c39978e4364b56b2414f68b47moved generation tongu.random.bytes(); the affected path is present in release commit910e306e79f7eb6e99d16e253075de42f055124c, and the signed-release record lists the corresponding 17 March 2021 DFU image. - When the hardware symbol is absent, COLDCARD's MicroPython fallback seeds a Yasmarang state from device-unique, SysTick and RTC values. Libngu contains a separate Yasmarang state and an ineffective compile-time guard.
- On Mk4-class devices, normal boot hashes 32 bytes from one secure element and 8 bytes from the other, then passes only a 32-bit value into one libngu state word. The source therefore supports an upper limit of 32 reseed bits on that path, not a measured per-device entropy value.
- The direct
ckcc.rng_bytes()surface continued to reach the hardware RNG. The affected and direct call sites are classified separately on the blast-radius page. - Pure-dice generation begins from the roll string and bypasses the affected generator. Mixed dice hashes the affected seed bytes together with the rolls and enforces no minimum roll count.
- The hotfix supplies the hardware-backed symbol used by the COLDCARD integration. The upstream libngu guard remains unchanged, so the source review describes the fix as integration-specific.
Known limits and open evidence gaps
- Candidate-space figures are models. Block, Coinkite, LLFOURN and Talip use different attacker-knowledge assumptions. The site presents their scenarios separately and does not select one as the measured strength of every device.
- The real distribution of device identifiers and timing states has not been measured here. Source layout and example values do not establish the population distribution needed for a universal attack-cost estimate.
- Firmware source and released binaries are different evidence. The source fix and vendor-published release records have been checked. The vendor's downloads page listed 4.2.0 as current for Mk2 and Mk3 on 1 August. The signed firmware images have not been independently reproduced or disassembled by this project.
- The FAQ wording captured on 1 August 2026 is not a pre-disclosure capture. It was captured after the disclosure and cannot by itself establish what users were told before the incident.
- Chain totals depend on attribution. Transaction arithmetic can be checked on chain, while common control and incident causation remain reported analyses. Address and output counts are not victim counts.
- The wider attribution remains conditional. Block's preliminary thread and a public privacy-safe artefact now support the 695-plus-500 counts and arithmetic, but no complete primary transaction list is published here and common control is not established by the arithmetic.
- Short social posts do not imply undisclosed methods. Where a capture states only a conclusion, the archive does not infer the test device, firmware, inputs, runtime or code.
- The blockchain-services provider remains unnamed at its request. Block reports that it found no evidence the provider knowingly participated in or facilitated the theft.
Editorial standards and corrections
This is an independent, unaffiliated research archive and explainer. Its content is general information and may change as the public record develops. Reports are attributed as reports and are not adopted merely by being included.
The project records what sources state, distinguishes reporting from primary analysis, and does not adjudicate between parties. Advice is framed by its technical assumptions and any relevant disclosed affiliation.
Corrections, additional primary sources, reproducible checks and requests for reply are welcome. Please identify the page and claim, explain the proposed correction or response, and include a source that another reader can check where possible.
Email [email protected] for corrections, legal notices, tips and questions. The project's X account is @cc_vuln. Substantiated corrections are marked visibly while prior captures remain preserved as part of the historical record. Reviewed source-content changes and preserved collection differences are listed in the source change record.
Copyright in third-party material remains with its owners. Excerpts are attributed and linked to their originals so readers can check the context.