Verified Platforms
Quick Links
Where to Stay Secure
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Between 01:31 and 01:56 UTC on 30 July 2026, 594.48 BTC left roughly 500 bitcoin addresses, and nobody had to touch a single device to take it. There was no malware, no phishing page, no seed phrase photographed off a kitchen table. The addresses were single-signature, many dormant for years, each holding more than 0.15 BTC, and 1,324 outputs moved across about 500 transactions inside a three-block window.
A sweep shaped like that is not a break-in but arithmetic that finished running.
The question at the center of it is what a BIP-39 passphrase actually does. You own a Coldcard, and the advisory has been open on your phone since breakfast. You have not moved the coins in three years, and you are working out whether the words in your safe still belong only to you. Lilith reads the evidence with you. Twenty years in cybersecurity trained her to ask one question of any security claim, which is what a person supplied and what a machine promised. She starts with the clock rather than the wallet.
Twenty-five minutes is a strange amount of time in which to rob 500 people. A phishing campaign that collects 500 seed phrases collects them over weeks, one careless moment at a time. The money leaves in a ragged line, each person caught on a different day. This did not look like that. Every output moved inside three consecutive blocks, which means the keys were already gathered, already derived, and already sorted before the first transaction was broadcast.
"Nobody was hunting during those twenty-five minutes," Lilith says. "The hunting was finished. What you are watching is the withdrawal."
Uniformity is the second signature. Every drained address was single-signature and every one held more than 0.15 BTC, a floor that reads like a filter rather than a coincidence. Someone working from a list of candidate keys does not chase dust. They derive the addresses each candidate implies, check the public ledger for which ones hold enough to be worth a transaction fee, and sweep the ones that clear the bar. Afterwards, 562 BTC was consolidated into a single address that has not moved since.
What has not been established is that the sweep and the flaw are the same event. Coinkite's advisory does not mention the theft at all. The researchers looking at both have been careful to say the connection is not demonstrated but inferred, read off the shape of the on-chain data. CoinDesk reported that Block published its findings without finishing exploitability testing, because exploitation already appeared to be under way. Adjacent and consistent is as far as the evidence currently goes, and the mechanism underneath does not need it to go any further.
A seed phrase is a number wearing words. Twelve or twenty-four words encode one random value. Everything downstream comes out of that value by rules that are public and identical in every wallet in the world: every private key, every address, every signature. The secret is not the words but the randomness underneath them.
That puts the whole of a hardware wallet's security on one moment that lasts a fraction of a second, produces nothing you can see, and decides everything that follows.
"You can verify an address on the screen," Lilith says. "You can check a signature. There is no screen anywhere that shows you how random your randomness was."
On 30 July, Block's bitcoin engineering and security team published Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware. That is where the mechanical detail lives. Coinkite's advisory tells owners what to do and offers no root cause. Block's write-up gives one, and it is smaller than anyone would like.
The device was meant to draw randomness from the STM32 chip's hardware generator. Its production board configuration switched MicroPython's own generator off by setting a flag to zero. Sitting between the two, the library checked whether that flag was defined rather than whether it was enabled, and a flag set to zero is still defined. The check passed, the library bound itself to the software generator, and the hardware source quietly stopped being used.
What replaced it was a deterministic software routine seeded from the low 32 bits of the chip's unique ID, a SysTick counter, and the real-time clock registers. None of those are secrets. Block notes that the chip ID is fixed device metadata, readable from memory, and partly transformed into the Coldcard's own USB serial number. The library did mix in a second software generator seeded with public constants. XOR does not create entropy, and if both inputs are reproducible then so is the result.
A random number library sits below the level anyone thinks to audit. So did the tooling in Protect Your Crypto Wallet From Malware in Your Tools.
A stolen seed is a personal event. Someone reached your house, your photo library, or your attention, and the damage stops at the edge of what they reached. You can usually reconstruct how it happened, and you can usually tell that it happened at all.
A weak seed is a category. The attacker never learns your name, never sees your device, and never sends you anything. They reproduce the conditions the device was in when it made the number. Then they enumerate the values it could have produced, derive the addresses each one implies, and read the public blockchain to see which of those addresses hold money.
Your wallet does not participate in this at all.
Nothing touches your network. Nothing touches your backup. The PIN never comes up, because the PIN protects a device the attacker has no reason to visit. Air-gapping works perfectly. It is not wrong but irrelevant, because at no moment did anything need to cross the gap.
Coinkite quantifies the damage for one device family only. For the Mk4, Mk5 and Q, the advisory states that affected seeds carry "about 72 bits of entropy rather than the expected 128 bits." It publishes no equivalent figure for the Mk3. Block's analysis goes further on the older hardware. On affected Mk2 and Mk3 devices it puts a broad upper bound near 2^40.7 candidate values when the timer values are unknown. Once the chip ID and timers are known, it describes the search as fully determined.
The distance between those numbers is the whole story. At 128 bits, nobody enumerates anything, which is the entire premise you bought the device on. At 72 bits, the margin stops being a guarantee and turns into an estimate of how much effort would be required. Near 2^40, effort stops being an interesting question.
None of it is observable from your side. There is no alert, no failed login, no strange transaction to catch. dApp Frontend Attack: How the Polymarket Drain Happened covers the same discomfort from another direction, where every component behaved as built and the loss happened regardless.
The vocabulary has been doing quiet damage here. A BIP-39 passphrase gets called the 25th word, and it gets filed in people's heads next to the PIN, as though both were passwords guarding the same door. They are not the same kind of object, and this event is what makes the difference expensive.
The PIN is enforced by the device. It decides whether the Coldcard in your hand will talk to you. Take the seed words out of that device, type them into any other wallet, and the PIN is simply gone. It was never part of the key but a property of the box.
A BIP-39 passphrase is not enforced by anything, because it is an input. The seed words and the passphrase enter the derivation function together, and what comes out the other side is a different master key, which means a different wallet with different addresses. Change one character and you get an unrelated wallet with no error message, because nothing was checked against anything. There is nothing to check.
"That is the entire distinction," Lilith says. "The PIN protects the device. The passphrase becomes part of the key. Only one of those still means anything once the device stops mattering."
Which raises the question worth asking about your own setup. Of everything you did to secure those coins, how much of it changed the key, and how much of it only guarded the container?
| Layer | Enters seed derivation? | Helps if your seed is stolen? | Helps if your seed is weak? |
|---|---|---|---|
| Device PIN | No | No | No |
| Air gap / cold storage | No | Yes | No |
| BIP-39 passphrase | Yes | Yes | Yes |
| Dice entropy (50+ rolls) | Yes, at creation | No | Yes |
| Multisig | No, a separate key | Partly | Yes |
A PIN and an air gap sit at the very center of what people picture when they picture cold storage, and neither one does anything at all for a key that was born guessable. They defend the container, and nothing about them reaches back to the moment the number was made. It is a familiar shape. Revoke Token Approvals: The Open Door You Forgot to Close teaches it from the opposite direction, where a permission you had stopped thinking about was still perfectly live.
Three groups came through this intact, and they are not three separate pieces of luck.
Passphrase users were not swept because the addresses derived from their seeds are not the addresses an attacker gets by enumerating the generator's output. The words alone produce one wallet. The words plus a passphrase produce another, and only the words were ever in reach.
That is not the same as safe, and Coinkite is explicit about it. The advisory's instruction is to "migrate to a newly generated seed as soon as practical" even with a strong passphrase. Bitcoin developer James O'Beirne put the reason plainly on X: if your device is affected and you have a passphrase, your coins are now only as safe as that passphrase. The seed underneath has become public arithmetic, and everything rests on the one component you chose yourself, which was never designed to carry the whole load alone.
Dice rolls work at the other end of the timeline. A Coldcard can hash physical dice rolls into the seed as it is being created. Coinkite's position is precise: "if you entered at least 50 fair and independent rolls, and the rolls were not recorded or exposed, we do not consider the resulting seed at risk from this RNG issue alone." Keep the hedge attached. From this issue alone is doing real work in that sentence.
Multisig survives for a third reason. It does not improve the bad key but makes it insufficient, because spending requires signatures from keys generated somewhere else, on other hardware, at other times. Multisig appears nowhere in the advisory. It comes from O'Beirne, who named all three defenses together for single-key holdings created on an Mk3 between 2021 and 2023. Anyone holding none of the three, he said, should move funds immediately.
Set the three beside each other and they stop looking like a list. A passphrase is randomness you supplied. Dice are randomness you supplied. A second key is randomness a different device supplied, at a time and in a place the broken one never touched. Every defense that held put something into the key that the failing generator did not produce.
There is one defense here, not three.
Establish whether you are in scope, and do it from the advisory rather than from memory of a headline. Coinkite's seed generation warning lists four devices. The Mk3 is affected on firmware 4.0.1, released March 2021, through 4.1.9, and is fixed in 4.2.0 or later. The Mk4 and Mk5 are affected on anything before 5.6.0, and the Q on anything before 1.5.0Q. Tapsigner, Opendime and Satscard are not affected, which Coinkite attributes to their running different codebases.
An early line said preliminary analysis suggested the newer models were clear. The advisory as it now stands does not say that. If you own an Mk4, an Mk5 or a Q, check the firmware version rather than the model name. What puts you outside this is not the device you bought but the number it is running.
Installing the fixed firmware repairs the generator, and it does nothing whatsoever to a seed the old generator already made. A key that was weak when it was created stays exactly as weak afterwards, because the number was written down years ago and the addresses it implies already sit on a public ledger.
Updating is not migrating.
That is why Coinkite publishes a migration sequence rather than an update notice. It runs in a deliberate order:
Steps three and seven are the ones that go missing under pressure, and both exist to stop you losing coins during the move rather than after it. Verifying a backup before funding it is what prevents a panicked migration from sending everything into a wallet you cannot restore. Keeping the old backup until the full balance has arrived and confirmed is what prevents you destroying the only copy of a key that still has money behind it.
If you have a passphrase, the instruction is still to migrate. Lower risk is not no risk. A string you chose is now the only thing standing between your coins and a seed somebody else can derive.
Cold storage answers a single question extremely well. Can anyone get this key off this device? Measured against that question, the hardware performed. The secure element held, the air gap held, the PIN held, and nothing was extracted from any of the roughly 500 devices involved. The tamper resistance those owners paid for was never even tested.
The question it does not answer, and was never built to answer, is whether the key was unguessable when it was made. That happened once, in a fraction of a second, years before any of this, and it left behind no evidence you can inspect. You cannot look at a seed phrase and see how much randomness stands behind it. Twelve words from a hardware generator and twelve words from a broken counter look identical on the card in your safe.
There is a difference between a system that holds something and a system that made it. Are Crypto Developers Money Transmitters? Code vs Custody argues that distinction in law. A hardware wallet lives on both sides of it and only ever shows you one.
Lilith's version of the habit is a question rather than a checklist. Take whatever is protecting your coins right now and sort it into two piles: the parts a vendor supplied for you, and the parts you supplied yourself. The first pile is a promise you are trusting. The second is the only part still standing if the promise turns out to be wrong.
On 30 July, for about 500 people, the promise turned out to be wrong.
Open the Kodex simulator and take any position. Before you size it, write down which parts of that trade you chose and which parts arrived as somebody's default: the entry, the stop distance, the position size. The list of things you chose is usually shorter than it feels, and finding that out on a simulated balance costs nothing but the ten seconds it takes to look.
