A dim laboratory bench: an open hardware-wallet case, a metal device with an amber display and a large knob, and a stack of envelopes sealed with red wax, lit by a desk lamp, with flasks and a microscope in the background.
Original AI-generated illustration.

Dashjr Publishes Nine COLDCARD RNG Concerns: What the Reviews Missed, and 45.9 BTC That Have Now Moved

NodeWitness Team 12 min read

On November 9, Luke Dashjr published nine concerns about COLDCARD's random-number generator and rejected the idea that only an AI could have found problems in that code. The argument lands months after the reviews that missed the seed-generation flaw. On the chain, 45.9 bitcoin that had sat still since July left one of the case's confirmed addresses on October 28.

Luke Dashjr posted a thread at 17:54 Madrid time on November 9 with nine concerns about COLDCARD's random-number generator [1]. He says he had already raised them with Coinkite privately, and that he has "no clue" whether the company has since fixed them. He is also explicit about the limits: he is not claiming that all of them can be weaponised, or that they are definitely bugs [1].

He says he is publishing them because he hears NVK "pretending humans couldn't find the Coldcard defect" [1]. In the next post he is blunter: "the claim that only a "genius AI" could find issues with the RNG is a blatant lie" [2]. He adds that this is what he found at a quick glance, not a full in-depth audit [2].

That line answers a post by NVK, Coinkite's co-founder, issued an hour earlier, at 16:50 Madrid time. After listing at least 15 external reviews or research efforts, two paid third-party product reviews — a Mk4 review in 2022 and, he says, a seperate Q review in 2024 — and 85 candidate findings from Rob Ham's OpenAI Cybersecurity Harness review, he concluded: "The uncomfortable truth is that It took a new Ai model to find what humans couldn't" [3]. The day before, he had written that "it took kimi-k3 1 week" [4].

How the seed flaw works, and how to migrate if you are affected, is already in our breakdown of the entropy bug. What is new today is the other layer: what each review was in a position to catch, what it missed, and what has happened to the stolen funds since our last piece on Wave 3.

Dashjr's nine points, as he put them

The nine concerns are not a restatement of the 2021 bug that left seeds weak. They target the generator code that was in use after the late-July fix [1][5]. In his own wording, shortened [5]:

  1. A TODO in rng_init asks whether the first STM32 sample should be discarded; at least some chips appear to require it.
  2. The driver does not check the seed-error (SEIS) or clock-error (CEIS) bits.
  3. The STM32 manual also calls for some unspecified post-processing for cryptographic use.
  4. random_buffer checks for repeated RNG output; direct calls to rng_get do not.
  5. If that check ever fires, rng_get_or_fault missed the error, so that routine cannot be considered safe until the other check is shown to be redundant.
  6. Even if the STM32 returned a deterministic result, the secure-element randomness might have been expected to keep entropy at a full 256 bits; he asks why that was not the case.
  7. Because this path was not being used before the fix, it is essentially a novel RNG and should be fully tested as such.
  8. The patch keeps the old PRNG from being compiled in, but only as a build-time tweak; he would like a runtime assertion.
  9. If rng_get is called from a context that is not Python-exception safe and the RNG times out, mp_raise_OSError could invoke undefined behaviour, a crash, or, at boot, a risk of bricking a slow device.

What each review could, and could not, catch

On August 20, Coinkite released firmware 5.6.1 for Mk4 and Mk5, and 1.5.1Q for Q [6][7]. The current recommended standard releases are 5.6.3 and 1.5.3Q, dated September 30 [8][9]. Installing them does not repair an existing seed.

The paid Mk4 review, 2022. Coinkite's public disclosure history records a professional audit, March 1–14, 2022, by Lazy Ninja. It examined PIN derivation, attempt-rate limiting, the microcontroller firewall and random-number generation, before the first public Mk4 firmware [10]. One recommendation that was adopted was to seed the runtime generator with authenticated entropy from both secure elements, starting in 5.0.0 [10]. The seed-generation flaw, though, was not an intentional weak design. It was a link-time error that left rng_get() resolving to MicroPython's Yasmarang software PRNG instead of the hardware TRNG path [11][12]. Coinkite has written that the disable flag "looked correct," and that the bug lived at the boundary between two unrelated submodules, not in the Bitcoin-specific logic that most reviews focus on [11]. That 2022 Mk4 review, which did look at RNG, did not stop it. The defect had been in the code since March 2021 [11][12].

The 2024 Q review. NVK cites it as the second paid product review completed before the incident [3]. Coinkite's public chronology, last updated August 20, 2026, does not list a professional Q audit in 2024: the only entry classed as such remains the 2022 Mk4 review [10]. Until Coinkite documents it, we treat that second review as NVK's account, not as a fact established by that record.

