Blast radius

Two failure families, and only one of them is about your seed

Most incident guidance sorts users by how their mnemonic was produced, because that is what decides whether the wallet keys themselves are enumerable. That question is real and it is the urgent one. It is not the whole of the defect. A second family of features asks the same generator for its own bytes and never consults the mnemonic at all, so the answer to "where did my seed come from" does not reach them.

flowchart TB
  S["How was the mnemonic produced?"] --> D["Dice-only, imported,<br/>or made before the regression"]
  S --> A["Generated on affected firmware"]
  D --> DS["The mnemonic itself is<br/>outside this defect"]
  A --> AS["The mnemonic and everything<br/>derived from it inherit the defect"]
  DS --> F["Separately: device features that call<br/>the affected generator without<br/>consulting the mnemonic at all"]
  AS --> F

  classDef n-act stroke-width:1.5px
  classDef n-safe stroke-width:1.5px
  class A,AS,F n-act
  class D,DS n-safe

Dice-only, imported and pre-regression mnemonics sit outside the left branch and inside the shared one. The feature list is set out in the register below.

flowchart LR
  BR["ngu.random.bytes()"] --> M["libngu my_random_bytes"]
  M --> Y["MicroPython Yasmarang<br/>UID word, SysTick, RTC"]
  M --> N["libngu Yasmarang<br/>constants or at-most-32-bit reseed"]
  OK["ckcc.rng_bytes()"] --> T["STM32 hardware TRNG<br/>analogue transistor noise"]

  Y --> BL["Call sites requiring review:<br/>seeds, paper keys, passwords,<br/>session material and nonces"]
  N --> BL
  T --> GL["Backup password, 7z salt,<br/>HSM user secrets,<br/>SD overwrite blocks"]

  Y -. "the hotfix rebinds this<br/>to the same hardware" .-> T

  classDef n-act stroke-width:1.5px
  classDef n-safe stroke-width:1.5px
  class BR,M,Y,N,BL n-act
  class OK,T,GL n-safe

Both call surfaces were intended to incorporate the STM32 hardware source. Before the fix, only the direct ckcc.rng_bytes() surface did so. The hotfix supplies the hardware-backed symbol used by libngu, which is why the table distinguishes call paths.

Adjudicating the Wizardsardine feature list

On 1 August 2026 Wizardsardine published a long-form post-mortem whose "broken regardless of your seed" section is the most complete public enumeration of this second family captured here. Its author, Kevin Loaec, separately stressed on X that imported and dice-generated seeds are still exposed through those features.

Each asserted exposure is set against what this archive can itself establish from the pinned firmware and libngu clones. The result is that the mechanism Wizardsardine describes holds at every call site checked, that several of its specific numbers are quotable from the source comments, that one claim needs narrowing, and that its list is not exhaustive.

BIP85 descendants follow the active root

BIP85 deterministically derives application entropy from a BIP32 master root. COLDCARD's implementation in shared/drv_entro.py derives the selected BIP85 path from the active wallet secret and then applies the specified HMAC-SHA512 transform. It does not generate an independent random root for the child wallet.

The consequence is conditional. If an affected active root can be recovered, its BIP85 children can be reproduced when their application and index paths are known or searched. If the active wallet included an undisclosed BIP39 passphrase, that passphrase remains an independent input to the root. A migration inventory should therefore include BIP85-derived wallets rather than treating their different mnemonic words as independent provenance. A separate passphrase later applied to a BIP85-derived mnemonic adds another input whose effect depends on its construction and attacker knowledge; it does not change the mnemonic's deterministic provenance.

Benma and Kevin Loaec each published incident-specific warnings about BIP85-derived wallets.

Where this sits in the record

The commit history behind the affected call surface, including an independent walkthrough by Dustin Dettmer and what this archive could and could not confirm of it, is set out on the developer-response page. The wider set of published analyses, with the commercial interests attached to each, is on the response page. For deciding what to do about a particular device or wallet, use the risk guide rather than this register.