What the developer community did

The upstream guard in the 1 August capture

The COLDCARD hotfix replaces the linked rng_get() implementation for the affected boards. It does not change libngu's original #ifndef MICROPY_HW_ENABLE_RNG guard. An integrator could encounter the same condition if it defined that macro as (0) and linked a software rng_get() fallback.

That is no longer the state of the library. ngu/random.c on master changed on 6 August 2026 when libngu #58 was merged: the guard now reads #if MICROPY_HW_ENABLE_RNG == 0 rather than #ifndef, so a board that defines the macro as zero fails the build with #error "get a HW TRNG plz" instead of passing silently. The same commit routes the Linux target through getrandom() in place of random() and rejects a negative byte count in random_bytes(). The captures do not show what any downstream integrator has done with that change. V1

Three pull requests were opened against switck/libngu, two on 31 July 2026 and one on 1 August 2026.

For #59, the proposed split is: the DRBG and CAVP-vector tests, the entropy health rule, and a smaller final random.c rework. All three were opened on 1 August as libngu #62, #63 and #64, and each is held here with its patch, captured on 7 August 2026.

• #62, the HMAC_DRBG core, is closed. Its single commit added an HMAC_DRBG built directly on the SHA-256 backend libngu already uses, rather than mbedtls' HMAC layer, which the author says allocates; the author states it was checked by a host-compiled harness against official NIST CAVP vectors through both backends. The author closed it on 7 August with the comment "No longer relevant given #61" — the proposal the maintainer had merged two days earlier.
• #63, the entropy health rule, is closed. It rejected a source word that was zero or that matched either of the two most recently accepted words, so that a stuck source and an exact two-word cycle were caught, and a rejected word did not advance the history. The author stated a steady-state false-rejection probability of 2^-31 per word and said the rule detected no cycle longer than two words. On 7 August 2026 the author of the merged #61 reviewed it, argued that no guidance he could find recommended rejecting a single A, B, A sequence and that a healthy 32-bit generator would produce one about once in four billion words, and asked whether a documented two-word cycle failure mode justified the check. The author agreed, said he would rebase #64 without the rule, and closed #63 the same day.
• #64, the platform-boundary rework, is merged with four commits. It centralises backend selection so unknown targets fail to build, permits STM32 builds only with MICROPY_HW_ENABLE_RNG=1 or an explicitly declared external rng_get(), requires an explicit ESP32 attestation, uses getrandom(2) on Linux and arc4random() on macOS and FreeBSD, refuses thread-enabled builds without a GIL, corrects the rejection mask in uniform(), and adds negative compile gates that assert each misconfiguration fails. It was merged on 10 August 2026 after scgbckbone approved it on 9 August.

What the stack proposes has narrowed since #59 closed. #59 offered to replace Yasmarang with the author's own HMAC_DRBG; #64 states that the generator "remains Cifra Hash_DRBG" as merged in #61, and hardens the entropy boundary around that generator rather than substituting for it. #62 and #63 were closed on 7 August; #64 was force-pushed and retitled twice on 7 August and merged on 10 August. Each of the three carries a disclosure from its author that it was developed with substantial LLM assistance, then adversarially reviewed, and that maintainer review is still required. V3 R4

#63 drew a substantive review from the author of the merged #61. On 7 August 2026 scgbckbone, writing as a repository contributor, questioned the rule: nothing in NIST SP 800-90B or STM32 guidance that he could find recommends rejecting a single A, B, A sequence, a healthy 32-bit generator will produce one about once in four billion words, and without a documented two-word cycle failure mode the check "seems arbitrary" and only adds an eventual false failure. The author agreed later the same day, said he would rebase #64 without the health rule and closed #63. #64 later received scgbckbone's approval on 9 August and was merged on 10 August. R5

COLDCARD firmware PR #691 began as the companion to libngu #60. It proposes passing the complete SHA256d digest from mk4.rng_seeding() into the widened reseed API rather than unpacking only its first four bytes. Through the day its state moved: open at 06:21 UTC, still open at 16:08, and a draft by the 17:41 capture, marked so at 16:13. A maintainer asked that the libngu changes be opened as a separate pull request against the libngu repository. The rewritten description now depends on libngu #61 rather than #60, a proposal that replaces the generator with a SHA-256 Hash-DRBG and requires a seed of at least 32 bytes, so the old four-byte call is rejected outright. In the capture held on 12 August 2026 a reviewer notes that the same change is already covered by PR #713 commit d16d47b and asks the author to close this draft; a collaborator asks the author to double-check and close it. V6 Its patch is held separately.

A larger firmware proposal followed from inside the repository. On 5 August 2026 scgbckbone, writing as a repository collaborator, opened COLDCARD firmware PR #707, "Improve seed gen & require external entropy for each new wallet", from the branch improve_seed_gen-public. It is a proposal, not shipped firmware: it was open, labelled an enhancement by doc-hex, and carried no review in the first capture held, taken at 15:45 UTC on 7 August 2026. By the next capture, at 19:22 UTC the same day, it was closed in favour of a successor by the same author; that is set out below. Its seven commits are held as a separate patch capture, and what they change is readable there:

