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.

Instrumented Mk4 TRNG read count

bigshiny0-2085547011743338845

https://x.com/bigshiny0/status/2085547011743338845

Captured screenshot of the post by @bigshiny0, posted 7 Aug 2026, 02:02 UTC
@bigshiny0 posted captured full-size capture → original post →
Author
@bigshiny0
Organisation
independent
Evidence role
social statement
Posted
Capture status
capture held

Shiny reports instrumenting Mk4 firmware at the point where it reads the STM32 hardware RNG and then requesting the same 32 bytes seed generation uses: on 5.6.0 exactly eight hardware reads were observed, which the poster reads as direct proof that the seed request reached the true RNG, and on affected firmware the same test is said to show zero hardware reads with the bytes coming from MicroPython's software PRNG instead. The post frames this as a real-device path test rather than statistical inspection of whether output looks random, and asks why such a test was not already in COLDCARD's suite and run routinely on hardware. It quotes the vendor's reply to another account insisting there was no weak entropy fallback and that precision matters, so it is a direct methodological answer to COLDCARD on what a test would actually settle. No instrumentation code, device identifier or log is published with it, and the affected-firmware half is stated as what the test would have shown rather than a run that was performed. The result and the inference are the poster's own and are not reproduced here.

This post is registered as evidence and has a locally held capture. The original remains the canonical publication.

How to check this yourself

Compare the screenshot or a quotation against the original while it is available.