← Back to all insights

After the Coldcard theft in July, I read the actual firmware of eight Bitcoin wallets, and then I read their history: every release, going back as far as 2014. Not the documentation, the code, at fixed versions, with the results recomputed so anyone can check them.

This is the second of two pieces. The first asked whether you can check your own seed. This one asks a different question: does the wallet still make the same seed it made last year, and did it ever quietly make a weaker one than it promised?

The answer is more reassuring than the headlines and more unsettling than the marketing, both at once. Let me be plain about the stakes before the detail, because most of what follows is real but not an emergency.

What is and is not at risk

Nothing here lets someone drain your wallet tonight. Two things are real. One: some firmware made seeds weaker than the word count implied, and one case is still shipping. Two: several wallets changed how they turn dice into a wallet, so a backup of your dice rolls may rebuild a different, empty wallet. If you backed up your words, which is what you are told to do, that second problem never touches you.

The number is one number

A quick recap from the first piece, because everything rests on it. Your wallet is one large random number. The twelve or twenty-four words are just that number written so a human can copy it. Everything else, every address and key, is calculated from it. So there are only two ways to be harmed: the number was easier to guess than you thought, or you cannot reproduce the number when you need it. This piece is about both.

Coldcard had a second bug, and it is still shipping

The famous one is public: from 2021 to July 2026, a mistake made Coldcard seeds guessable, and in July someone guessed a great many of them. Hundreds of bitcoin, gone. That is settled and it is not my finding.

Reading the history, I found a separate problem in the same device, older and still live. When you make a seed by rolling dice and tapping the result, holding a key a moment too long makes the device count one tap as several. The screen climbs to "99 rolls" while your hand supplied far fewer. As few as 33 real rolls can display 99, which is roughly 85 bits of randomness in a seed the screen presents as 256.

The check meant to catch bad dice does not catch this, because the rolls that are recorded still look evenly spread. The count is inflated, not the distribution. This behaviour was in shipping firmware for about six years, from August 2020, and the fix for the flagship models landed only in August 2026. The cheaper Mk3 line still ships it today.

Honest severity: this bites only someone who uses dice mode, on the affected model, and holds the buttons. That is a small group. But it is real, it is current, and the fix is trivial, so it is worth saying out loud.

Same dice, three different wallets

This is the finding that surprised me most, and I checked it three ways before believing it.

SeedSigner changed how it converts dice into a seed, twice. Feed the exact same 99 dice rolls to three different versions and you get three completely different, unrelated wallets:

version 0.2.0 to 0.4.4  ->  smoke grid actor echo stick girl ...
version 0.4.5           ->  resist crawl output pizza floor damp ...
version 0.4.6 to today  ->  team dinosaur twist public grit turn ...

The same physical dice, three eras of firmware, three strangers' wallets. Verified by computing all three from the published source.

The reason is mundane, which is what makes it dangerous: an early version treated the rolls as a number, a later one started hashing them, and a third stopped rewriting the digit 6 before hashing. None of that matters if you wrote down your words. It matters enormously if you wrote down your rolls, put them in a drawer for three years, and try to rebuild on today's firmware. You will get a valid-looking wallet that has never held your coins.

Keystone has the same shape of problem in a different form. For about two and a half years, across some seventy releases, its dice mode would build a "24-word" seed from as few as 50 rolls, roughly half the randomness the word count implies. The telling detail: the firmware never even recorded how many times you rolled until the fix in mid-2026, so nothing could have enforced a minimum. And Krux quietly dropped a separator character from its dice format in August 2022, so rolls saved on the older version rebuild a different wallet on the newer one.

Two conventions pretending to be one standard

There is a neat, quiet split in how wallets turn dice into a seed, and no device tells you which side it is on.

Coldcard, SeedSigner and Krux hash the digits exactly as you tapped them. Keystone and the widely used Ian Coleman website first rewrite every 6 into a 0, then hash. Same rolls, two camps, two different wallets:

hashed as typed   ->  hole luggage safe present express tragic ...
6 rewritten to 0  ->  tip toward alcohol rule pave weird ...

I confirmed the digit 6 is the sole cause: rolls with no 6 in them produce identical wallets across all of these.

While checking the Ian Coleman tool, I found a worse default in it. Its dropdown ships set to a "raw entropy" mode, and in that mode 50 dice rolls produce a six-word phrase, far weaker than a normal seed, with no warning shown. Pick "12 words" from the dropdown and it hashes properly and warns you. So the tool warns in the safe case and stays silent in the weak one. The saving grace is that six words is visibly wrong and cannot easily be loaded into a real wallet, so this is a bad default rather than a silent trap. But it is a bad default on a tool a lot of people use.

Who got it right

Reading history is only fair if you report the clean results as loudly as the ugly ones, so here they are.

Trezor: twelve years, both product lines, over a hundred releases, and the way it builds a seed has never once produced a weaker result than advertised. A genuinely strong record, and it matters because Trezor has the largest installed base of any open wallet.

BitBox02: five independent sources of randomness in the very first public commit in 2019, combined the same careful way ever since, verified against the project's own test vectors across seven years.

Bitkey, from Block: if its randomness source ever fails, the device stops rather than carrying on with a weak value. That is the exact opposite of the Coldcard failure, and it is the right instinct.

The contrast is the lesson. The wallets that stayed clean did the same boring things: use the hardware's randomness, stop if it fails, and never quietly change what you already shipped.

What to actually do

Short and practical, because that is the part that protects you.

How this was checked

Every claim above was reproduced from each project's published source at a fixed version, and the dice results were recomputed independently, in some cases three separate ways, before being written down. The wallets covered were Coldcard, SeedSigner, Krux, Keystone, Trezor, BitBox02, Blockstream Jade and Bitkey, plus the Ian Coleman tool. Where a finding is still live, the vendor is being notified before this is widely shared. Where I could not settle something from source alone, I have left it out rather than guess.

The single most useful habit, again, because it is the only one that needs no trust: a dice-made seed on Coldcard, SeedSigner or Krux can be recomputed on a plain laptop with one command, against nobody's word but arithmetic. If you can check it yourself, you do not have to wonder.