Main Takeaway: The Coldcard vulnerability disclosed on July 30, 2026 was a firmware build error, not a cryptographic break. For five years, affected devices generated seed phrases from a software pseudo-random generator instead of the hardware one, which made those phrases computable. ELLIPAL Titan 2.0 generates seeds through a single hardware TRNG path with no software fallback, and every ELLIPAL device also accepts a seed you generate yourself, so your security does not have to rest on any vendor's word. This article explains the incident and what you can verify on your own.
Quick reference
| Term | What it means |
|---|---|
| TRNG | True random number generator. A hardware circuit that produces randomness from physical noise, which cannot be replayed or predicted. |
| PRNG | Pseudo-random number generator. Software that produces random-looking output from an internal state. Anyone who learns the state can reproduce the output. |
| Entropy | The amount of genuine unpredictability in a key, measured in bits. Seed phrases are designed for 128 to 256 bits. |
| BIP39 | The recovery phrase standard, usually 12 or 24 words. A phrase carries its own entropy, so it can be generated by one tool and used in another. |
| Passphrase | An optional extra secret under BIP39 that changes the entire key derivation, creating a separate hidden wallet on top of the same phrase. |
| Fail closed | A design where a missing security component stops the operation entirely, rather than continuing with a weaker substitute. |
What happened in the Coldcard incident?
On July 30, 2026, Coinkite published a security advisory about its Coldcard hardware wallets. Since March 2021, a build misconfiguration had caused seed generation to draw from a software pseudo-random generator instead of the hardware true random number generator. The flaw sat in shipped firmware for five years without detection.
Community on-chain trackers counted roughly 594 BTC, worth about $38 million, drained from close to 500 wallets in under 30 minutes around the disclosure. Those figures come from independent tracking rather than an official tally. Coinkite confirmed the root cause in a technical deep dive the following day, and Block's engineering team published an independent analysis that matches it. The disclosure itself was detailed and candid, which deserves credit. People who did everything right by the book still lost funds, and that is the reason this incident is worth understanding rather than just scrolling past.
How did the bug actually work?
Three small things lined up, and each one alone would have been harmless.
First, a migration. In 2021 the key generation code moved to a new cryptographic library, and the function that fetches randomness ended up with a generic name. Which implementation actually provided that function was left for the build system to resolve.
Second, a guard that could not fail loudly. The build flag for the hardware RNG was set to zero, meaning disabled. The safety check only tested whether the flag existed, not what value it held. Defined as zero still counts as defined, so the protection did not trigger.
Third, a silent link. The MicroPython runtime inside the firmware ships its own software PRNG, and it happens to export a function with the same name. The linker picked it. The firmware compiled cleanly, booted normally and produced seeds that looked perfectly random while drawing from a generator an attacker can reconstruct.
A plain-language version: the vault combination was supposed to come from a hardware dice roller. After a renovation, the system quietly started using a predictable counting rhyme instead, and the alarm that should have caught the swap had a bug of its own. For five years, every combination was guessable by anyone who knew the rhyme.
Who was affected, and what fixes it?
Per the Coinkite advisory, Mk3 devices on firmware 4.0.1 through 5.0.3 were hit hardest, with an effective search space of roughly 40 bits against a 128-bit design target. Block's analysis found that later models reseeded the same software generator with only 4 bytes of hardware entropy, leaving an effective space it estimates at roughly 72 bits. The vendor's guidance is the important part: a firmware update cannot repair a seed that already exists. Remediation means generating a fresh seed on fixed firmware, or from an independent source, and migrating funds to it.
Two groups of users came through materially better. Those who had folded 50 or more dice rolls into seed generation, and those protected by a strong BIP39 passphrase. Both protections share one property, and it is the lesson of the whole event: they did not depend on the vendor being right.
Every vendor is now saying the same sentence
Within 48 hours, most major hardware wallet makers published statements. They are broadly honest statements, and they are also all the same sentence: our architecture is different, our code is not affected.
We are going to say that sentence too, and we want to be upfront about its limits. Coldcard said a version of it for five years, in good faith, while the bug sat underneath. A vendor assurance, ours included, is a claim about current code, not a law of nature. That is why the second half of this article is not about our assurance. It is about your options.
How does ELLIPAL generate randomness?
For the record, the assurance, stated precisely. On the ELLIPAL Titan 2.0, seed generation has exactly one source of randomness: the hardware TRNG inside the device's CC EAL5+ certified secure chip. The firmware contains no software pseudo-random fallback for key generation. The three conditions that produced the Coldcard failure do not have an equivalent here:
- No competing implementation. There is one RNG path, so there is no second function with the same name for a linker to pick by mistake.
- No enable flag to get wrong. A single path needs no build option to select it.
- No fallback. If the hardware TRNG does not respond, key generation does not proceed with something weaker. It fails closed: no randomness, no key.
The Titan line is also air-gapped, with no USB data connection, no Bluetooth and no WiFi, so even a theoretical flaw in any component is not reachable over a network. Transaction data crosses as QR codes you can read.
That is our sentence. Here is why you do not have to rely on it.
What can you verify without trusting a vendor?
Self-custody removed the exchange from your security model. The next honest step is letting you remove the vendor's word from it too. We call the principle trustless trust: the wallet should hold your keys without asking you to believe anything you cannot check or replace. Every ELLIPAL device supports that today, in three independent ways.
Generate your seed somewhere you can audit. ELLIPAL Joy is a dedicated offline seed phrase generator with one job: produce a BIP39 phrase of 12 to 24 words from a hardware entropy source, with no storage, no radio and no network connection. Its full source code is public on GitHub for anyone to read, build and compare against the shipped firmware. If you would rather not trust the generator inside any wallet, including ours, create the phrase on Joy and import it.
Or generate it with any tool you already trust. Every ELLIPAL wallet accepts an imported 12 to 24 word BIP39 phrase. Physical dice with a lookup table. SeedSigner. A device you verified yourself. The import does not weaken anything, because a BIP39 phrase carries its own entropy with it. The wallet stores and signs, and the randomness question was settled by the tool you chose. On the Titan, the phrase is entered on the offline device itself. On the X Card, import happens through the offline Starter device, so the phrase does not pass through the App.
Add a passphrase if you are an experienced user. All ELLIPAL devices support the BIP39 passphrase standard. A passphrase changes the entire key derivation, so a leaked or weakly generated phrase alone does not open the wallet that matters. In the Coldcard incident, users with a strong passphrase had a much better outcome. Two honest caveats belong next to that. A passphrase does not add entropy back into a weak phrase, which is why Coinkite still recommends migration for affected devices. And a forgotten passphrase means permanent loss that nobody can undo, including us. Treat it as an independent second lock, not a repair kit.
Where does the rest of the industry stand?
For fairness and for the record, condensed from each vendor's own published response.
| Brand | Stated randomness approach | Accepts an externally generated seed |
|---|---|---|
| Coldcard | Hardware RNG, restored by fixed firmware after the build flaw | Yes, dice rolls supported |
| Ledger | Certified TRNG inside the Secure Element | No external seed import |
| Trezor | Multiple entropy sources mixed, including the host computer | No external seed import |
| OneKey | Secure element TRNG, with a source-level analysis published | Yes |
| Keystone | Dual secure elements generating and mixing independently | Yes, dice rolls supported |
| ELLIPAL | Single-path hardware TRNG in the secure chip, no software fallback | Yes, any BIP39 tool, plus the open-source Joy generator |
The honest summary of that table: architectures differ, every vendor's current code is presumably fine, and on most devices users still cannot act on any of it except by belief. Dice input, where it exists, is the notable exception and genuinely worth using. An imported seed from an auditable generator is the same idea with less friction.
What should you do now?
- If you own an affected Coldcard: follow Coinkite's advisory. Generate a fresh seed on fixed firmware or an independent source, migrate carefully, and test a small restore before moving the rest. Do not type your old or new phrase into anything with a network connection.
- If you own an ELLIPAL: no action is required. If this week changed how much vendor trust you are comfortable with, the import path exists. A phrase from Joy or dice, imported on the device, works exactly like a native one.
- If you own any hardware wallet: find out two things. Where its randomness comes from, and whether it accepts an externally generated seed. The first answer requires trusting documentation. The second you can test yourself in ten minutes.
- If you are choosing a wallet now: add one question to your checklist. Not whether the RNG is sound, since every vendor answers that identically. Ask what you can verify without believing them. The length of that answer is the real security page.
- If you hold long-term and rarely touch the device: this incident is a good prompt to confirm your backup actually restores, on a blank device, before you ever need it to.
FAQ
Is ELLIPAL affected by the Coldcard vulnerability?
No. The flaw is specific to Coldcard's firmware build system. On ELLIPAL Titan 2.0, seed generation uses a single hardware TRNG path inside the CC EAL5+ secure chip, with no software fallback for key generation.
How do I know ELLIPAL's RNG claim is true?
You do not have to take it on faith, and that is the point of this article. Generate a seed with ELLIPAL Joy, whose source code is public on GitHub, or with dice, or with any BIP39 tool you trust, then import it. From that moment your keys do not depend on our internal generator.
Can I import my existing seed phrase into an ELLIPAL wallet?
Yes. Titan and X Card accept 12 to 24 word BIP39 phrases. On Titan the words are entered on the offline device itself. On X Card the import happens on the offline Starter device, so the phrase does not touch a connected phone.
Did Coldcard users lose money because of user error?
No. Users followed instructions correctly. The randomness underneath their phrases was weaker than designed, which made the phrases computable. Storage discipline cannot fix a phrase that was born guessable, and that is what makes this incident worth studying.
Does a passphrase protect against a weak RNG?
Partially. A strong passphrase is an independent secret, so a computed phrase alone does not open the hidden wallet. It does not restore missing entropy, and Coinkite still recommends migration for affected devices. Forgetting a passphrase means permanent loss, so it is a tool for experienced users.
Is a hardware wallet still worth it after this?
Yes. The failure was one implementation, not the model. Keys generated and stored offline remain the strongest practical protection for self-custody. The refinement this incident adds: prefer a setup where the parts that matter can be verified or replaced by you.
How is ELLIPAL Joy different from rolling dice?
Same principle, less friction. Dice with a lookup table involve no vendor at all and take an afternoon to do properly, at 99 rolls for 256 bits of entropy. Joy produces a standard BIP39 phrase from hardware entropy in one step, and its code is public, so the process is auditable rather than taken on faith.
What does an ELLIPAL setup cost?
Current prices are listed on the official ELLIPAL store and move with promotions, so check there rather than third-party listings, which also avoids counterfeit risk. Joy and the X Card are the entry points, and the Titan 2.0 is the flagship device.
What happens if I lose my ELLIPAL device?
Your funds live on the blockchain, not in the device. Restore from your seed phrase, or your phrase plus passphrase, on a replacement device. This is also why the quality and backup of the phrase matter more than any single piece of hardware.
The record
ELLIPAL has built hardware wallets for self-custody since 2018, used by more than 1 million people across 140+ countries. The air-gapped Titan 2.0 carries a CC EAL5+ certified secure chip and signs by QR code only. Devices support BIP39/BIP44, 10,000+ tokens across 45+ chains, seed import and passphrase. Joy's source code is public at github.com/ELLIPAL/ellipal-joy.
Own it. Then use it.
This article describes a third-party security incident based on public disclosures as of August 1, 2026: the Coinkite advisory and technical backgrounder, Block's engineering analysis and community on-chain tracking. Figures attributed to community tracking are estimates. ELLIPAL is a self-custody hardware wallet maker and does not hold user funds.