The May–June 2026 AI review. The same history describes an enterprise AI review, running from May 1 to June 26, that produced 85 candidate findings: 8 high, 37 medium, 20 low and 20 informational [10]. Coinkite says it reviewed each one by hand, closed the work on June 26, and shipped several fixes, including a Delta Mode path [10]. NVK adds that this review — which he identifies as Rob Ham's OpenAI Cybersecurity Harness — did not include the seed-generation defect [3]. That matches what Coinkite wrote on August 4: the AI-assisted review in the weeks before the exploit did not catch the vulnerability [11].

Post-incident model tests. In that same August post, Coinkite said that after the incident it also tested the code against Kimi K3, Claude Fable and Codex 5.6, and that none of them caught it [11]. That sits awkwardly next to NVK's November wording: that it took kimi-k3 a week, and that it took a new AI model to find what humans could not [3][4]. We are reporting both statements; we are not reconciling them.

Dashjr's list and the August firmware. Several of the points in the thread do have a counterpart in 5.6.1. The changelog and Coinkite's advisory document detection of the STM32 seed-error flags (SEIS and SECS), bounded retries, discarding the next 12 hardware words after a recoverable error, and a boot-time test that rng_get() enters the hardware read path and stops the device if it does not [6][7]. The release also began sampling SE1 and SE2 directly for each new master seed, rather than only at boot [7].

Other items are still visible in the public source as reviewed on November 10. The repeated-output check remains in random_buffer, not in every direct rng_get call [13]. Clock-error flags (CEIS/CECS) are ignored on purpose: a comment in the source cites RM0432 and ST errata as saying a clock error does not invalidate generated numbers when data is ready, and that a dead clock still fails closed on a timeout [13]. Dashjr asked for a runtime assertion; Coinkite shipped a boot-time self-test [6][7][13]. And he is clear that this was not a complete audit [2].

Where the funds we can actually see sit today

The case has never had a single agreed total. TRM Labs put the figure at 1,816 BTC in early August; Galaxy Research, on September 7, said its published total would be about 1,806 BTC if one still-unconfirmed vault were counted, and that 82% of the stolen bitcoin was still in the attackers' original addresses [14][15]. Those figures, each with its method and its date, are in our coverage of the escalation and in the Wave 3 piece.

We are not trying to rebuild that total today. What we have done is reread, at our node's tip, the five addresses that public trackers treat as confirmed [16][17]. At 13:06 Madrid time on November 10, our node was in sync at block 975,299 [18]. At that same height on the chain:

  • bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r still holds 562.02148293 BTC and has never spent [16][19].
  • bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 still holds 398.47576957 BTC and has never spent [16][19].
  • bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q still holds 89.62329890 BTC and has never spent [16][19].
  • bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0, the collector that forwarded the 562 BTC on July 30, still holds 32.45061090 BTC; there are no new spends [16][17][19].
  • bc1qtfrwa4j6rmj9rsgspv6a0yjumkg39js2numu75, which received 45.90251994 BTC on July 31 and had still not spent in October, was almost emptied on October 28 [16][19].

That last exit is what was missing from our October 20 piece, which cited Bitquery's tracker as of October 19: last movement on October 2, and the largest address, at 562.02 BTC, still untouched [15][16]. At 22:57 Madrid time on October 28, in block 973,601, the address spent 45.90251994 BTC in transaction 4882d3f6eb054e78b81e45b1d6e7edbcc962c15750523da90e93b9948ed91a76: 154 inputs, 196 outputs, a fee of 36,734 sats [20]. Only one of those inputs comes from this address; the rest, and a long run of repeated denominations, are consistent with a CoinJoin. 0.00003000 BTC of dust was left unswept [19].

Two and a half hours later, at 01:32 Madrid time on October 29, the largest output of that transaction — 40.73690951 BTC at bc1qu2cdpatut3fglsvtzastsft8ajk6pya0u6scu6 — was fully spent in block 973,617, in another transaction with 222 inputs and 267 outputs [21]. That movement occured the same night.

The five confirmed addresses still hold 1,082.57119230 BTC. Almost all of that balance sits in the three largest piles, which have not been touched. This is not the stolen total, and it is not an update to Galaxy's 82% figure: it is what is visible, today, in this specific cluster [18][19].

What does not change if you still use a COLDCARD

Neither Dashjr's thread nor this 45.9 BTC movement changes whether your seed is exposed. That depends on the model and firmware that created it, not on what the attackers do with coins already taken, and not on whether current firmware closes every one of the nine points. If it falls in the affected range, the path is still the one in our breakdown of the flaw: a new seed, current verified firmware, a small test transaction, then the rest.

The proposed class action in Ontario, which has not been certified, does not replace that migration either. What the claim alleges, and what is worth keeping on file, is in our piece on the lawsuit.

Sources

