It is not incredible, and the reason is worth understanding because it tells you what audits can and cannot buy you.
A broken RNG is invisible in its output. That is the whole problem.
Feed the output of a well-seeded CSPRNG and a badly-seeded one into every statistical test you have — dieharder, NIST STS, entropy estimators, anything — and both pass. They are supposed to. A PRNG's entire job is to produce output that looks random. The defect is not in the bytes, it is in how much unpredictability went IN, and that is not a property you can measure by looking at what came OUT.
So an auditor cannot catch this by testing. They have to catch it by reading, and the reading was hard for a specific reason.
WHERE THE BUG ACTUALLY LIVED
Not in a line saying "use weak randomness". The 2021 migration to libsecp256k1 pulled in libNgU, and seed generation moved from `ckcc.rng_bytes()` to `ngu.random.bytes()`. On that path the call resolved to MicroPython's software fallback instead of the hardware RNG.
Read the wallet's own source and you see a call to a random-bytes function from a crypto library. That looks correct. The defect is in which implementation that name BINDS TO at build time, inside a submodule, on that platform. The vendor's own words are that the PRNG "is from a submodule" they did not know was in the codebase.
An audit scoped to the application's source can be thorough and still miss it, because the bug is not in the application's source. It is in the resolution.
WHAT WOULD HAVE CAUGHT IT
Not more code review. Instrumentation. Something that asserts, on the actual device, that the hardware RNG was READ during seed generation — a counter, a test hook, a boot self-test that fails loudly if the TRNG contributed nothing. That is a different discipline from auditing, and almost nobody commissions it.
Which is also the honest argument for dice, and why I keep repeating it: dice are the only entropy input the USER can independently verify went in. `printf '<rolls>' | sha256sum` compared to the displayed hex proves the device used your rolls and nothing else. It does not test the RNG — that is impossible from outside — it removes the RNG from the trust chain entirely.
WHERE YOUR CRITICISM DOES LAND
Five years is a long time, and this is a single, identifiable, security-critical call. A targeted review of "does the seed actually come from the TRNG on this hardware" is exactly the sort of thing you would hope a hardware wallet commissions specifically, separately from a general audit. That it apparently was not is a fair thing to be angry about.
And the closed-source period matters here for a concrete reason rather than an ideological one: this is a bug an outsider finds by reading the build, not by using the product. Fewer readers, more years.
So: not incredible. Structurally difficult, plausibly under-prioritised, and a good argument for verifiable entropy over trusted entropy.
