COLDCARD RNG incident the public record, collected and explained
Informational only, and this site never asks for your seed words. details

Informational only. This is an open source collection of what others have published about the incident, together with an explanation of it. It is not financial, security or legal advice, and not a substitute for professional advice about your own situation. It is not affiliated with, endorsed by, or speaking for Coinkite. Material is attributed and quoted as published; where sources disagree their scenarios are kept separate with their assumptions rather than reconciled into one answer. Everything is meant to be checked against the linked evidence rather than taken on trust. Act on your own judgement about a particular situation. Editorial standards and corrections.

Do not disclose recovery material to a website, form, message or support account. This site never asks for it, and contributions containing recovery words or private keys are not accepted.

Plain language Updated 15 Aug 2026

Reference

The research behind this site's claims: who found what, grouped by the kind of finding they made, and the code published around the incident, described from each repository's own README.

Primary analysis

Original analysis and reporting that restates it are different things, and this register covers only the first: 21 contributions, grouped by the kind of finding they made. Each entry names who published it, what it added to the public record, what has been checked here, and what remains that source's assumption. The candidate-space estimates below differ because their authors assume different attacker knowledge; none is a measured population-wide search cost.

An entry is listed here when it introduced something no earlier source had, and the 5 groups below are the kinds of thing it could introduce: a source or binary reading, a candidate-space model, a reproduction, a chain derivation or attribution, or a prior-warning account. Restatement belongs on the source list instead. One contributor holds one entry per group, carrying every artefact behind that contribution, so a body of work that was revised reads as a revision rather than as several independent findings. Inclusion records provenance rather than endorsement; each date is the registered first publication, not the capture, and entries run oldest first within a group. R1 D2

The candidate-space estimates grouped below apply different assumptions about what a remote attacker knows at the moment of generation, and one of them disputes whether two of the generator's own inputs vary independently. The attack-cost page sets out the assumptions beside the figures it tabulates, and they should not be combined without carrying those assumptions with them. R3

Source and binary readings

Work that reads the firmware, the libngu source or the compiled images and reports what the code does. These are the entries a reader can most directly recheck, because the artefacts are public.

Block engineering, with anonymous collaborators

evidence →

The technical disclosure

Identified the migration commit, showed that the Mk4-class reseed carries at most 32 bits into one libngu state word, and published lower candidate-space scenarios. Bitcoin Optech reports that anonymous researchers participated and that disclosure was coordinated with Coinkite.

Reported technical analysis; the disclosure report is captured for revision tracking.

The candidate-space figures are scenarios with stated attacker-knowledge assumptions, not per-device measurements.

Kevin Loaec, Wizardsardine

An early hypothesis, then the post-mortem and the derived-material argument

Before the full technical account was public, Loaec proposed a low-entropy generator as the cause and pointed to BIP84-only searching, limited derivation depth and partial sweeps, presenting AI-assisted script generation and the operator's limited Bitcoin knowledge as a hypothesis rather than a demonstrated attribution. The later Wizardsardine post-mortem reconstructs the flaw at length and argues its reach goes past seed generation: on affected devices, features that draw on the same generator are reported broken even where the seed itself was imported or created with dice. That post opens with configuration-specific guidance for Liana, Miniscript and multisig users before turning to the incident, and a companion post enumerates the features in an attached graphic that did not render in the held capture.

Captured screenshot of the post by @KLoaec, posted 30 Jul 2026, 20:28 UTCcaptured

Reported early analysis, later confirmed in direction, followed by reported independent analysis; the mutable post is captured for revision tracking.

The derivation-pattern observations do not establish that the operator used AI or identify who discovered the defect. Wizardsardine sells Liana, a competing wallet product, and the post-mortem's first section is written as guidance to its own users. The authors describe it as written quickly under stress and invite corrections. The feature-exposure claims are their reading until checked against source, and nothing in the post has been reproduced here.

3z

evidence →

Mk3 binary reversal and bounded synthetic proof of concept

Reports reproducible builds of Mk3 4.1.9 and 4.2.0, compares the resolved RNG symbols in both binaries, and models the vulnerable path with fixed synthetic register inputs. The repository says it contains no enumeration, wallet-recovery or fund-targeting capability.

