Coldcard's $116M Hack: Why One Entropy Source Isn't Enough
Back to articles
TL;DR
- Starting July 30, 2026, attackers drained roughly 1,816 BTC from more than 5,200 Coldcard addresses, close to $116 million at prices at the time. Nobody broke into a device, and no attacker needed to touch one.
- A Coldcard seed came from one source of randomness by default, and a March 2021 firmware change pointed that source at ordinary software instead of the dedicated randomness hardware on the chip. With no second source mixed in to cover for it, the mistake went into every seed the device made.
- Effective key strength fell from a designed 128 bits to roughly 40 on Mk2 and Mk3 and roughly 72 on Mk4, Mk5 and Q, and lower again where an attacker could work out when the device was set up. At 32 bits an ordinary desktop can work through every possible seed.
- Nothing about an affected wallet looked wrong. The recovery words were valid, the addresses worked, and the balances were right. The flaw sat in shipping firmware for five years.
- The owners who lost nothing had added their own unpredictability with dice, or had a passphrase or a multisig quorum standing between the weak key and the funds. A wallet that leans on one source of its own has to get that source right every time.
Every hardware wallet has one job that everything else rests on, which is to come up with a number nobody can guess. That number is the private key. Your recovery words are a readable spelling of it, every address in your wallet is derived from it, and anyone who learns it can spend your coins from anywhere, without ever touching your device.
Everything else a hardware wallet does is about keeping that number safe once it exists. It signs transactions inside the device so the key never leaves, and it makes you approve each payment on the device itself. All of that assumes the number was impossible to guess to begin with.
Coldcard, one of the most trusted devices in bitcoin self-custody, shipped firmware for five years that built that number from a software formula instead of the dedicated randomness hardware on the chip, and nobody caught it.
Starting July 30, 2026, attackers drained roughly 1,816 BTC, close to $116 million at prices at the time, from more than 5,200 addresses, according to the Galaxy Research tally cited in TRM Labs' analysis. TechCrunch put the total at around $130 million by August 4, an estimate Elliptic's Tom Robinson called roughly correct, and found at least a dozen separate hackers working the same opening. No one was phished, and no device was stolen, opened, or tampered with.
What Entropy Actually Is
Entropy is the amount of genuine unpredictability that went into a number, measured in bits, and each additional bit doubles the number of possibilities an attacker has to work through.
Any wallet that produces a seed phrase is supposed to start with at least 128 bits of it, and usually 128 or 256 of it, software wallets included. Your key is safe because nobody can guess it, not because anyone is guarding it.
| Entropy | Possible values | What that means for an attacker |
|---|---|---|
| 256 bits | about 12 followed by 76 zeros | The strongest setting most devices offer, and the design target for a 24-word seed. |
| 128 bits | about 3.4 followed by 38 zeros | The design target for a 12-word seed. Unreachable by brute force. |
| 72 bits | about 4.7 sextillion | Expensive to search, but no longer in the category of physically impossible. |
| 40 bits | about 1.1 trillion | A single well-equipped machine can work through the whole range, generate the addresses for each candidate, and check them against the blockchain. |
| 32 bits | about 4.3 billion | An ordinary desktop can search all of it. |
How a Hardware Wallet Turns a Random Number Into a Wallet
Nearly every hardware wallet that gives you a recovery phrase follows the same process. The device generates a random number. That number gets mapped onto a word list under BIP39, which is where the 12 or 24 words come from, along with a short checksum so a mistyped phrase gets rejected. From that seed, BIP32 derives every account, address and private key the wallet will ever use.
That checksum only confirms the words are a validly encoded seed, and says nothing about how much unpredictability went into the number underneath.
Everything hangs off the first step. The word list is just an encoding and the derivation is deterministic math, neither of which adds unpredictability. If the number at the root is guessable, every key beneath it is guessable too.
Where that first number comes from, and how many separate places it comes from, decides everything downstream. A device drawing on one entropy source needs that source to be right every time it's used. A device drawing on several needs only one of them to be right, because they all get mixed into a single number, and an attacker has to predict every one of them to predict the key.
A Technical Look at the Coldcard Firmware Bug
Coinkite published a backgrounder that walks through the mechanics. The chain runs from one compile-time guard to every seed the device produced.
1. The call path changed. In March 2021 Coldcard migrated to a cryptographic library called libngu, and seed generation moved from ckcc.rng_bytes() to ngu.random.bytes(). Coinkite: “That path resolved rng_get() to MicroPython’s software fallback instead of COLDCARD’s hardware RNG implementation.”
2. The guard tested the wrong thing. The build used #ifndef MICROPY_HW_ENABLE_RNG, which checks whether that macro is defined at all rather than whether its value is switched on. Coinkite had defined it as 0, intending to replace MicroPython’s randomness with their own more conservative implementation. The guard saw a defined macro, raised no error, and the build went out.
3. A zero flag does not remove the function. Kevin Loaec, Wizardsardine: “MicroPython does not remove rng_get() when that flag is 0. It replaces it with a software imitation.”
4. The imitation was Yasmarang, a general-purpose pseudorandom generator built into MicroPython. It is seeded once at startup from the chip’s fixed serial number combined with a clock counter, the time of day, and a subsecond register. Block: “After initialization, no new entropy is collected. Every subsequent output is a deterministic state transition.”
5. The backstop on newer models was capped at 32 bits. From March 2022, Mk4, Mk5 and Q pulled 40 bytes from the two secure elements and hashed them to reseed the generator. Only the first four bytes of that digest reach the reseed function, which writes a single 32-bit word of generator state.
Every input to that startup seeding is something an attacker can work to narrow down, and the clock values matter most, because pinning them down amounts to working out when the device was set up. The two model groups landed in different places once attackers tried. Coinkite's advisory estimates roughly 72 bits on Mk4, Mk5 and Q, against roughly 40 on the older hardware.
The secure elements are the tamper-resistant chips that hold the card's secrets, and topping up the generator from them is what Coinkite called a reseed.
Block's analysis puts a harder bound on that top-up: because it writes only a single 32-bit slot, it can take at most about 4.3 billion values, a 32-bit ceiling, however much secure element output went into it. Block's loosest ceiling for the two together is about 73 bits, roughly 41 bits of startup timer state treated as independent fields plus the 32 bits the reseed can contribute, one that treats every timer field as independent, adding that "this is not 73-bit cryptographic security." Where an attacker can work out when the device was set up, Block puts the newer models at that 32-bit ceiling and the older ones at a single determined candidate.
The reseed also splits the newer models by date. It shipped in March 2022, a year into the bug, so every Mk4, Mk5 and Q seed has some secure element material behind it, while the Mk2 and Mk3 seeds have none and sits with the Mk2 and Mk3 seeds at that floor.
The gap between the two model groups shows both what a second source is worth and where it stops. The Mk2 and Mk3 had nothing behind their seeds but the broken generator. The newer models had a second source feeding that same generator, and it put them further out of reach even though it was never designed as a safety net.
What it couldn't do was carry the whole key, because all forty bytes were compressed into a four-byte slice of the digest before any of it reached the generator. That is the same shape of mistake as the build flag one level down, with the right material present and the code not using it.
Coinkite's advisory lists the affected version ranges for each model. Fixed firmware shipped on July 31, 2026, and updating protects seeds you generate from now on. It does nothing for a seed already created on the old code.
Why It Took Five Years to Notice
Coinkite's backgrounder explains how the review missed it.
“Both RNG implementations had the same function signature, and the intended board-specific TRNG code was present in the binary. Existing review verified that code but did not verify end-to-end symbol resolution and call reachability.”
The correct hardware RNG code was in the firmware, but nothing ever called it.
On the user's side of the device there was nothing to see at all. A weak seed produces valid words, a passing checksum, working addresses, and correct balances. It behaves identically to a strong one in every way a person can observe.
You also can't test a finished seed to find out. Any specific set of 24 words is exactly as likely as any other, so no statistical check on the output can tell you whether it could have been predicted. Randomness is a property of the process that produced a number, not of the number itself. Once the seed exists, the evidence of how it was made is gone.
That's what separates this from the risks self-custody guides usually cover. You can learn to spot a phishing site or a tampered device. No amount of care would have caught this one.
Coinkite says they assume "someone used AI to review previous versions of our firmware and stumbled upon this issue." Several security researchers pushed back on that framing, pointing out that a build flag disabling a hardware random number generator is an ordinary engineering mistake that conventional review should have caught years earlier. Block's Bitcoin engineering and security teams say they traced the vulnerability to its cause from user reports and a review of the public firmware repository, working alongside other researchers.
Why the Air Gap Didn't Help
Coldcard can be run so that it never touches a computer or the internet, taking unsigned transactions in on a microSD card and handing them back signed. The Defiant described that setup as the "gold standard" air-gapped wallet, and Nick Neuman, co-founder and CEO of the custody firm Casa, walked through how the bug defeated it anyway.
Nobody bypassed that air gap, and nobody had any reason to try. It stops a key from leaving the device, which covers malware on the host computer and anything sitting between the wallet and the network, none of which was involved here. The attackers worked out the narrow range the affected seeds fell into, brute-forced it with GPUs, and checked each candidate's addresses against the public blockchain.
Every step of that happened on the attacker's hardware, using data anyone can download. The isolation a hardware wallet gives you protects a secret from getting out. It has no bearing on whether that secret was beyond guessing when it was made. A key drawn from a narrow range stays findable by anyone willing to search that range.
How Some Coldcard Wallets Survived
Coinkite's security advisory explains why some owners lost nothing at all.
"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."
Coldcard has always offered an Add Dice Rolls option, where you physically roll a die and type in the results. On affected firmware, the device hashed its own generated seed together with every dice roll you entered. The device's contribution to that hash was close to worthless, but the rolls carried real unpredictability, and because the two were combined, that unpredictability survived into the finished seed.
Coinkite says the same holds for a strong, unique BIP39 passphrase, an extra secret the owner adds on top of the recovery words. It "adds an independent barrier," and knowing the weak seed alone doesn't get an attacker past it. They still tell those users to migrate to a fresh seed as soon as it's practical.
The mixing carries unpredictability through, but it cannot create it. As Block puts it, "deterministic hashing cannot increase the number of possible seeds."
Neuman put the objection bluntly: "You just can't ask people to roll dice to be secure with your self custody. It's a non-starter for 99% of people." The mixing worked exactly as it should have, and it only protected the small share of owners who knew the option existed, chose it, and carried it out correctly.
The Coldcards Held Inside a Multisig
The same principle carries one level up, from sources inside a device to keys inside a wallet. A multisig wallet needs signatures from several keys held on separate devices before anything moves, so one guessable key can't spend on its own.
Casa's Nick Neuman said customers holding a Coldcard as one key in a multisig quorum were not drained, and that . Owners who were never at risk still asked to have the Coldcard swapped out of their quorum rather than leave a key they now knew was weak inside it.
Multisig doesn't repair a weak key or make it any harder to guess. It takes away that key's authority to act alone, which is why the owners it protected were still told to replace it. The protection also depends on the keys being genuinely independent, and a quorum assembled entirely from affected Coldcards would have had the same bug behind every one of them. What it costs is more devices, more backups to keep straight, and a recovery process you have to rehearse before you need it.
Related: For a closer look at what happens when the exposure comes from a compromised vendor rather than a flawed key, read The Vercel Breach Hit Crypto Teams Hardest.
How Other Hardware Wallets Source Entropy
Coldcard, Ledger, Trezor and Burner each handle this differently, in where the randomness comes from and in how many places it comes from.
| Wallet | Where the randomness comes from | Sources combined | Published detail |
|---|---|---|---|
| Coldcard | Hardware TRNG on the device, with optional dice rolls entered by the owner | One by default, two if you add dice | Open firmware, published backgrounder |
| Ledger | A TRNG inside a certified secure element, with cryptographic post-processing in Ledger OS | One, monitored by hardware fault detectors | AIS-31 PTG.2, Common Criteria EAL5+ or EAL6+ |
| Trezor | The device's own RNG combined with entropy supplied by the host computer | Two, hashed together | Open firmware, host-side entropy check |
| Burner | On-chip TRNG, factory-generated randomness, and optional user input | Up to three, blended through a hash | Help-center documentation of the sources and how they combine |
Ledger and Trezor have both published how their devices handle this. Ledger's single generator sits inside a secure element with hardware detectors for malfunction and voltage glitches. Trezor mixes 32 bytes from the host computer into its own randomness, so either side failing still leaves the strength of the other.
Trezor's second source is the computer you plug the device into, which is the one piece of hardware a wallet is built not to trust. Malware on that machine could feed the device predictable bytes and know exactly what it sent. Trezor's answer is that the device mixes in randomness of its own, so knowing the computer's half is not enough to work out the key.
Kevin Loaec, who wrote Wizardsardine's analysis and whose firm builds the multi-key self-custody products Liana and Revault, adds a caveat: "To tolerate a design error, duplicating a component is not enough; it also has to be designed differently."
A second source only helps if it can break in a different way from the first. Two chips of the same design carry the same flaws, so if one of them produces a predictable number, the other one will too. That is why the dice worked on an affected Coldcard: whatever was wrong inside the chip had no bearing on a die landing on a table.
How Burner Generates Keys
Burner is a credit-card-sized hardware wallet that generates its private key on a secure chip and never produces a recovery phrase at all. There's no recovery phrase to write down or store, and backup works by duplicating the key to a second card rather than exporting it as text.
Three inputs feed key generation:
A true random number generator on the chip, producing cryptographically secure random numbers when the card is set up.
Factory-generated randomness, produced during manufacture and stored securely on the device.
Optional user-provided entropy, which you can supply during onboarding and which gets folded in with the rest.
The card blends those sources through a cryptographic hash function, so no single one determines the result. If one of them were compromised, the key would still take its unpredictability from the others. The same three inputs feed every key the card generates.
That's the same property that protected the Coldcard owners who rolled dice, with the difference that the mixing is part of the normal setup rather than an option you have to find. If you skip the optional user input, the key still draws on both the on-chip generator and the factory randomness.
The two are made at different times by different processes, one on the chip when you set the card up and one during manufacture, so a failure in one has no path into the other.
Final Thoughts
Coinkite wrote the hardware RNG code, shipped it in the binary, and set a compile-time flag to switch MicroPython's version off. But the build tested whether that flag was defined rather than whether it was on, and every seed the firmware generated for the next five years was weak.
Careful engineering makes a source fail less often, but it can't make failure impossible, which is why no single component should carry the whole key. Entropy is the one part of a wallet where a failure produces no symptom until the money is gone.
If you own a hardware wallet, ask your vendor, including us: How many independent sources go into your key? How are they combined? What happens if one of them is wrong? Any device that ties everything to a single source is asking you to trust that the source was implemented correctly, and that trust has now been tested in public.
Sources
Primary technical documents, for readers who want to check the mechanics directly. Reporting and product documentation are linked inline where they appear.
Coinkite, Seed generation security advisory
Block Bitcoin Engineering and Security, Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware
Kevin Loaec, Wizardsardine, Analysis of the Coldcard RNG vulnerability
Bitcoin Improvement Proposals, BIP39, mnemonic code for generating deterministic keys
FAQ: Hardware Wallet Entropy
❓ What is entropy in a crypto wallet?
Entropy is how much genuine unpredictability went into the random number your wallet was built from. It's measured in bits, and every bit doubles the number of values an attacker would have to try. A wallet designed for 128 bits is safe because searching that many possibilities isn't physically achievable. If the real entropy is much lower, the same wallet becomes searchable.
❓ How is a seed phrase actually created?
The device generates a random number, then BIP39 maps that number onto a standard word list and appends a checksum, which produces the 12 or 24 words. BIP32 then derives every account and address from that seed. The words are only an encoding of the original number, so the strength of the whole wallet is decided at the moment the number is generated.
❓ Can I check whether my existing seed phrase is weak?
No. Any given set of words is exactly as likely as any other, so no test on the finished phrase can reveal how predictable the process behind it was. The only way to know is to establish which firmware generated it. For Coldcard, check your model against the affected version ranges in Coinkite's advisory. Because no wallet lets you audit a finished key, the generation step is the only real lever. Burner blends up to three sources and produces no recovery phrase at all, so nothing is ever written out as words to store or lose.
❓ Does updating my Coldcard firmware fix an affected seed?
No. As Block puts it, "exposure depends on the firmware used when a secret was generated, not the device's manufacturing date." The July 31, 2026 firmware fixes how new seeds are generated and can't repair one that already exists. If your seed was created on affected firmware without added dice entropy or a strong passphrase, Coinkite's guidance is to update, generate a new seed, verify the backup and receive addresses, send a test transaction, and only then move the remaining funds.
❓ Was the Coldcard air-gapped, and why didn't that stop the hack?
Coldcard can be run fully air-gapped, signing transactions over a microSD card without ever connecting to a computer or the internet, and that isolation was never broken. An air gap is designed to stop a key from being extracted through a connection, which is a different attack from the one that happened. The attackers generated candidate seeds on their own machines and checked the resulting addresses against the public blockchain, so they never needed contact with a device. Isolation protects a secret; it can't improve one that was predictable when it was created.
❓ Would multisig have protected against the Coldcard bug?
In most setups, yes. Multisig requires signatures from several keys on separate devices, so a single guessable key can't move funds on its own. Casa's Nick Neuman said customers holding a Coldcard inside a multisig quorum were not drained. The exception is a quorum built entirely from affected Coldcards, where the same bug would sit behind every key. Multisig doesn't fix the weak key either; it only removes that key's ability to spend alone, which is why affected owners were still advised to replace it.
❓ Do Ledger and Trezor have the same problem?
Neither has been reported as affected by this bug, and their designs differ from each other. Ledger uses a single TRNG inside a certified secure element with hardware fault detection and post-processing in Ledger OS. Trezor combines its own device randomness with entropy from the host computer and hashes them together, and recent firmware lets the host verify the device committed to fresh entropy first. Trezor's approach uses two to four independent sources depending on model; Ledger's relies on one certified and monitored source.
❓ How many entropy sources should a hardware wallet use?
More than one, and they should be able to fail for different reasons. A single source has to be implemented correctly every time, with no backstop if it isn't, which is what the Coldcard bug demonstrated. Devices vary in how they do this. Ledger uses one certified generator with hardware fault detection, Trezor combines its device randomness with the host computer's, and Burner blends up to three sources on the card. The count matters less than whether the sources share a way of going wrong.
❓ Does a wallet without a seed phrase avoid this class of bug?
Not automatically. A wallet with no recovery phrase, like Burner, skips the BIP39 encoding step, but it still has to generate a private key from a random number, so entropy quality matters just as much. What reduces the exposure is how many independent sources feed that number. Burner blends up to three of them, so a single failing source doesn't determine the result on its own.
❓ How much bitcoin was taken in the Coldcard hack?
Roughly 1,816 BTC from more than 5,200 addresses, based on the Galaxy Research tally cited by TRM Labs. At prices when the funds were taken that came to close to $116 million, and TechCrunch reported the figure passing $130 million once a suspected fourth wave was included. The BTC amount is the figure that holds; the dollar value moves with the bitcoin price. The first wave alone moved 594 BTC out of around 500 addresses in 25 minutes on July 30, 2026.
Get your Burner
What to read next
Back to articles
Who Is Satoshi Nakamoto? The Suspects and the 2026 Hunt to Unmask Bitcoin's Creator
More than 17 years after Bitcoin's first block, no one has proven who Satoshi Nakamoto is. We go through the leading suspects, the competing answers from a 2026 documentary and the New York Times, and what Satoshi's untouched coins say about holding bitcoin yourself.
What is a Real-World Asset (RWA)? A Guide to RWAs on Base and How to Securely Store Them
A real-world asset is something that exists off the blockchain, like a US Treasury bond, a money market fund, a bar of gold, or a share of stock, represented on-chain as a token. The token isn’t a new asset with value of its own. It’s a claim on the real one, recorded on a blockchain so it can be moved, split, and held the way you’d hold any cryptocurrency.