What Does the Ideal Hardware Wallet Look Like?

The Coldcard entropy bug has seen over $100M worth of BTC drained across multiple attack waves so far.

This flaw laid dormant for years, leading to many Coldcard hardware wallets checking only if the devices’ random number generator (RNG, i.e. the component supplying unpredictability for your wallet’s private keys) existed, but not whether it was being called at runtime.

Coldcard’s RNG Bug Has Reportedly Compromised As Much As 2,000 BTC on Bankless

A weak RNG in Coldcard wallets has cost users an estimated +$100M worth of BTC in less than a week.

The fundamental question that matters here, then, is where does your private key’s randomness come from?

Some approaches are better than others. If we look across the hardware wallets space today and its various design philosophies, there are pillars that, if combined, would make for a virtually impenetrable cold wallet, or at the very least, a more resolute option than what many alternatives offer.

Stitch these foundations together, and a scenario like the Coldcard exploit becomes all but impossible. Any attack would have to come in some other unprecedented way. As I see it, these pillars are as follows…

1) No single entropy failure point

A hardware wallet ideally mixes multiple independent randomness sources together (often via a hash function) so that one broken source can’t bork a whole seed.

Trezor deserves a shoutout here, as they do this well. Their devices combine internal hardware TRNG (true random number generator, i.e. randomness pulled from physical electronic noise) with 256 bits from your host computer via SHA-256. Plus, their newer Safe 7 line adds a third source of entropy through a dedicated secure element.

BitBox02 notably goes even further in this vein, drawing by default from five separate sources: your password, your computer, a microcontroller, a secure chip, and manufacturing data. The redundancy might seem like overkill, but crypto security can only benefit from thoroughness like this.

Multiple entropy sources are only worth something if the code actually uses them. You can have four different sources of randomness in the device, but if it is using a test generator instead (code bug), none of those sources actually matter. Rolling dices doesn’t imply the device…

— Tomas Susanka (@tsusanka) August 3, 2026

2) User-verifiable randomness

A hardware wallet can be designed well, but at various points there are still certain trust assumptions you have to accept when using them. That said, it’s nice to have optionality, and it’s nice to be able to use a hardware wallet in such a way that you don’t have to trust its machinery at all.

This is why some cold wallets let users roll their own dice for entropy. This technique isn’t a silver bullet on its own, but it does offer the awesome advantage of providing an avenue for users to check the math afterward themselves. DIY verification of the RNG, as it were.

SeedSigner exemplifies this model in production today. These devices are built from off-the-shelf parts (Raspberry Pi Zeros, camera modules, etc.), and they ship with a guide on how to reproduce your seed generation math via an independent tool so that you can directly confirm everything lines up yourself.

3) Open source builds

To be sure, an assurance like dice verifiability only goes so far if a wallet’s firmware itself is a black box.

Devices like Trezors and BitBox02s shine here because their firmware repos are fully open source, meaning anyone can compile the code and get a binary that hashes identically to the official release, i.e. no trust required.

Moreover, note that the community project WalletScrutiny independently rechecks this kind of reproducibility on a regular basis, so you can routinely keep tabs and confirm matches for what’s running on your personal devices. The site is Bitcoin-centric, but it’s a great resource in any regard.

4) Hardware diversity

For wallets that do lean on dedicated secure chips, the shield for vendor risk is straightforward: don’t source the silicon from just one place.

Keystone is a hardware wallet team that combines secure elements from multiple different manufacturers to generate its keys, thus a flaw or backdoor in any one chip wouldn’t compromise the whole system. In other words, it’s the redundancy principle in silicon form.

5) Fail closed

It’s true that the randomness of Coldcard devices was botched for five years, but the more troubling dimension of the case is that this misconfiguration was allowed to function. Put otherwise, the system kept running on a broken path, “fail open” style, instead of stopping.

Ellipal builds around this vector directly as I understand it. Its Titan line of wallets use a single hardware TRNG path with no software redoubt. If this system fails for some reason, it “fails closed,” i.e. key generation doesn’t proceed. Easier said than done, sure, but ideally a hardware wallet should refuse to produce a broken key.

Zooming out

The Coldcard vulnerability might seem obvious in hindsight now that people have pored over the incident, but it’s also understandable how it was a hard failure mode to catch. The RNG was suitable to work, it seemed to be confirmed as working, yet all the while it wasn’t being invoked at runtime.

That said, in isolation the pillars I mentioned above could run into problems too. Layer them all together, though, and you’d get a pretty damn good hardware wallet that could safely weather a failure here or there.

No single wallet on the market today combines all five of these approaches, although some get close. And that reality leads to my grand point. We don’t need hypothetical breakthroughs in this vertical, as we already have the components necessary to create an absolute tank of a hardware wallet. Here’s hoping someone pulls this off in the not so distant future, since this sort of device would offer a strong shield against some of self-custody’s worst specters.