Reported independent binary analysis; the README is captured for revision tracking.

This archive has not independently reproduced the builds or endorsed the author's candidate-state calculation. The synthetic proof establishes determinism for its inputs, not a measured remote-search cost for a wallet population.

Álvaro P.

evidence →

Reproducible firmware and chain investigation

Reports independent checks of the fix commits, a chain reconstruction from a public consolidation point, and compiled vulnerable and patched firmware symbol comparisons. The repository separates completed evidence from planned synthetic and regtest demonstrations.

Reported independent reproduction; the public README is captured for revision tracking.

The repository has not been audited in full by this archive. Deeper files contain public transaction identifiers, so only the address-free README is mirrored publicly here.

Dustin Dettmer

The commit-history reading of how the defect entered

Traces the firmware commit history behind the disabled hardware generator: a commit whose entire message is "runs" sets MICROPY_HW_ENABLE_RNG to zero next to a duplicate symbol definition that would not otherwise have compiled, and the overridden functions turn out not to be the ones seed generation reaches. Published on bitcoin++ Insider Edition.

Reported independent source reading; the commit-level claims are checkable against the pinned repository clones held here.

The account of what the original author intended, and of the frustration inferred from it, is the writer's reading of commit messages and diffs rather than established fact. This archive has not rechecked every commit cited.

bigshiny0

evidence →

A run-time path test on a real device

Reports instrumenting the Mk4 firmware at the point where it reads the STM32 hardware generator, then requesting the same 32 bytes seed generation uses. On 5.6.0 the author says exactly eight hardware reads were observed, and presents that as direct evidence the seed request reached the TRNG. The post frames this as a path test on real hardware rather than a statistical judgement about how random the output looks, and asks why a test of that shape was not already in COLDCARD's suite and run on devices.

Captured screenshot of the post by @bigshiny0, posted 7 Aug 2026, 02:02 UTCcaptured

Reported first-person test on a real device.

Neither the instrumentation nor its output is published, so nothing in it has been rechecked here. The zero-hardware-read result stated for the affected firmware is what the author says the same test would have shown, not a run reported in the post, and the question about the vendor's test suite is the author's.

Candidate-space models

Estimates of how much an attacker must search. They disagree because they assume different attacker knowledge, or read the generator's own inputs differently, not because one is arithmetically wrong. The attack-cost page sets out the assumptions beside the figures it tabulates, and none of these is a measured population-wide search cost.

LLFOURN

evidence →

The attack-cost model

Published a model using about 2^20 MCU identifiers, 80,000 timing states and 16 button-press variants. This gives about 2^40.3 for Mk3 and 2^72.3 for Mk4-class devices. The source does not decompose the 16 variants further. A follow-up said clock assumptions might reduce the latter by 10 to 14 bits, and another reply described a 2^32 lower scenario when UID, button-press variation and clock behaviour are known.

Captured screenshot of the post by @LLFOURN, posted 31 Jul 2026, 00:41 UTCcaptured

Reported model; the figures are the author's derivation from the stated inputs.

The 2^20 UID range and practical timing distribution have not been independently measured here.

Talip (@otaliptus)

evidence →

Independent technical analysis

Published a separate, deliberately tentative Mk4 model. It assumes a remote attacker does not know the UID, estimates about 20 to 21 bits from the wafer-coordinate word, narrows the practical SysTick positions, and makes the unresolved RTC term visible. The post reports roughly 52 to 63 bits if RTC behaviour is problematic and roughly 75 to 88 bits if it is not. The author labels the work brainstorming and lists assumptions that may be wrong. Profile.

Captured screenshot of the post by @otaliptus, posted 1 Aug 2026, 01:32 UTCcaptured

Unverified working hypothesis.

The author calls it brainstorming, says details may be wrong and credits GPT-5.6 Pro with document checking. It is retained as commentary, not a settled estimate.

ineedanamegenerator

evidence →

A tighter bound on the Mk3 seed word

