The advisory is thin on the actual defect — "early analysis", formal technical review still to come — so the useful thing right now is triage order, not speculation about the RNG.
First filter I haven't seen raised: was the seed generated on the Mk3, or imported into it? If you imported a seed produced by dice or by another device, the Mk3's random number generator never touched it and you're outside the blast radius. That one question decides whether any of the rest applies to you.
If it was device-generated on 4.0.1 (March 2021) through 5.0.3, treat every address ever derived from that seed as permanently burned — not just the ones currently holding funds. That includes addresses you handed to third parties and anything sitting in a watch-only wallet. Moving the balance fixes the funds; it doesn't fix the exposure.
On the passphrase stopgap Coinkite suggests: it's genuine defense-in-depth, but it sits on the same foundation. An attacker who can enumerate weak seeds still has to brute force the passphrase, so it buys time rather than undoing a bad seed. Coinkite frames it as "interim" and that's exactly right — it's a bridge to a real rotation, not a substitute for one.
Multisig changes the math and nobody's mentioned it: an Mk3 key inside a 2-of-3 doesn't hand anyone your funds on its own. It quietly downgrades you to 1-of-2 effective security. Not an emergency, but don't file it under "unaffected" either.
And following on from the mempool point above — everyone affected is about to bid for the same block space. If you're rotating, move the high-value UTXOs first and at a fee that actually confirms. Cheap-and-patient is the wrong strategy when the entire affected cohort is racing you for the same blocks.
Order that works: new seed on an unaffected device (Mk4, Q or Mk5) → verify offline → small test transaction → then move, largest first.
The advisory is thin on the actual defect — "early analysis", formal technical review still to come — so the useful thing right now is triage order, not speculation about the RNG.
First filter I haven't seen raised: was the seed generated on the Mk3, or imported into it? If you imported a seed produced by dice or by another device, the Mk3's random number generator never touched it and you're outside the blast radius. That one question decides whether any of the rest applies to you.
If it was device-generated on 4.0.1 (March 2021) through 5.0.3, treat every address ever derived from that seed as permanently burned — not just the ones currently holding funds. That includes addresses you handed to third parties and anything sitting in a watch-only wallet. Moving the balance fixes the funds; it doesn't fix the exposure.
On the passphrase stopgap Coinkite suggests: it's genuine defense-in-depth, but it sits on the same foundation. An attacker who can enumerate weak seeds still has to brute force the passphrase, so it buys time rather than undoing a bad seed. Coinkite frames it as "interim" and that's exactly right — it's a bridge to a real rotation, not a substitute for one.
Multisig changes the math and nobody's mentioned it: an Mk3 key inside a 2-of-3 doesn't hand anyone your funds on its own. It quietly downgrades you to 1-of-2 effective security. Not an emergency, but don't file it under "unaffected" either.
And following on from the mempool point above — everyone affected is about to bid for the same block space. If you're rotating, move the high-value UTXOs first and at a fee that actually confirms. Cheap-and-patient is the wrong strategy when the entire affected cohort is racing you for the same blocks.
Order that works: new seed on an unaffected device (Mk4, Q or Mk5) → verify offline → small test transaction → then move, largest first.