• Seed generation mixes the two secure elements with the TRNG. generate_seed() in shared/seed.py previously hashed 32 TRNG bytes alone; the patch appends 32 bytes read from SE1 and 8 from SE2 before the SHA256d.
• The four-byte reseed truncation is removed. mk4.rng_seeding() drops the ustruct.unpack('I', n[0:4]) line and passes the whole 256-bit digest, which is the change firmware PR #691 proposed from outside the repository.
• Every new master seed would require user-supplied entropy. The changelog entry states that key mashing, physical dice rolls or physical coin flips must be chosen, that TRNG, SE1 and SE2 randomness is mixed in as well, and that the user-supplied results are checked for obviously bad distribution. A later commit extends the requirement to CCC keys and temporary seeds.
• The dice-only path would gain a warning screen stating that the rolls are the only source of randomness, that no hardware randomness is mixed in, and that the hash shown while rolling is secret. A UX test asserts the screen appears. This describes a proposed code change; what the shipped firmware does today is set out under the dice conditions.
• The libngu submodule is bumped so the SHA-256 Hash-DRBG merged as libngu #61 replaces Yasmarang. A seventh commit then excludes schnorr and musig from the build to save flash and adds an NGU_STM32_EXTERNAL_RNG_GET macro; the author states on 7 August that this commit requires a further upstream proposal, libngu #68, and another submodule bump after it merges. That proposal was merged upstream the same day.

The proposal is unmerged in the capture held, and each of its changelog entries is added to releases/Next-ChangeLog.md, the file the repository uses for changes not yet published in a normal release. Nothing held here states that it will be adopted. It is recorded as what was proposed, and where it stood on 8 August 2026. V7 U8

It did not stand for long. Between the two captures held of that page, both taken on 7 August 2026, #707 moved from open to closed, and the same author opened firmware PR #713, "Improve seed generation - mash timing with microsecond-resolution", stating that it replaces #707. It was opened with seven commits and was still open in the capture held at 23:42 UTC on 14 August 2026, by which point it had been force-pushed to commit 11d8130 with a five-commit series that revises the mash-entropy implementation, adds a testing fixture and disables MicroPython threads for the unix port. The conversation also gained cross-references to PR #691 and #700 and an author self-review comment. What it changes about its predecessor is the mash path rather than the entropy requirement: timing is hashed at microsecond resolution at the raw key edge, 128 presses are required, and one bit of entropy is credited per press, which the proposal attributes to Peter Todd's push-button generator model. A proposal replaced by its own author within two days is worth stating plainly rather than leaving the record pointing at the version that was withdrawn. V9

A process observation on the firmware repository

The review path of the firmware repository itself drew comment. On 2 August 2026, mutatrum observed that most changes in coldcard/firmware land directly on master or are merged without review comments, and asked what the open repository provides in that state. R10 That is an attributed observation about the visible history, not a measurement this archive has repeated: no independent count of direct-to-master commits or reviewless merges has been made here.

Independent commit-history analysis

On 1 August 2026, bitcoin++ Insider Edition published a guest analysis by Core Lightning developer Dustin Dettmer, announced the same day on X. It reads the firmware commit history around the disabled hardware-RNG guard and the call chain that left seed generation on the software generator, and argues that the board override was aimed at a symbol the seed path never uses, while silencing the build condition that would have exposed the mistake. Dettmer attributes the defect's introduction to a 2021 commit and describes the developer's intent; both are reported here as published, not independently checked. R11

One further code-level assertion was made on 7 August 2026, in an exchange the disclosure history records: replying to a Coinkite correction about where the weak generator came from, James O'Beirne linked a specific libngu blob and said the Yasmarang copy in that library was weaker still because it used hardcoded constants. The characterisations on both sides are contested and are set out there; the source lines he pointed at can be checked here. The held capture of ngu/random.c from before the 6 August merge does define a second Yasmarang inside libngu, with fixed initial state (0x0a8ce26f, 69, 233), XORed into every output alongside CHIP_TRNG_32(), and a reseed() that assigns only the 32-bit yasmarang_pad. That is a second generator, distinct from MicroPython's; how it broke sets out how the two combine. Whether one is weaker than the other is a comparative judgement this archive does not make. V12

Where public discussion was found

Two details from Optech

Downstream public reactions

The disclosure also prompted decisions and reviews in other public repositories. These records show what those projects did or proposed. They do not establish that another product shared COLDCARD's defect.

Licensing and forkability

The incident renewed a question about what the published source permits. On 2 August 2026, notgrubles asked whether Coinkite's licence would legally prevent forking the firmware to provide longer-term support if the company went out of business. R19 The question sits against an attributed history: a community account posted the same day links the firmware's Trezor-derived origins and a later relicensing under the Commons Clause to the outside-review question. R20 Neither post is a legal analysis, and this archive has not itself construed the licence terms; the question is recorded as open.

Follow-up items as checked on 15 August 2026, except where a later date is given

• Coinkite promised a technical postmortem. The captured statement does not give a publication date or detailed scope. The company's blog index as of 15 August 2026 lists no postmortem; its newest incident post is "Update on Customer Data Retention", and the most recent incident write-up remains the 4 August "Adding to the Public Record on Our Ongoing Investigation". V21
• No captured source announces an independent audit of the fixed firmware. This is an archive limitation, not proof that no private review exists. It still holds against material registered to 15 August 2026: the incident-funded review effort captured on the AI page scans Bitcoin repositories at large and is not presented as an audit of the fixed COLDCARD firmware.
• No incident-specific CVE record was identified. NVD remained unreachable or inconclusive from this collector on 9 August 2026; no incident-specific CVE for COLDCARD/Coinkite has been captured, and the only NVD result seen earlier was the CVE-2019-14356 OLED side-channel record. A differently worded or unpublished request could be missed.
• The two reproduction scripts described by Gregory Sanders (instagibbs) remain unavailable here. A dated search of his public GitHub repositories, code results and gist index found no matching publication, so the archive still cannot inspect the test conditions or method. Nothing registered up to 15 August 2026 supplies them. U22