Argues that the value seeding the Mk3 generator, UID[31:0] XOR SysTick->VAL, carries nearer 23 bits than 32. SysTick is put at about 16.3 bits confined to the low bits; the UID word encodes wafer coordinates whose lower half overlaps those same bits and so, under the XOR, adds nothing; and the upper half is bounded by how many chips a wafer holds, which the author takes at an upper bound of 20,000 and reduces to roughly 7 bits. The post carries its own struck-through correction, withdrawing an earlier BCD-encoding step as a manual error while stating the result is unchanged.

Reported derivation, and a stated disagreement with the treatment of the same two terms in the models above.

The wafer figure is a general upper bound the author found rather than a measurement of shipped COLDCARD parts, the author says the square-root step assumes a square wafer and is approximate, and nothing here has been rechecked against a device population. It bears on the other models in this group, which treat the identifier and timing terms as contributing separately: this archive records the disagreement and does not settle it.

Reproductions and live demonstrations

Independent attempts to make the defect do something observable. Each states what it targeted, and none of them measures the cost of discovering unknown funded wallets.

Gregory Sanders (instagibbs)

Independent public confirmation

Published the statement: "Confirmed. Mk2/3 vuln, I don't think mk4 is but can't be certain." A later captured post says it took about one hour and 50 minutes from deciding to investigate to an on-device proof on Mk3.

Captured screenshot of the post by @theinstagibbs, posted 30 Jul 2026, 22:37 UTCcaptured

Reported confirmation.

The follow-up identifies Mk3 and the full investigation-to-proof interval. Neither post identifies firmware, method, candidate inputs, brute-force runtime or scripts. The elapsed interval is not an attack benchmark.

Praveen Perera

evidence →

Independent recovery against the known stolen set

Reported scanning index-zero addresses against the known first-wave address set and recovering two private keys associated with approximately 34 BTC. Perera reported that the run took about five minutes and less than US$5 of GPU time.

Captured screenshot of the post by @PraveenPerera, posted 31 Jul 2026, 01:01 UTCcaptured

Reported independent reproduction.

The code, candidate inputs and recovered keys are not public. The run targeted known stolen addresses and does not measure discovery of unknown still-funded wallets.

JStefanop1

evidence →

A collision-search demonstration under the 40-bit model

Reports a program built on the 40-bit effective-state model, stating that a duplicate wallet appears on average about every 1.3 million seed generations, and that a collision was found in 4.7 seconds on an M1 Max at roughly 268,000 evaluated states per second. The attached screenshot shows the reported duplicate-seed run.

Captured screenshot of the post by @JStefanop1, posted 1 Aug 2026, 04:14 UTCcaptured

Reported independent demonstration.

The code and inputs are not audited here and the rates are the author's own measurements. A collision inside the modelled state space demonstrates duplicate generation under that model; it is not a measured cost of finding unknown funded wallets.

Rob Hamilton and CKTRIPWIRE

evidence →

A live honeypot experiment

publication date not established

Publishes live states for honeypots across a control and stepped added-entropy bands. Eight were listed at the first capture, where the control was reported swept after 1 hour 18 minutes while the seven other cases remained live. The board has grown since: the capture of 6 August 2026 holds 17 entries, 12 of the operator's own and 5 submitted by others and watched only, with 15 live and two swept — the trivial-difficulty control at 1 hour 18 minutes, and a submitted Mk3 with no added entropy at two minutes. The same day the operator revised its estimated GPU crack times sharply downward across every difficulty band. By the capture of 12 August 2026 at 03:08 UTC the board had grown to 19 entries, 12 live and 7 swept; the new swept entries were two trivial-difficulty honeypots (HP-88A9 and HP-D85A) and the two low-dice honeypots HP-2C6F and HP-10ED, while HP-696E remained live and the community-submitted one-word and two-word passphrase cases were swept after about six days. A later capture the same day at 05:07 UTC updated the scoreboard to 11 live and 8 swept and recorded honeypot HP-D4A0 as swept after about six days and seven hours.

Reported live experiment; revision-captured by this archive.

