About this record · COLDCARD entropy incident

What this record is

The site is the public record of the July 2026 COLDCARD predictable-RNG incident: it preserves what each party published and how it changed, organises the material, and explains it without adjudicating between the people involved. The register gives every source its own page showing what is held and how the text changed. Plain-language pages reconstruct the failure and organise the published responses, with each material claim carrying an evidence label.

The purpose is historical as well as immediate. This project preserves the contemporaneous public record for posterity, so future readers can assess the incident from what participants published at the time, including pages later edited or removed. It also organises explanations, opinions and speculation chronologically so readers can see how public interpretation changed.

When people publish conspiracy theories alleging an inside job or that law-enforcement or intelligence agencies caused or directed the incident, those claims are part of the historical reaction record. They are preserved as dated, attributed public reaction, never as evidence that the theory was true. Later retractions, corrections and changes of view belong beside the original claim.

The whole project is open source: the collection, the capture tooling and this site are all public at the source repository, under licences that let anyone re-run the captures, check the record against the originals or reuse the material elsewhere. Being checkable is the point: the record links to originals and independent copies where they are available, and states when a supporting copy is held only by this project. Collection and editorial methods describe how material enters the record and where coverage remains incomplete.

Who publishes this

The site is published pseudonymously by an independent interested party. It is not affiliated with, funded by, or coordinated with Coinkite or any other party named in the record. It carries no advertising and asks for no money: there is no donation address, no sponsorship and nothing for sale. What it does ask for is corrections, sources it has missed, and code. Those go to [email protected] or the repository.

The pseudonymity is deliberate, and it shapes how the site asks to be read. There is no name or institution behind it whose reputation could stand in for evidence, so nothing here has to be taken on trust: 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 capture times and reviewed change summaries that can safely be shown.

The site was researched, written and built largely with AI tooling under human direction and review, a process the project records because AI-assisted discovery is itself part of the incident record. Code claims were checked against cited source and quotations against held captures; those checks do not replace independent review.

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.

Where the sources are

The register is the source list: every registered source, searchable and faceted, each with its own evidence page showing what capture is held and how the published text has changed since. The primary-analysis register separates original technical work from reporting that restates it, and /record/sources.json is the same data as machine-readable JSON.

Links on this site point at the archive's own captures rather than at live pages wherever a capture exists. Live pages are edited during an incident, which is the failure this project was built to record.

Why captured posts are shown as images

Some pages in the record display screenshots of individual public social posts, captured by this project. They are shown as quotation and record: short statements that are themselves events in the incident, reproduced for a factual, archival purpose. Each is attributed to its author, dated, and linked to the original post, and each links to a source page carrying the capture time and why the post is in the record. A screenshot of one post is not a substitute for the platform it came from. It exists so that what was said stays checkable if the original is edited or deleted.

Longer material is treated differently: articles, forum threads and other long-form work appear as excerpts and diffs only, never as full copies.

What was published stays in the record. This project does not withdraw a public post because its author would now prefer it gone: the statements held here were events in the incident, and a record the participants can edit cannot answer the question it exists to answer. Three things do come off: material that was never public, anything identifying a private individual, and anything this project has got wrong, which is handled as a correction. Copyright in the material stays with its author, which is why it is quoted and excerpted with attribution rather than mirrored.

That describes what this project does with a request to reconsider. It is not a refusal to answer the law: a complaint with a legal basis, including a copyright complaint or a court order, is assessed on its merits and acted on where it is good. Preferring that the record did not show something is not a legal basis.

Where the technical findings come from

This record does not verify the firmware itself; it reports what the people involved published. The technical pages organise those published findings, with an evidence marker on each claim naming the captured publication behind it: how the generator path broke for the code-level accounts researchers published, and the firmware record for the published release histories and affected ranges.

Known limits and open evidence gaps

Each of these is also marked in place, on the page where it bites, as an unverified or contested claim. They are gathered here because a public record should be able to say in one place what it does not establish.

Publication caveats

Candidate-space figures are models. Block, Coinkite, LLFOURN and otaliptus use different attacker-knowledge assumptions. Independent researchers have since reproduced some candidate spaces on-device, which confirms specific scenarios but is not a measured strength of the device population. The site presents the 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 in any source this record holds. Source layout and example values do not establish the population distribution needed for a universal attack-cost estimate, and a 15 August 2026 recheck found no published population sample of device identifiers. Two sources registered on 6 and 7 August narrow the term without measuring it: the honeypot operator's instrumented sacrificial Mk3, which is one device, and a community derivation that bounds the identifier word from an assumed wafer yield.
Firmware source and released binaries are different evidence. The published source fix and the vendor's release records are captured here. The vendor's downloads page still listed 4.2.0 as current for Mk2 and Mk3, unchanged in every poll through 15 August 2026. No held source reproduces or disassembles the signed firmware images; an independent researcher's binary-level comparison of vulnerable and fixed Mk3 firmware is registered in the reference record.
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 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. Block's account remained preliminary as of a 15 August 2026 recheck: the held thread has not been restated, and no newer Block publication is registered.
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 population of affected seeds is unknown. No unit-sales figure or count of seeds generated under vulnerable firmware has been published or captured, as of a 15 August 2026 recheck. A community poster's count of compromised accounts is not that denominator.
Coinkite's promised formal technical review has not been published. The vendor's 2 August update describes it as forthcoming, and reporting on 7 August relays the vendor saying it is working on one. No date or scope is captured as of a 15 August 2026 recheck, and no captured source announces an independent audit of the fixed firmware.
The prior-warning accounts do not reconcile. A researcher's account of a May 2025 report to the vendor and the vendor's own disclosure chronology differ. On 7 August the researcher widened the account to an unidentified person who he says warned the vendor about the same issue four years before him, and the vendor stated publicly that third-party researchers did not find the defect. No document is attached to any of it. All are preserved, and the difference is presented without resolution.
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

Independence and corrections

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 on the page where the claim was and listed at /corrections/, while prior captures remain preserved as part of the historical record. Reviewed source-content changes and preserved collection differences are listed separately in the source change record: those are the sources changing their own pages, not errors of ours.

If you are citing this record in reporting or research, how to cite it covers citing a preserved source state, naming the state you read, and what a citation to this archive does and does not assert.

Copyright in third-party material remains with its owners. Excerpts are attributed and linked to their originals so readers can check the context.