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.

COLDCARD firmware PR #692 patch

coldcard-firmware-pr-692-patch

https://github.com/Coldcard/firmware/pull/692.patch

Organisation
Coinkite
Evidence role
Repository patch
Published
not established
Source changes
0
Detected differences
0
Unreviewed
0
Copies held
1

Patch content for the TRNG error-recovery proposal. Kept separately from the conversation and review-state capture.

Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked .

  1. Earliest copy held Current
    seen · Captured here 11,108 chars
    Extracted text as captured 
    From 20fb8082338a4e313f1f817729ceea078c87eb31 Mon Sep 17 00:00:00 2001
From: Silexperience <[email protected]>
Date: Mon, 3 Aug 2026 09:04:49 +0000
Subject: [PATCH] rng: recover the TRNG after a seed/clock error instead of
 failing forever
Since the 2026-07-31 hotfix (ca724637) rng_get() reads the hardware TRNG
and raises OSError(EFAULT) on a 10ms timeout, replacing a software PRNG
that could not fail. rng_init() only re-enables the peripheral when
RNGEN is clear, but per RM0432 25.3.7 (RM0351 for the L4) a seed error
latches SEIS and stops DRDY while leaving RNGEN set. Recovery requires
clearing SEIS and then toggling RNGEN off->on, so rng_init() is a no-op
in exactly the state where it is needed: one transient glitch makes
every later call time out permanently.
That is not survivable by the user, because rng_get() is now reached
from the keypad scan-order shuffle in _start_scan(), which runs from a
Pin.irq callback before login. The OSError reaches IMPT.handle_exc ->
die_with_debug -> show_logout(), so the device lands on a fatal-error
screen with no way to enter a PIN and therefore no way to reach the
upgrade menu.
  rng_reset()     clear the clock, drop RNGEN, clear SEIS/CEIS, re-enable,
                  and discard the first word as the reference manual asks
                  (the old "TODO: throw out some samples?" case)
  rng_init()      reset when RNGEN is clear *or* any error flag is set
  rng_try_once()  non-throwing single attempt; rejects the word if an
                  error latched while waiting for DRDY
  rng_get_or_fault()
                  up to RNG_MAX_ATTEMPTS with a reset between each, then
                  raise as before
The throw-on-persistent-failure contract is unchanged and there is no
fallback to software entropy: a genuine hardware failure still raises.
mempad.py / keyboard.py: wrap shuffle(self.scan_order) in try/except.
Scan-order randomisation is anti-Tempest hygiene, not a secret, and must
never be able to take the keypad down before login.
COLDCARD_Q1/rng.c is a symlink to the Mk4 file, so Mk4/Mk5/Q are all
covered by the one change.
---
 shared/keyboard.py       |  9 +++-
 shared/mempad.py         |  9 +++-
 stm32/COLDCARD/rng.c     | 92 ++++++++++++++++++++++++++++++++--------
 stm32/COLDCARD_MK4/rng.c | 92 ++++++++++++++++++++++++++++++++--------

    Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.

How to check this yourself

The excerpts and plain unified diffs above show the text this project held and how it changed. To verify a quotation, compare it against the page itself or against the Internet Archive's copies, which are independent of this project.

Complete captures are held offline rather than mirrored here, so this page shows diffs and excerpts. If a quotation is ever disputed, the full copy can be produced. Ask.