The experiment is ongoing and the figures above are the state of one held capture, not a current reading. Two swept zero-added-entropy cases and fifteen then-live ones do not establish a safe entropy threshold or a general attack-time distribution, and the anonymised handles were re-randomised on 6 August, so an individual row cannot be followed from one capture to the next.

Chain derivations and attribution

Work reconstructing what moved, when, and who might have controlled it. The chain establishes transactions and amounts; wave grouping, common control and cause are derivations on top of it, and the funds page keeps the competing totals apart rather than reconciling them.

Rob Hamilton, AnchorWatch

On-chain forensics, and the front-running warning

Reported 1,324 UTXOs across 500 transactions, approximately 594.48 BTC and a later 562 BTC consolidation. The transactions occupy four block heights, not the "3 block window" in the post. Hamilton separately described the first-spend script-reveal risk for threshold wallets in a captured migration PSA.

Captured screenshot of the post by @Rob1Ham, posted 30 Jul 2026, 18:30 UTCcaptured

Reported primary analysis.

The post labels the entropy attribution preliminary. The chain establishes movements, not the COLDCARD cause by itself.

Kevin Kelbie

A chain-derived postmortem, and the tracker built on it

Publishes frozen chain data, explicit rules for deriving collectors and waves, source recovery notes and reconciliation checks, distinguishing victim-named evidence, publisher attribution and its own pattern matches. The tracker built on that dataset was announced on 2 August with 1,367 BTC stated as tracked across 4,620 drained addresses, coins followed from victim addresses to their current position, a timeline running from the 2021 bug to the July 2026 sweeps, and a searchable ledger, then moved from coldcard-hack.up.railway.app to coldcard.rip on 3 August. That total is numerically close to Galaxy's revised 1,367.05 BTC across 4,585 addresses, but neither source states that the two sets are the same, so the funds page registers them as separate reported figures.

Reported independent chain analysis; the mutable README and the tracker announcements are captured for revision tracking.

The chain can verify transactions and amounts. Wave grouping, common-control attribution, tool fingerprints and counterfactual claims remain the author's derivations and may change as new reports appear. The tracker posts do not itemise which waves the total counts or restate the attribution rules behind it.

Clay Garrett, Block

The earlier-wave scan, and the attribution finding

Reported 695 earlier transactions with the same stated fingerprint as the known wave: 204 sweeps in block 960,183 and 491 in block 960,185, with 488.10957948 BTC reaching three first collectors, from a described scan of 888,661 transactions. Separately reported that the operator queried the source addresses through a paid account at a blockchain-services provider during the sweeps, and that the provider's logs matched the suspected workflow "with extraordinary specificity, including the number, timing and sequence of requests".

Captured screenshot of the post by @clay_garrett, posted 31 Jul 2026, 00:03 UTCcaptured

Reported primary chain analysis, and an attribution finding reported by Block that is not independently verifiable from public data.

Block explicitly said it had not confirmed that the earlier waves were related to the drain; the shared fingerprint and arithmetic do not establish common control or cause by themselves. The provider remains unnamed at its request, and Block says it found no evidence that the provider knowingly participated.

Galaxy Research

The flow-of-funds mapping, revised three times

The first attributed set ran from 01:10:20 to 01:51:26 UTC across blocks 960,183 to 960,191, for a 1,082.65 BTC gross total and four consolidation holdings. On 1 August Galaxy identified a third sweep wave of 207.7294 BTC, revised the observed size to 1,367.05 BTC across 4,585 addresses, reported 1,366.3865 BTC under attacker control with every endpoint address unspent, and placed the vulnerable firmware at block 674,951 on 17 March 2021 with no identified coin created before it. A 2 August update gave the provenance of the wave identifications: wave 1 came from Block engineers, waves 2 and 3 from victims coming forward, with findings stated as shared with US authorities, SEAL, exchanges and cyber investigators. On 3 August it stated a high-confidence 1,596 BTC from about 7,300 addresses across three confirmed waves plus 14 smaller incidents, superseding the 1 August figure; including a suspected fourth wave would reach 2,055 BTC, which Galaxy does not promote without victim confirmation. What each figure measures, and why the later totals are not alternative measurements of the 30 July set, is set out on the funds page. The block-boundary finding bears on the firmware range, where three limits belong with it.

