Main Takeaway: A seed phrase is only as strong as the true randomness present at the moment it was created, and a firmware update cannot put that randomness back afterwards. The 2026 Coldcard case showed why that matters, because a build error routed seed generation to a software formula instead of the physical noise source on the board, so phrases that looked ordinary were narrow enough to guess. This page explains how to find out where your own wallet's randomness comes from.
Quick reference
| Term | What it means |
|---|---|
| Entropy | The unpredictability collected at the instant a seed is created, counted in bits. A 12 word phrase targets 128 bits and a 24 word phrase targets 256 bits. |
| Seed phrase (BIP39) | The 12 to 24 words that encode that entropy. Every private key and address in the wallet is derived from those words. |
| PRNG (pseudo random number generator) | Software that produces random looking output by running a formula forward from a starting value. Recover the starting value and the entire sequence follows from it. |
| TRNG (true random number generator) | Hardware that samples physical noise such as circuit thermal noise or clock jitter. There is no starting value to recover and no sequence to replay. |
| Search space | The number of candidate seeds an attacker would have to test. A figure such as 40 bits or 72 bits describes the size of that space. |
| Secure element | A certified chip that holds keys and performs signing inside itself, kept separate from the device's main processor. |
What happened in the Coldcard case?
On July 30, 2026, Galaxy Research recorded an unusual pattern of Bitcoin transfers. Within 41 minutes, 1,196 addresses were emptied and roughly 1,083 BTC moved out. Every transaction carried the same fee rate of 30 satoshis per virtual byte, none produced a change output, and only default derivation paths were swept, meaning the standard address routes that a wallet uses unless the owner changes them. That level of consistency points at automated tooling working through a prepared list rather than at a series of separate compromises.
The sweep ran roughly 30 hours before the manufacturer published anything, so the people draining addresses had reached the defect first. Chainalysis later described the targeting as deliberate rather than random, with the largest balances taken first and more than 30 million US dollars collected inside the opening ten minutes.
The same day, the Canadian hardware wallet manufacturer Coinkite published a security advisory confirming a firmware level random number generation defect in Coldcard devices. In plain terms, the device was supposed to draw the randomness for a new seed from a dedicated noise generator on its own board, and instead drew it from a software formula whose starting value sat in a small, predictable range. That shrank the pool of possible seeds far enough that someone could generate candidates offline, derive the matching addresses, and check them against the public blockchain. No physical access to any device was involved at any point, and if you are working out whether a specific model and firmware combination falls inside the disclosed range, our seed entropy check page walks through it in order.
| Model | Affected firmware | Reported search space | Fixed release |
|---|---|---|---|
| Mk2 and Mk3 | 4.0.1 to 4.1.9 | Around 40 bits | 4.2.0 |
| Mk4 and Mk5 | Releases before the fix | Around 72 bits | 5.6.0 standard, 6.6.0X Edge |
| Q | Releases before the fix | Around 72 bits | 1.5.0Q standard, 6.6.0QX Edge |
| Tapsigner, Opendime, Satscard | Reported as not affected | Not applicable | Separate codebase |
What exactly went wrong in the code?
According to Coinkite's own technical write-up, the defect traces back to a code migration in March 2021, when elliptic curve operations were moved from an in-house implementation to Bitcoin Core's libsecp256k1 by way of the libngu library. During that migration, the call used for seed generation changed from ckcc.rng_bytes(), which reaches the hardware generator, to ngu.random.bytes().
The second call resolved to Yasmarang, a software pseudo random number generator built into MicroPython, instead of the STM32 hardware true random number generator on the board. Published analysis of the defect describes that software generator as starting from values such as the device identifier and timer state, both of which sit in a range an attacker can work through. The cause was a preprocessor guard written with #ifndef, which tests whether a macro is defined rather than what value it holds. The macro was defined with a value of 0, meaning off, so the guard treated it as present and the build failure that should have caught the mistake did not fire.
How much was taken, and how firm are the figures?
Two qualifications belong with any number quoted here. The 40 and 72 bit figures are search space estimates under particular assumptions, closer to a maximum enumeration count than to a measured entropy value, and the real figures are likely well below those upper bounds. Separately, the scope described in the official advisory does not line up exactly with the scope suggested by independent source analysis, so absence from an advisory is not on its own a clean bill of health.
The totals have moved every few days. As of August 4, 2026, Galaxy Research counted three main waves plus 14 smaller incidents, with high confidence on approximately 1,596 BTC drained from around 7,300 addresses. Counting a suspected further wave takes that figure toward 2,055 BTC, and later reporting in early August put the running total higher again. These are independent on-chain estimates rather than an official count, they were still being revised upward when this article was written, and any single total is best read as provisional. Roughly 90 percent of the taken coins had not moved from the receiving addresses at that point.
Coinkite disclosed the defect itself, shipped patched firmware across every model line within two days, destroyed units awaiting shipment that carried the affected firmware, and emailed customers with migration instructions. None of those steps reaches a phrase that already exists, which is why the remedy for an affected seed is a migration rather than an update.
Why can't a firmware update fix a seed that already exists?
A defect of this kind produces a compromised number rather than a compromised device. The chain runs from the generator, through the moment of generation, to your seed, and on to the private keys and addresses derived from it. Firmware is the generation step in the middle. Your seed is the output that step already produced, a fixed value that left the process at that instant and now exists on its own.
A firmware update reconnects the generator to the hardware source, so seeds created from that point forward are drawn correctly. The update has no way to reach backwards into a value produced years earlier. The weakness now sits inside the number itself, which is why the durable fix is a new seed rather than a patched device.
The same logic explains why a strong PIN, a sealed casing or a certified secure element does not close this particular gap. Those measures defend a device that someone has to reach. A guessable seed is attacked from the public blockchain, without anyone touching the hardware at all.
How can entropy fail without anyone noticing?
This defect ran for years without detection because functional testing and cryptographic security examine two different properties. A test suite looks at what the output looks like, while security depends on whether the output can be predicted, and the first measurement cannot see the second.
A statistical randomness check asks a specific set of questions, and a deterministic software generator answers every one of them acceptably:
- Balance of ones and zeroes. A PRNG produces an even split.
- Distribution of byte values. Also even across the range.
- Repetition. The output does not stick on a single repeating value.
- Difference between consecutive numbers. This was the specific health check Coldcard performed, and any functioning PRNG clears it without difficulty.
- The Diehard suite, a well known battery of statistical randomness tests. The author of Yasmarang has said the generator passes it.
Predictability leaves no trace in surface statistics, because a deterministic generator can produce output that is statistically clean and simultaneously reproducible by anyone who knows its internal state. Looking random is an external appearance, whereas being unpredictable is a cryptographic property, and tests aimed at the first do not reach the second.
One related point matters when reading vendor documentation. Mixing or hashing two deterministic streams together does not manufacture physical unpredictability. Combining sources improves the output distribution, and if every input is computable then the result stays computable. Entropy has to enter from a physical process somewhere, and a diagram showing several arrows converging is not evidence that it did.
Which situation is yours?
Exposure to a defect like this depends on the conditions the phrase was born under, not on when the hardware was bought. The rows below cover the cases people actually write in about.
| Your situation | What it means |
|---|---|
| The seed was generated on an affected model, on firmware inside the disclosed range | Treat the phrase as compromised and move to a new seed. The balance is reachable by anyone running the same candidate search. |
| The seed was generated somewhere else and imported onto the device | An imported phrase belongs to whatever produced it originally, so this particular defect does not reach it. The question moves to the tool that generated it. |
| Extra dice rolls were added during generation on the affected device | The advisory treats that case separately, because those rolls contributed randomness the software path did not control. Check the count you used against the manufacturer's advisory rather than assuming. |
| A strong BIP39 passphrase is in use on top of the seed | The passphrase raises the cost of attacking a weak seed considerably without repairing the seed underneath. Read it as time bought for a migration. |
| The affected key is one of several in a multisig arrangement | An attacker holding one weak key still needs the others, so immediate exposure is lower. The weak key still belongs on the replacement list. |
| The firmware version at the moment of creation cannot be recalled | Treat that uncertainty as the finding. A phrase carries no record of the conditions it was created under, so there is nothing to inspect after the fact. |
| Coins are already leaving the address | A migration will not help at that point, because the situation has become a fee race rather than a planned move. |
Six questions to ask about any wallet's entropy
These apply to any manufacturer, including the one you currently trust and including us. Each is answerable in a sentence by a vendor who has done the work.
- Which physical component produces the randomness, and can they name the part? An entropy source is a specific piece of silicon with a datasheet. A vendor that describes its source only as "hardware based" has given you a category rather than a fact, and a category cannot be looked up.
- Does that output actually reach seed generation? This is the precise gap the 2026 case fell through. A correct hardware source is worth nothing if the function called during setup resolves somewhere else, so the answer should name the call path rather than the component.
- If the secure path is unavailable, does the build fail or fall back quietly? Systems that degrade silently accumulate faults nobody observes. A vendor who can point to a compile time or run time check that halts rather than substitutes has designed for the failure that actually occurred here.
- Is the source readable, and does it correspond to shipped firmware? Published source and reproducible builds are separate claims, where the first lets someone read the intention and only the second connects that reading to the binary on the device in your hand.
- Has an independent party traced the call chain, rather than reviewing the algorithm? Most audits assess cryptographic design. The 2021 defect was not a design error, since the design specified the hardware generator correctly, and the mistake sat one layer below in integration, which is the region audits routinely skip.
- Can you supply your own entropy and import the resulting seed? A vendor that supports this is offering something better than an assurance, because it lets you remove their generator from your setup. A vendor that requires on-device generation is asking you to accept the previous five answers permanently.
Silence on any of these is informative in itself. A manufacturer that has traced its own entropy path can describe it briefly and without hedging, while one that responds with adjectives about security has probably not looked recently.
What should you do if you need a new seed?
This sequence is brand neutral and applies to any migration away from a suspect seed. Work through it unhurried, since a rushed migration can cost more than the defect did.
- Generate the new seed on a device that is not carrying the defect you are leaving. Staying with the same manufacturer means installing the fixed firmware and confirming the version on the device screen first. Moving to another means checking that manufacturer's entropy implementation independently. Generating a replacement on the unpatched device repeats the problem.
- If the old seed is already suspect, consider moving the funds before touching the update. Independent reports in early August described devices failing during the firmware update, so carrying out the migration with a separate device you already trust removes any dependency on that step.
- Back up the new phrase physically. No photographs, no screenshots, no notes application and no digital copy of any kind. Our guide on how many backup copies to keep covers the tradeoffs.
- Verify the backup by restoring from it. Wipe the device and restore, or restore onto a second device, because a backup that has not been tested is only an assumption that it works.
- Confirm a receive address on the screen of the device that holds the keys. Check it on that hardware rather than in a companion application or on a computer display, since the device screen is the one surface an attacker cannot repaint remotely.
- Send a small test transaction. Move a minimal amount to the verified address, wait for confirmation, and check that the balance appears.
- Move the remaining balance and retire the old wallet. Stop using any address derived from the old seed and redirect recurring payments. Keep the old backup until every transfer has confirmed, then treat that seed as decommissioned.
One warning belongs on the edge of that list. Forgetting a BIP39 passphrase means the funds behind it cannot be recovered by anyone, including us, so a passphrase you add during migration needs a storage plan of its own before you rely on it.
Can you take the manufacturer's generator out of the question?
On this subject ELLIPAL would rather offer a product fact than an assurance. Our generator does not have to be part of your setup at all. Every ELLIPAL product accepts a 12 to 24 word BIP39 phrase produced somewhere else, whether that came from dice, from an open source signing device, or from a wallet you already hold, and every ELLIPAL product supports a BIP39 passphrase you choose yourself.
On Titan 2.0 the words are entered directly on the device screen, so the phrase goes into the hardware that will hold it rather than through a connected computer. On the ELLIPAL X Card, an NFC cold wallet in credit card form, import runs on the offline X Card Starter that ships with it, which keeps the phrase out of any phone application. Both product lines use Common Criteria certified secure elements, and both derive keys under BIP39 and BIP44, so a phrase you generated yourself restores on any BIP39 wallet from any brand if you later decide to leave.
Frequently asked questions
How do I know whether my own hardware wallet is affected?
Check three things: the model, the exact firmware version running when the seed was created, and whether the seed was generated on that device or imported from elsewhere. An imported seed belongs to whatever produced it originally. If you cannot recall the firmware version or the origin with confidence, treat that uncertainty as the finding, because a phrase carries no record of the conditions it was born under.
Can I test a seed phrase to see whether it is random enough?
No test on the words themselves will tell you. Validators confirm that each word appears on the BIP39 list and that the checksum computes, which any correctly formed phrase satisfies regardless of the entropy behind it. Twelve or twenty-four words is also far too little data for statistical analysis to say anything meaningful. The evidence lives in the generation record rather than in the output.
Does importing a seed phrase I generated myself weaken it?
No. BIP39 derivation is deterministic, so a device given your words derives exactly the keys those words describe, identical to what any other BIP39 wallet would derive from the same input. The strength was settled when the entropy was collected. What matters at import time is that the words are entered on an offline device rather than typed into anything with a network connection.
Is a passphrase enough to protect a seed that was weakly generated?
A BIP39 passphrase adds a secret that came from you rather than from the device, so it sits outside whatever the manufacturer's generator did. Against an attacker enumerating weak seeds, that raises the cost substantially. It leaves the underlying seed weak, which is why it works better as protection while you migrate than as a permanent answer. Forgetting it means the funds behind it are unreachable.
Does moving to a new seed cost anything?
The migration itself costs network fees on whichever chains you move, and those fees depend on conditions at the time rather than on the wallet you use. ELLIPAL charges nothing for generating or importing a phrase, and a phrase you produced yourself can be imported into a device you already own, so replacement hardware is a choice rather than a requirement. Budget for the fees on every chain you hold, since a partial migration leaves balances behind on the old seed.
Can I keep using the device after updating the firmware?
The update restores the generator for seeds created after it, so the hardware becomes usable again for a fresh seed. The phrase created under the defect stays weak whatever version the device now runs, which is why a new seed is the fix rather than the update on its own. Given the reports of devices failing mid update, moving funds with a device you already trust is the lower risk order when the old seed is suspect.
Is a hardware wallet still worth using after a case like this?
The failure here sat in one integration path inside one firmware line, and it did not come from the idea of keeping private keys off an internet connected machine. What the case does change is which questions are worth asking before trusting a device, since entropy provenance turned out to matter as much as the signing architecture people usually compare. A wallet that lets you supply your own phrase gives you a way to act on those questions rather than accept an answer.
What happens if I lose a seed phrase I generated myself?
The same outcome as losing any self-custody seed, which is that the funds become unreachable. Generating your own entropy comes with no recovery service and no reset path, and that is true of every self-custody wallet whoever produced the words. Keep at least one durable physical backup, store it apart from the device, and if you use a passphrase, store that separately again.
About ELLIPAL
ELLIPAL has been on the market since 2018, with more than 1 million users in 140+ countries. ELLIPAL products are BIP39 and BIP44 compatible, support 10,000+ tokens across 45+ blockchains, and use Common Criteria certified secure elements. ELLIPAL hardware has been reviewed independently by outlets including Coin Bureau, 99Bitcoins and CryptoNews.
Read next
For the fundamentals underneath all of this, our seed phrase guide covers what those words are and how derivation works. On keeping a backup alive for decades, see whether a bank vault is the right place for a seed phrase. If a phrase is rejected during import, the common causes are mechanical and easy to correct, and the ELLIPAL Help Center lists them by symptom.
Own it. Then use it.
Security note: No self-custody setup removes every risk. Generating your own entropy and importing it closes one specific category of dependency, and it does not address physical, supply-chain, firmware, social-engineering or user-error risks. Buy from an official source, store your recovery phrase on a durable offline backup kept separately from the device, do not share it or enter it on any connected device, and verify every transaction on the device screen. Incident figures cited here reflect public reporting as of August 6, 2026, they were still being revised as this was written, and you should check the manufacturer's official advisory before acting on version details. Third-party tools referenced are independent projects that ELLIPAL does not operate or endorse. This article is general educational information about wallet architecture. It is not financial, investment or custodial advice.