
594 BTC in 25 Minutes: How One Line in a Firmware Build Emptied Hundreds of Cold Wallets
By EIDEX Team
The night of 31 July 2026 will be remembered as the moment a hardware wallet failed hundreds of owners simultaneously — the very device people buy precisely to guard against scenarios like this. In 25 minutes, roughly 500 addresses gave up 594.48 BTC, about $38 million at the time of the sweep. No device was broken into, no phishing email was opened, no backup was stolen. The attacker simply computed the private keys on their own hardware.
Timeline: How the Night Unfolded
The first public alarm came from Kevin Loaec, co-founder of Wizardsardine, the team behind the Liana wallet. At 17:35 UTC he asked his followers with a Coldcard to check their balances, adding that he hoped it would turn out to be nothing. Ninety minutes later the tone changed to a flat warning: this was not a drill.
Confirmations arrived fast. Community veteran grubles verified one case; Jameson Lopp reported partial drains — some wallets had lost only a portion of their outputs, not the full balance. The theory of a single careless user collapsed on the spot: the victims included well-known and highly experienced holders. By nightfall it was obvious the attacker had been working from a prepared target list.
Anatomy of the Sweep: 1,324 UTXOs Across Four Consecutive Blocks
This was not manual work. It was a pre-assembled pipeline. The attacker moved 1,324 UTXOs — unspent transaction outputs — from roughly 500 addresses inside a window of 01:31 to 01:56 UTC, spanning consecutive blocks 960188 through 960191.
Each transaction emptied exactly one victim address, the signature of a script walking down a ready-made list of keys. The loss distribution looked like this:
- median loss — 0.41 BTC, around $26,500;
- 110 addresses lost more than one coin;
- largest single-address loss — 29.9 BTC, close to $2 million;
- floor — 0.15 BTC; wallets holding less were never touched;
- 419 addresses held a single output, while some had accumulated 105 and even 200 UTXOs;
- fees cost the attacker roughly 0.044 BTC.
That 0.15 BTC floor points to target filtering by minimum balance — signing a transaction for dust is not worth the fee. By address type: 490 of the 500 were native segwit, plus five legacy and five nested segwit. Chainalysis added the detail that explains the operation's logic: the attacker worked top-down by balance size and pulled more than $30 million in the first ten minutes alone. In the end, 562 BTC were consolidated into a single address, with another 32 sitting on an intermediate one.
The First Theory: Blame the Users
The investigation started with a Reddit post. The author explained that he had bought a Coldcard in 2021, the device generated the 24-word seed phrase itself, funds were sent in, and the wallet sat untouched for years. In January of last year he bought a second Coldcard and re-entered the old phrase to confirm the words were recorded correctly. He had never shared the phrase with anyone and had only ever typed it into the device itself.
The manufacturer's first reaction was predictable. NVK, founder and CEO of Coinkite, wrote at 18:10 that there was no need to panic: someone had loaded a compromised phrase onto a Coldcard, or had leaked it. Analysts at Atlas21 floated a matching hypothesis — the problem was not the hardware but weak seed phrases that owners had imported themselves.
Pushback from the community was sharp. Defaulting to user error is a standard opening move for manufacturers, and it rarely earns trust. Within 24 hours the theory had failed outright, and with it the assumption that the victims had exposed their own phrases.
The Real Cause: A Macro Checked the Wrong Way
The technical breakdown came from the Bitcoin Engineering and Security team at Block. Coldcard's firmware contained two implementations of a random number generation function sharing the same signature: a hardware wrapper written at Coinkite around the built-in generator, and a software version inherited from MicroPython.
Coldcard's production configuration sets the MICROPY_HW_ENABLE_RNG macro to zero — precisely because the company uses its own hardware wrapper instead of the stock one. But the libngu library checked at build time whether the macro existed, not what it was set to. The macro existed, the check passed, and the build was bound to MicroPython's software generator: the Yasmarang algorithm, seeded from the chip's unique ID and timer register values, which collected no fresh entropy after initialization.
Put plainly, a device marketed as the gold standard of isolated key generation had been quietly bypassing its own hardware source of randomness for five years. The fault was introduced in firmware 4.0.0 in March 2021. The attacker was never guessing blindly — they reconstructed the generator's logic and were left with a compact search space.
One further detail: Coinkite believes the flaw in its open-source code was found by the attacker with the help of AI. The company's own AI audit of that same code, run weeks before the incident, turned up nothing.
What Entropy Is, and Why 40 Bits Is a Death Sentence
A 24-word BIP-39 seed phrase looks formidable, but its strength is determined by the number of genuinely random bits fed in, not by its length. The standard benchmark is 128 bits: a space that cannot be searched with any computing power available today.
That gap is what turned a build error into a ready-made tool — the attacker was handed a problem solvable with rented compute at a reasonable price. Coinkite estimates the effective search space on the Mk3 shrank to roughly 40 bits. Block's report declines to give a single figure, instead setting conditional ceilings below 2^40.7 and 2^73.3, with an explicit warning that the second value is not equivalent to 73-bit cryptographic security. Block published no brute-force benchmark.
40, 72 and 128 Bits: The Scale of the Difference
Think of entropy as the size of a combination lock:
- 40 bits — roughly a trillion combinations. An ordinary desktop clears that range in hours;
- 72 bits — out of reach for a hobbyist with a home rig, but within the means of a well-funded adversary running specialized hardware;
- 128 bits — the search would outlast the age of the universe, even at billions of attempts per second.
This is why 594 BTC left those wallets without any cryptography being broken. It was ordinary computation. The keys were not stolen; they were calculated. Bitcoin itself as a protocol was never compromised: every signature was valid and consensus behaved exactly as designed.
Which Devices and Firmware Versions Are Exposed
- Mk2 and Mk3, firmware 4.0.1 through 4.1.9 inclusive — the worst-hit group, at roughly 40 bits of effective entropy;
- Mk4 and Mk5 — seeds created before standard version 5.6.0 or Edge 6.6.0X;
- Q — seeds created before standard version 1.5.0Q or Edge 6.6.0QX;
- on the Mk4, Mk5 and Q, additional entropy came from the SE1 and SE2 secure elements, so the estimate is gentler at around 72 bits — still below any safe threshold;
- TAPSIGNER, OPENDIME and SATSCARD are built on a separate codebase and are unaffected.
Judging by the composition of the drained addresses, the attacker prioritized the Mk3 range, where brute force was cheapest. Fixes shipped on 31 July: Mk2/Mk3 at 4.2.0 and above, Mk4/Mk5 at 5.6.0 and above, Q at 1.5.0Q and above, and the Edge branches at 6.6.0X and 6.6.0QX.
The detail that matters more than the patch itself: updating the firmware does not repair a seed that already exists. Risk is determined by which version was running at the moment of generation, not by when the device was purchased or what is installed on it now. A weak key stays weak forever. Only the key itself can be replaced.
Who Survived: Dice, Passphrases and Multisig
Not every owner of an affected device is at risk, and this part matters.
Dice rolls. On the vulnerable firmware, Coldcard hashed the device-generated seed together with every roll entered through Add Dice Rolls. Between 50 and 98 fair, independent rolls contribute at least 128 bits of entropy on their own; 99 or more contribute roughly 256 bits. If the rolls were fair, independent and never recorded anywhere, Coinkite does not consider the resulting seed compromised. Fewer than 50 rolls, or "I don't remember," means following the migration guidance.
BIP-39 passphrase. An additional passphrase, stored nowhere on the device, moves the wallet outside the searchable space entirely.
Multisig. Not one of the 1,324 stolen outputs came from a multisig address — the attacker never got near those wallets. Every victim was single-signature. That is the most practical takeaway of the whole incident: multisig, ideally across devices from different manufacturers, protects not only against a stolen device but against a single vendor's mistake.
The Scale Keeps Growing: From 594 to 1,367 BTC
The initial estimate turned out to be the visible tip, and the attacker did not stop at the first wave.
- 31 July — Galaxy Research counted 1,082.65 BTC across 1,196 addresses, nearly double the original figure;
- 1 August — a second wave: 1,158.66 BTC, around $75.1 million, across 2,673 addresses;
- 2 August — a third wave pushed the running total to 1,367 BTC, roughly $89 million, across 4,585 addresses.
Galaxy adds a caveat: the analysis rests on on-chain data, so the firm cannot prove that every drained address was generated from a weak seed. But the timing, the scanning pattern and the consolidation behaviour leave little room for competing explanations.
Panic as a Business Model: The Second Wave of Scammers
The second blow to Coldcard owners came not from the blockchain but from the familiar playbook of crypto fraud. The moment the news spread, scammers launched a phishing wave: fake "seed checkers," clones of the Coinkite blog, "support staff" sliding into direct messages, bots offering to verify whether your phrase falls inside the vulnerable range.
The logic is old and reliably profitable: a genuine incident manufactures a legitimate-looking reason to type your seed phrase somewhere new. In crypto, panic converts into someone else's revenue better than any advertising budget.
No legitimate verification tool will ever ask for your seed phrase. Not one. Exposure can only be established from the firmware version on the device and whether dice rolls or a passphrase were used — and none of that needs to be sent to anyone.
How to Tell a Real Warning From a Scam
Most fraud around events like this is built on three levers: urgency, the manufacturer's authority, and an offer of help. The tells:
- any request for a seed phrase, private key or backup file, however it is worded — a guaranteed scam, without exception;
- a "firmware update" link that does not point at the manufacturer's domain;
- countdowns and pressure: "migrate within two hours or your funds are gone";
- offers to "insure" or "recover" stolen coins for an upfront fee;
- direct messages from "employees" on messaging platforms — official channels do not message first.
A category of its own is the recovery scam. Fraudsters find victims through public discussion threads and offer retrieval services against a deposit. No legitimate incident-response firm operates that way. The recovery con is not unique to crypto, but it thrives here for a simple reason: getting funds back through conventional means really is close to impossible.
Weak Entropy: Far From the First Case
This class of vulnerability is old and keeps returning:
- Randstorm — wallets generated in-browser on BitcoinJS between 2011 and 2015 relied on a predictable source of randomness;
- Milk Sad (CVE-2023-39910) — Libbitcoin Explorer derived seeds from a 32-bit Mersenne Twister seed, with losses running into the millions;
- the 2022 Trust Wallet browser extension flaw — the same nature: a library that supplied insufficient randomness.
The common denominator is not cryptography but build engineering and silent defaults. The algorithms work correctly; what breaks is the input they are handed. This category of failure resurfaces in crypto roughly every two years, and each time someone else reaches the result first.
What Coldcard Owners Should Do Right Now
- Determine which firmware the seed was created on — not the current version, but the one running at the moment of generation.
- Recall whether you used dice rolls and how many, and whether you set a BIP-39 passphrase.
- If the seed falls inside the vulnerable range, update the device to a fixed release.
- Generate a new seed on the updated device, then write down and verify the backup.
- Confirm the new receive address directly on the device screen and check the wallet fingerprint.
- Send a small test transaction, and only then move the main balance.
- If an Mk3 is your only available device, Coinkite recommends temporarily setting a strong, unique BIP-39 passphrase, verifying the fingerprint and address carefully.
- Consider moving to multisig across devices from different vendors.
While the blockchain is still being scanned for remaining vulnerable addresses, speed of migration matters more than elegance.
What the Market Should Take Away
The incident is uncomfortable precisely because it does not fit the usual frame. There was no rug pull, no fake token, no social engineering — none of what the word "scam" normally describes. There was one line in a build configuration, unnoticed for five years, and an attacker who read the open-source code more carefully than the manufacturer did.
Three practical conclusions follow. First, "cold" does not mean "safe": a hardware wallet removes one class of risk while adding trust in one specific vendor's firmware. Second, external entropy and passphrases turned out not to be paranoia but the only thing that saved a portion of owners. Third, multisig across devices from different manufacturers is the only setup that came through this incident fully intact.
The price barely reacted, holding near $64,000. To the market as a whole, $89 million is a rounding error. To 4,585 addresses, it is a total loss. That asymmetry is exactly why stories like this keep repeating: the cost of the error lands not on the industry, but on the individuals holding their own keys.
Which Coldcard models and firmware versions are affected?
Mk2 and Mk3 running firmware 4.0.1 through 4.1.9 are the worst hit, at roughly 40 bits of effective entropy. Mk4 and Mk5 are affected for seeds created before standard version 5.6.0 or Edge 6.6.0X, and Q for seeds created before 1.5.0Q or Edge 6.6.0QX — around 72 bits there. TAPSIGNER, OPENDIME and SATSCARD run a separate codebase and are unaffected.
Does updating the firmware fix a seed that already exists?
No. Risk is determined by the firmware version running at the moment the seed was generated, not by what is installed now. A weak key stays weak forever — you need to generate a new seed on a fixed release and move the funds to it.
Who was not affected?
Owners who added dice rolls through Add Dice Rolls (50 to 98 fair, independent rolls contribute at least 128 bits on their own), owners who set a BIP-39 passphrase, and every multisig wallet: not one of the 1,324 stolen outputs came from a multisig address.
Was Bitcoin itself hacked?
No. Every signature was valid and consensus behaved exactly as designed. The keys were not stolen, they were calculated: the effective search space had shrunk to roughly 40 bits instead of the standard 128.
How much was stolen in total?
The first wave took 594.48 BTC, about $38 million, from roughly 500 addresses in 25 minutes. By 2 August, Galaxy Research counted 1,367 BTC — roughly $89 million — across 4,585 addresses.
How do you tell a genuine warning from a scam?
No legitimate verification tool will ever ask for your seed phrase. The tells: any request for a seed, private key or backup file; a “firmware update” link that does not point at the manufacturer's domain; countdowns and pressure; offers to “insure” or “recover” stolen coins for an upfront fee; direct messages from “employees” on messaging platforms.
CTO of the EIDEX crypto exchange. Responsible for platform architecture, the trading engine and security; writes about the crypto market, regulation and blockchain technology.