Captured screenshot of the post by @glxyresearch, posted 31 Jul 2026, 13:23 UTCcaptured

Reported attributed estimates, revised three times; the underlying transaction and address lists are not published.

Galaxy's own stated method limit bounds every figure: the work derives solely from Bitcoin block data and the unspent-output set, it has not used compute to test whether the addresses it identifies as possible victims were generated with low entropy, and it should not be treated as complete or definitive. Galaxy does not publish its address-counting method, and victim-supplied addresses are reports to Galaxy rather than verified attributions.

profedustream

A published mapping export and a two-actor hypothesis

Published the JSON export of a multi-day on-chain mapping. It describes a scripted first wave whose consolidations remain untouched; a noisier, more erratic pattern whose movements reach clusters the author links to Chivo Wallet and Binance, six ChangeNOW transactions, and one CoinJoin service whose outputs were later connected to Binance; and further script-like waves that also remain unmoved. On that split the author offers a working hypothesis of two actors.

Reported independent mapping; the JSON export and its accompanying schema prompt are held, but the graph and its cluster attributions have not been independently rechecked here.

The exchange and service cluster labels are the author's attributions, and the two-actor reading is stated as a working hypothesis rather than a finding. Behavioural differences between waves do not by themselves establish separate operators.

Chainalysis

evidence →

A geographic distribution estimate

Reports that Canada accounts for 25 percent of losses it could attribute geographically, with Australia, the United States and Thailand also prominent.

Captured screenshot of the post by @chainalysis, posted 4 Aug 2026, 20:11 UTCcaptured

Reported company analysis.

The post does not publish the attributed address set, victim set, geographic method or denominator. It cannot be reproduced from the post alone.

Prior-warning accounts

First-person accounts of having raised the defect, or something near it, before the public disclosure. Each is attributed and dated; none attaches the contemporary report it describes, and the vendor's own chronology does not record them.

Blockchain Unmasked

evidence →

A reported 2024 victim investigation and warning

Says the authors investigated victim losses in 2024, traced them to weak entropy and reported the finding to Coinkite and several authorities before the public disclosure.

Reported prior-warning account and retrospective investigation.

The article does not publish the contemporary reports, underlying victim set or complete chain method. Its broader conclusions remain the authors' analysis.

James O'Beirne

evidence →

A reported May 2025 audit warning

Says that a May 2025 audit identified a potential concern around COLDCARD randomness and libngu, that he reported it to the team, and that he was told they would know if the concern was valid. Coinkite's published disclosure history carries no May 2025 entry, an absence set out on the disclosure-history page.

Captured screenshot of the post by @jamesob, posted 4 Aug 2026, 12:56 UTCcaptured

Reported first-person prior-warning account, unreconciled with the vendor chronology.

No contemporary report, correspondence or exact finding is attached to the post. It does not establish that the later defect was identified before disclosure, and the vendor selects what its own chronology contains, so the absence is not evidence that no report was made.

Earlier predictable-key failures are kept beside this register as context rather than inside it, and the primary document for each is held: the Debian OpenSSL advisory of 2008, Android's SecureRandom statement of 2013, the Trust Wallet browser-extension generator as both a vulnerability record and the vendor's own thread, the Milk Sad disclosure and Unciphered's Randstorm disclosure. Milk Sad is the nearest process precedent, pairing a public disclosure with an attempt to account for affected funds. Each is a different generator, a different affected population and a different disclosure process, so they are precedent for how such an incident is handled, not evidence about COLDCARD. V4

One more is in the record without a primary document. Registered posts captured on 7 August 2026 describe Ill Bloom, a weak-entropy flaw in CryptoJS said to be twelve years old, for which a public proof of concept was announced during this incident's response, and Coinspect, which sells security audits, named one wallet whose generated phrases it says are affected. No disclosure, advisory or vulnerability record for it is captured here, so it is held as what those posters said rather than as an established account. R5

