Libbitcoin Explorer is a command line tool, and one of the things it can do is generate the randomness a wallet seed is built from. For nine years, from 2014, that command seeded its random number generator with 32 bits of the system clock and nothing else.
A seed is supposed to come from a space so large that no one could ever count through it. This one came from a space of 4,294,967,296 possibilities, which is a number a laptop counts through in days.
The researchers who found it in 2023 named it Milk Sad, after the first two words the tool produces when the clock value is zero. They found it because they were investigating thefts that were already happening. Wallets built with the tool were being emptied in coordinated sweeps across several chains, more than $900,000 in total, and about 29.6 BTC in one sweep on 12 July 2023.
Every affected seed was twelve or twenty-four valid words with a correct checksum. Every wallet that imported one accepted it.
Nothing about the seed could tell its owner it was one of four billion. The only thing that could was knowing where the randomness came from, and the tool's own documentation had said for years that the command was not for production use.
Provenance was the entire defense. Nobody was checking it.
F104-03 taught you to check the provenance of the device: where the box came from, whether the seal means anything, why a pre-filled recovery card is the sign to walk away. This lesson is the same discipline applied one layer down, to the seed itself.
The words are not the secret
A seed phrase is a way of writing down a number. Twelve words encode 128 bits, twenty-four encode 256, and the last word carries a few bits of checksum so a transcription error is caught on import.
The security of everything built on that number depends on one property: that it was chosen from the whole space, uniformly, by a process nobody else can reproduce. That property is invisible. Two seeds, one drawn from the full 128-bit space and one drawn from a space of four billion, are both twelve valid words with correct checksums. Every wallet accepts both. Every explorer shows both as ordinary addresses.
So the question is never "does this seed look right". It is "where did the randomness come from", and the answer is a fact about a process, not about the words.
Three ways provenance fails
A bad generator. Milk Sad is the clean example: a generator that produced output of the right length from input of the wrong size. It is not the only one. In 2023 the firm Unciphered disclosed that a JavaScript library used by many browser wallets between roughly 2011 and 2015 drew its randomness from a weak source, so that an estimated millions of dollars sat in addresses an attacker could enumerate. The pattern is the same: the code was open, widely used, and wrong, and the seeds it produced were indistinguishable from good ones.
A seed somebody else generated. A device that arrives with the recovery card already filled in. A friend who "set it up for you". A vendor's cloud backup that offers to restore a seed it made. In every case the seed may be perfectly random, and it does not matter, because a seed with a second holder is not a secret. F104-03 called the pre-filled card hostile. This is the general rule it was an instance of.
A seed you did not watch being made. A web page that generates seeds "locally". An app you cannot inspect. A process that happened while you were looking elsewhere. The seed might be fine. You cannot know, and "might be fine" is not a provenance.
Take 32 bits of entropy. The space is two to the power of 32, which is 4,294,967,296 possible seeds.
Suppose a laptop can derive an address from a candidate seed and check it against a list of funded addresses at a modest 100,000 candidates per second. That is 100,000 times 60 times 60 times 24, or 8.64 billion checks per day.
The entire space is exhausted in about half a day, on one machine, without any cleverness at all.
Now take the 128 bits a twelve-word seed is supposed to have. The space is two to the power of 128, about 3.4 times ten to the 38. At the same rate, that is roughly 3.9 times ten to the 28 days, which is about ten to the 26 years.
The difference between those two numbers is not a matter of degree. One is an afternoon and the other is longer than the universe has existed. And from the outside, looking only at the words, there is no way to tell which one you are holding.
What good provenance looks like
The device generating the seed should be one you can reason about: a dedicated signing device whose firmware you verified before setup, per F104-03, generating the seed on its own screen, while you watch, with nothing else connected.
Some devices go further and let you contribute randomness yourself, by rolling dice or pressing keys, and then show you how that input was combined with the device's own. The point of that feature is not that your dice are better than the device's generator. It is that you can now describe the process, which is what provenance means.
If you want to check a device's generation rather than trust it, the check is the one F103-02 described: take the seed the device produced, derive the first address on an independent offline tool, and confirm the two agree. That does not prove the randomness was good. It proves the device is deriving honestly from what it showed you, which closes one of the ways a malicious device could lie.
Adding a passphrase fixes a weak seed.
A passphrase, the so-called 25th word, is combined with the seed to produce the keys, and a strong passphrase does add real protection against someone who holds only the words.
It does not repair the seed's provenance. If the seed came from a space of four billion, an attacker who enumerates that space and then tries common passphrases is exactly where they were before, plus one dictionary. And if somebody else generated the seed, they can do the same thing you can.
The passphrase protects the seed from being enough on its own. It does not make a bad seed good. Regenerate.
The rule, applied to your tiers
F104-06 had you write a one-page specification of your setup with no secrets in it. Add one line to each tier's entry:
Provenance: which device generated this seed, on what date, with what firmware verified, and whether anyone else was present or could have been.
If you cannot write that line for a tier, that is the finding. The seed is not necessarily weak. It is a seed whose strength you cannot vouch for, holding funds you would mind losing, and the fix is the fifteen minutes it takes to generate a new one properly and move the funds across, which F104-05's recovery drill has already rehearsed.
The vault tier, the one holding the most, is the one where this line matters most and where it is most often missing, because vault seeds are the oldest and were often made before the owner knew what to look for.
Closing the loop
F103 told you a seed is the whole secret. F104-03 told you to check where the device came from. This lesson closes the gap between them: the seed has a provenance too, it is invisible in the words, and it is the property that Milk Sad victims were missing while their wallets looked exactly like everyone else's.
Two lessons remain in F104. The next asks what an air-gap actually guarantees once the seed is on the device, and the last asks how to verify a transaction you are about to sign when the screen that built it may be lying.
A seed phrase is a number, and its strength is a fact about the process that chose the number, not about the words. A valid checksum proves transcription, not randomness, which is why every Milk Sad seed imported cleanly from a space a laptop can count through in half a day. Provenance fails three ways: a bad generator, a seed somebody else made, and a seed you did not watch being made, and the words look the same in all three. Generate on a verified device while you watch, record where each tier's randomness came from, and if you cannot write that line for a seed, regenerate it before it holds anything you would mind losing.