Part 2: A Taleb lens
Part 2 of 5 in a deep dive on hardware wallets, randomness and the vaults behind every device. Start with Part 1 if you are new to the series.
A Taleb lens: the cup is safe, the process is not
Taleb uses a coffee cup on a table to explain fragility, and I want to extend that image to key security. Billions of atoms inside the cup vibrate in random directions every second, yet the cup does not jump, crack, or drift across the table. Countless small, independent fluctuations cancel each other out, and no single atom can move the cup.
This is what Taleb calls Mediocristan: a domain where randomness is mild, bounded by physics, and where no single observation can dominate the total. A well-designed hardware random number generator lives exactly there. Ring-oscillator jitter is thermal noise from enormous numbers of electrons, conditioned and stretched by a DRBG into uniform output. Waiting for a properly generated 256-bit key to be guessed is like waiting for the cup to jump on its own.
The cup can still end up on the floor when someone knocks it off the desk.
You can have the best random number generator in the world, and your process can still expose you to black swans.
The entropy layer is Mediocristan. The process layer, made of people, user interfaces, firmware updates, supply chains, and seed backups, is Extremistan, where a single event can dominate everything that came before.
Fragility and the absorbing barrier
Taleb returns to the coffee cup in Antifragile for a second lesson. The cup survives millions of tiny shocks, but a one-foot drop does far more than twelve times the damage of a one-inch drop. Harm is nonlinear, and the cup has no upside from volatility, only loss. In his framing, anything linear in harm is already gone; what survives is what can absorb small stressors.
A private key has the same payoff profile. It gains nothing from events. It can only be lost. And on a public blockchain, loss is final: there is no chargeback, no issuer dispute, no reversal window. In Taleb's terms, that is an absorbing barrier. Once you hit it, averages, base rates, and past performance stop mattering, because you are no longer in the game.
Black swans in key custody
Taleb defines a black swan by three properties: it is outside regular expectations, it carries extreme impact, and after the fact we build a story that makes it look predictable. The table maps the incidents in this piece against that definition.
| Incident | Was the entropy layer sound? | Where the process failed | Black swan property |
|---|---|---|---|
| Binance (Oct 2026) | Yes, MPC key shares were never exposed | Compromised engineer machines reached a signing service that approved non-standard delegations with no human in the loop | About $6.3 billion moved in roughly 20 minutes after months of quiet staging; one burst outweighed years of clean operations |
| eMudhra (Oct 2026) | No, but the random generator was not the cause: a key-ceremony script produced weak keys | Weak keys sat in trusted certificate chains for about 18 months without anyone noticing | One disclosure, and within a week the company left the global TLS certificate business |
| Ledger via CryptoBilis (Oct 2026) | Yes | Devices sold through one reseller carried a hidden implant that read the recovery phrase off the screen during setup | Phrases were collected quietly, then drained in one wave; more than $90 million by on-chain estimates |
| Coldcard (Jul 2026) | No: the firmware never used the device's hardware random generator | A build setting passed every review for five years | Wallets created since 2021 were drained in waves within days; about $116 million |
| Bybit (Feb 2025) | Yes, secure-element keys in Ledger devices | A compromised UI plus blind signing on routine-looking transfers | One transaction moved about $1.5 billion; hindsight now calls blind signing "obvious" |
| Wintermute (Sep 2022) | No, Profanity's 32-bit seed | Assets were moved off the vanity address, but its admin rights over the vault were not revoked | Weakness was public days earlier; the loss came from one forgotten permission |
| Randstorm (2011 to 2015 wallets) | No, silent fallback to Math.random() | Library code failed without raising an error and was copied into many products | Wallets looked safe for a decade, which read as evidence of safety |
| Ledger Recover (2023) | Yes | Firmware policy, not hardware, decides whether the seed can leave the chip | No funds lost, but users discovered optionality they did not know the vendor held |
| Trezor Safe 3 MCU (2025) | Yes | Supply-chain protections could be bypassed through the microcontroller beside the secure element | Supply-chain path through the least-protected chip |
Even the entropy disasters were process disasters. No ring oscillator failed in Wintermute, Randstorm, eMudhra or Coldcard. Someone chose a vanity generator built on mt19937, a library silently fell back to a browser PRNG and nobody tested for it, a script in a formal key ceremony swapped in weak keys, or a firmware build quietly skipped the hardware generator.
The turkey problem in signing operations
Taleb's turkey is fed every day for a thousand days, and each day raises its confidence that the farmer loves it, right up to the day before Thanksgiving. Signing operations have the same dynamic. A multisig that has approved hundreds of routine hot-wallet top-ups trains its signers to approve the next one quickly. Every successful signature is evidence of safety until the one that is not. The Bybit signers were approving what looked like a planned transfer from a cold wallet to a hot wallet.
What a Taleb-informed posture looks like
Once the entropy layer is sound, I would put the next dollar into the process layer. Taleb's toolkit translates directly.
- Survive the tail first
- Cap what any single signature can do. Spending limits, timelocks, address allowlists, and velocity rules turn a potential total loss into a bounded one. Bybit's core exposure was that one approved transaction could change control of the entire cold wallet. Binance's was a signing service with no effective ceiling on what a single authenticated caller could move.
- Via negativa
- Remove before you add. Remove blind signing. Remove standing admin keys and unused permissions. Remove single seed backups and single-vendor dependencies. Subtraction removes whole failure paths, while added tools often add new ones.
- Barbell the holdings
- Keep the bulk in high-friction cold multisig with independent devices and people, and a small hot float you can afford to lose. The dangerous zone is the middle: setups that feel cold but sign routinely through a web UI.
- Redundancy is insurance, not waste
- Multi-vendor secure elements, geographically split backups, and diverse signer devices look inefficient until one vendor's library leaks, as EUCLEAK showed.
- Prefer systems that gain from stressors
- Open firmware, public bug bounties, and competitors like Ledger Donjon testing Trezor hardware expose the ecosystem to many small, survivable attacks, which in Taleb's terms makes the system antifragile. Closed designs avoid those small stressors and can accumulate hidden fragility instead.