Beyond this register, 932 social posts are registered with their own evidence records, on the registered-post wall, and the chain monitors' current totals are read live out of the archive on the funds page. Those trackers are independent of this archive, their figures and methods can change, and entering an address into any third-party site discloses that query to its operator and to network intermediaries. Registry descriptions do not convert a reported claim into a verified one, and where this register has been wrong the corrections process records the change: one entry was corrected after timestamps showed private-submission advice attributed to the wrong person.

One absence belongs beside the register. ZachXBT stated that he has no plans to monitor or trace the incident, citing where his donor support comes from. It is recorded as made and not adjudicated here. R6

Firmware releases

The firmware release register moved to its own page: which firmware, on which model, generated an affected seed, including the v4.0.0/v4.0.1 boundary dispute and the vendor's stated lower bound.

Published code

3 repositories are held here with their READMEs captured, and each is described from its own README, leading with the input it states it takes. Two accept no wallet material at all; the third reads a firmware source tree. Upstream files and the pull requests filed in response are listed separately, as source and patches rather than tools a reader runs.

Held in this archive

Each entry leads with the input its README asks for, and all 3 were read before being described. V7

DK27ss/ColdCard-38M-PoC

capture →

anonymous author · · No licence stated.

Input: Nothing. It creates its own target.

An end-to-end reproduction. It reimplements both generators, the MicroPython software fallback and the libngu mixer, fabricates its own synthetic victim wallet through the affected path, then recovers that wallet's mnemonic by searching the timer and skip space. Because the target is generated by the repository itself, the demonstration is safe by construction: it runs offline, it never needs a real wallet, and there is no input field for recovery material because there is nothing for a reader to supply.

The author is anonymous and the repository states no licence, so reuse terms are undefined. Its candidate-space and skip-model figures are the author's analysis and are not adopted here.

SamSamskies/coldcard-hack-tracker

capture →

SamSamskies · · MIT, with a test suite.

Input: Public addresses it already holds, queried against public explorers.

The published source behind the tracker dashboard this archive already tracks as a deployed page. Publishing it matters for a reason that is easy to miss: it converts an opaque third-party dashboard into something a reader can audit, so the watch set, the hop-following rules and the accounting can be checked rather than trusted. It reads public block-explorer APIs and takes no wallet material from the reader.

Its watch set is hardcoded from public reports rather than derived independently, and querying any third-party tracker discloses that query to its operator and to network intermediaries.

nobuxpt/coldcard-entropy-test

capture →

nobuxpt · · ISC.

Input: A firmware source tree. Not a wallet, and not a seed.

Two offline tools. A collision demonstration reproduces the reduced search space by generating seeds through a reimplementation of the affected chain and counting duplicates. A static scanner reads a firmware source directory and flags the defined-ness guard, reporting vulnerable, fixed or indeterminate. The scanner examines source code, not a wallet: it classifies a build rather than a wallet balance or individual exposure.

Its README states that it does not contact the Bitcoin network, derive wallet balances or scan for funds. That is the repository's own description of itself, quoted rather than independently audited here.

Already in the source register