Source type in brackets. Times in UTC; in the body they are converted to Madrid time (UTC+1). Checked on November 10, 2026.

  1. Luke Dashjr, post on X, 16:54:36 UTC on November 9, 2026 (17:54 Madrid). Prior private report to Coinkite; does not know whether it has been fixed; not claiming all items are exploitable bugs. (Primary, thread author)
  2. Luke Dashjr, post on X, 16:54:36 UTC on November 9, 2026. "the claim that only a "genius AI" could find issues with the RNG is a blatant lie"; quick glance, not a full audit. (Primary, thread author)
  3. NVK, post on X, 15:50:42 UTC on November 9, 2026 (16:50 Madrid). Long text: 15 reviews, two paid (Mk4 2022 and a Q review in 2024), 85 findings from Rob Ham's OpenAI Cybersecurity Harness, and "It took a new Ai model to find what humans couldn't." (Primary, Coinkite co-founder)
  4. NVK, post on X, 16:39:21 UTC on November 8, 2026 (17:39 Madrid). "It took kimi-k3 1 week." (Primary, Coinkite co-founder)
  5. Luke Dashjr, X thread, posts 1 through 9, 16:54 UTC on November 9, 2026. The nine points, including the rng_init source link. (Primary, thread author)
  6. Coinkite, COLDCARD Security Update: Seed Generation, Transaction Integrity, and Data Isolation, August 20, 2026. Firmware 5.6.1 and 1.5.1Q; seed-error checks, 12-word discard, boot-time test; updates do not repair existing seeds. (Primary, company)
  7. Coinkite, History-Mk.md, 5.6.1 section, August 20, 2026. Changelog: SEIS/SECS, rng_get() self-test, direct SE1 and SE2 sampling, Hash_DRBG. (Primary, firmware repository)
  8. Coinkite, Current COLDCARD Security Status, verified October 1, 2026; checked November 10. Standard releases 5.6.3 / 1.5.3Q. (Primary, company)
  9. Coinkite, COLDCARD Firmware 5.6.3 & 1.5.3Q: Codex32 and Shamir Backups and ChangeLog.md, September 30, 2026. (Primary, company)
  10. Coinkite, Security Disclosure History, updated August 20, 2026; checked November 10. Lazy Ninja audit (March 2022); AI review May 1–June 26, 2026 (85 findings); July 30 incident attributed to public investigation; no professional Q audit in 2024 on that chronology. (Primary, company)
  11. Coinkite, Adding to the Public Record on Our Ongoing Investigation, August 4, 2026 (updated August 30). Yasmarang link-time error; pre-incident AI review missed it; Kimi K3, Claude Fable and Codex 5.6 also missed it, according to that post. (Primary, company)
  12. Coinkite, seed-generation advisory, July 30–31, 2026, and technical backgrounder. (Primary, company)
  13. COLDCARD firmware repository, stm32/COLDCARD_MK4/rng.c on master, checked November 10, 2026. Warm-up discard in rng_selftest; clock-error flags ignored on purpose; repeat check only in random_buffer. (Primary, source)
  14. TRM Labs' 1,816 BTC figure, as cited in our coverage of the escalation, August 6, 2026. (Secondary, cited in our own piece; original figure is TRM's)
  15. Galaxy Research / CoinDesk, September 7, 2026, and Bitquery as of October 19, as cited in our Wave 3 piece. About 1,806 BTC, 82% unmoved on September 7; last movement October 2 in the October check. (Secondary, via our own piece)
  16. Bitquery, Coldcard Hack Tracker Live, public snapshot at 08:30 UTC on October 28, 2026, block 973,522: the five confirmed addresses and 45.90254994 BTC still unspent at bc1qtfrwa…. (Secondary, tracker; the page did not respond on November 10; the snapshot is used only to identify addresses and the prior state)
  17. PublicAML, Coldcard hack: where the stolen bitcoin is now. Path of the July 30–31 waves and the collector bc1qnk4zh…. (Secondary, public tracker)
  18. NodeWitness, /api/node/status, November 10, 2026, 13:06 Madrid time: primary node in sync at block 975,299. (Primary, own node)
  19. Own check of balances and spends for the five confirmed addresses, and of the 40.73690951 BTC destination, at block 975,299 on November 10, 2026. (Primary, on-chain read)
  20. Transaction 4882d3f6eb054e78…8ed91a76, block 973,601, 21:57 UTC on October 28, 2026 (22:57 Madrid): 45.90251994 BTC from bc1qtfrwa…; 154 inputs, 196 outputs, fee 36,734 sats. (Primary, chain)
  21. Transaction 24f3619f057885be…3fc8b144, block 973,617, 00:32 UTC on October 29, 2026 (01:32 Madrid): full spend of 40.73690951 BTC from bc1qu2cdp…; 222 inputs, 267 outputs. (Primary, chain)
  22. The Defiant, Luke Dashjr Publishes Nine Coldcard RNG Concerns, November 9, 2026. (Secondary, press)
  23. CriptoNoticias, ¿La IA descubrió los fallos de Coldcard? Luke Dashjr cuestiona esa versión, Cristina Cedeño, November 9, 2026. (Secondary, press)

More in Privacy and self-custody

See all 34 articles in Privacy and self-custody →

Last updated: November 10, 2026