Upstream code and the pull requests filed in response were tracked before this catalogue existed. They are listed here so that the code published around this incident can be seen in one place, with their individual capture records linked. V8 Their inputs are not at issue: these are source files, patches and review threads rather than tools a reader runs.

  • libngu random.c · switck · publication date not established
    The generator file at the centre of the defect, tracked for change. Its master state changed on 6 August 2026 when the hardware-TRNG enforcement below was merged into it, and again by 12 August 2026 when the implementation was refactored behind random_backend.h.
  • libngu PR #58 · switck · publication date not established
    Incident-response proposal, "Enforce HW TRNG", open in every 1 August capture and merged on 6 August 2026 as commit e9d5e80.
  • libngu PR #59 · switck · publication date not established
    Broad incident-response proposal; the maintainer called the diff too large and the author closed it on 1 August in favour of a three-pull-request stack, #62, #63 and #64; the closing comment was edited on 7 August 2026 as two of those were retitled.
  • libngu PR #60: full-width reseeding · switck · publication date not established
    Full-width reseeding proposal, closed by its author on 1 August. Was the companion to firmware PR #691, which now names libngu #61.
  • COLDCARD firmware PR #691: pass the full secure-element digest · Coinkite · publication date not established
    Removes the firmware-side four-byte truncation. A draft by the last 1 August capture; now depends on libngu PR #61. In the 12 August 2026 capture a reviewer notes the change is already covered by Coldcard/firmware PR #713 commit d16d47b and asks the author to close the draft.
  • COLDCARD firmware PR #689: Mk3 RNG hotfix · Coinkite · publication date not established
    Merged Mk3 hotfix behind release 4.2.0.
  • COLDCARD firmware PR #690: Edge RNG hotfix · Coinkite · publication date not established
    Merged Edge hotfix behind 6.6.0X and 6.6.0QX.
  • COLDCARD mainline RNG hotfix commit ca724637 · Coinkite · publication date not established
    The mainline hotfix commit carried by the Mk4/Mk5 and Q releases.
  • Mk3 binary reversal and bounded proof of concept · 3z ·
    Binary reversal with a bounded synthetic proof; states it excludes enumeration and fund targeting.
  • Chain-derived COLDCARD RNG postmortem · Kelbie ·
    Chain-derived postmortem built from frozen chain data.
  • Reproducible firmware and chain investigation · Álvaro P. ·
    Re-derivation of fix commits and vulnerable versus patched symbols.
  • SeedSigner PR #962: withdrawn camera-entropy hardening proposal · SeedSigner · publication date not established
    Downstream hardening proposal, withdrawn by its author as unsound.
  • SatSigner PR #468: entropy audit and hardening · SatSigner · publication date not established
    Downstream entropy audit of separate optional dice and coin paths.
  • Sparrow Wallet PR #2047: warn on COLDCARD device selection · Sparrow ·
    Downstream user-warning proposal from an outside contributor: show Coinkite's advisory wherever a COLDCARD is selected as a device. Open at the 12 August 2026 capture; the discussion gained a follow-up comment clarifying which COLDCARD selection surfaces show the warning and another proposing a load-time acknowledgment or MOTD feature. Its author states it was drafted with an AI coding tool and that they could not run a local build.
  • Bitcoin.org PR #4905: remove COLDCARD listings · Bitcoin.org · publication date not established
    Merged removal of the COLDCARD listings under the site's published criterion.
Evidence on this page 8 items
  1. R1
    Reported

    The attributed contributions, models and evidentiary limits in the primary-analysis register below

    Source Original technical reports, researcher posts and captured publications linked from each entry

    Evidence →

  2. D2
    Derived

    The grouping of the register entries below by kind of finding, and the merging of one contributor's artefacts into a single entry per kind

    Source This project's editorial arrangement of the register. It sorts and consolidates the entries below; it does not alter what any source published, and every artefact remains separately linked and dated from its entry

    Evidence →

  3. R3
    Reported

    The differing Mk4-class candidate-space figures attributed below to Coinkite, LLFOURN, otaliptus and Block

    Source Each publisher's own stated estimate and assumptions, as captured; no independent measurement of a device is made here

    Evidence →

  4. V4
    Verified

    That the five earlier predictable-key incidents named here are registered and captured in this archive as context, and that no claim about COLDCARD is drawn from them

    Source Each incident's own primary document, captured and listed in the source register

    Evidence →

  5. R5
    Reported

    The existence, age and published proof of concept of the Ill Bloom CryptoJS entropy flaw, and the wallet named as affected by it

    Source Captured posts by ThreatWire and Coinspect of 6 and 7 Aug 2026; no primary disclosure for that flaw is held here and none of it is checked against COLDCARD

    Evidence →

  6. R6
    Reported

    ZachXBT's statement that he has no plans to monitor or trace the incident, and his stated reason

    Source ZachXBT's captured post of 2 Aug 2026

    Evidence →

  7. V7
    Verified

    The stated inputs, licences and described behaviour of the three repositories held here

    Source Each repository's own published README, as captured, read before being described; behaviour is quoted from the repository rather than independently audited

    Evidence → captured 2 Aug 2026

  8. V8
    Verified

    That the upstream files, pull requests and researcher repositories listed above are registered and captured

    Source The source register, where each entry carries its own capture record and revision history

    Evidence →