One RNG, No Fallbacks: How Vault12 Guard Generates Seed Phrases — and Why the Coldcard Failure Can't Happen Here

On July 30, 2026, Coinkite published a security advisory that confirmed the worst kind of bug a wallet can have: for five years, Coldcard devices had been generating seed phrases with far less randomness than advertised. In a single 25-minute window, one entity swept 594 BTC from roughly 500 addresses. By August 2, on-chain analysts had traced over 1,300 BTC — roughly $89 million — drained across more than 4,500 addresses.

The cause was not exotic cryptography. It was a one-line build error. During a 2021 firmware migration, a preprocessor guard checked whether a configuration flag existed rather than what its value was. The result: the hardware true random number generator was silently replaced by a software fallback PRNG called Yasmarang, seeded from mostly predictable chip data. As Block's engineering team documented, effective entropy collapsed to roughly 40 bits on Mk3 devices and about 72 bits on later models — instead of the 128 to 256 bits users believed they had.

Two details of the incident deserve your attention, because they define what a trustworthy RNG design looks like.

First, the weak output was indistinguishable from strong output. Coldcard's onboard statistical self-tests passed for five years. The seeds looked random. You cannot inspect randomness into existence — the only assurance that matters is provenance: knowing exactly which code path produced your bytes.

Second, hashing didn't help. Coldcard whitened its RNG output through SHA-256, but hashing a predictable stream just produces a predictable hash. If a generator has only 2⁴⁰ possible internal states, it can only ever produce 2⁴⁰ distinct seeds, no matter how many megabytes you feed through a hash function.

With those two lessons in hand, here is exactly how Vault12 Guard generates a seed phrase.

How Vault12 Guard generates your seed phrase

When you create a wallet in Vault12 Guard, generation runs as a pipeline with one source of randomness: the platform CSPRNG, exposed as WebCrypto's crypto.getRandomValues. On iOS this is wired to the kernel-seeded AES-CTR generator behind arc4random_buf; on Android it is Chromium's BoringSSL implementation drawing from the kernel's getrandom(). These are the most heavily scrutinized random number generators on Earth, exercised billions of times a day by every TLS handshake on every phone.

The pipeline works like this. A dedicated background worker fills a 1 MiB buffer with CSPRNG output, requested in chunks that respect the WebCrypto per-call quota. That buffer is hashed with SHA-256, and the digest is chained into the next round: each subsequent buffer embeds the previous round's hash, so the final digest depends on every byte of every round. Rounds are strictly serialized — a new round begins only after the previous one has fully completed — and generation runs for at least five rounds over about five seconds before the app will let you continue.

The final SHA-256 digest is then sliced to the exact BIP39 entropy width for your chosen phrase length — 16 bytes for 12 words up through the full 32-byte digest for 24 words — and encoded into a mnemonic by @scure/bip39, an independently audited, minimal, version-pinned without external dependencies library that validates its inputs and its wordlist on every call. The arithmetic is exact: 12 words carry 128 bits of entropy, 24 words carry 256, precisely the BIP39 nominal strengths

The property that actually matters

Look back at the great wallet RNG failures of the last fifteen years and a single pattern repeats. Randstorm (2011–2015): a type-check bug silently fell back from window.crypto to Math.random, exposing over a million BTC. Trust Wallet's browser extension (2022): a Mersenne Twister with a 32-bit seed generating mnemonics. Milk Sad (2017–2023): a wall-clock-seeded PRNG in Libbitcoin's bx. Cake Wallet: Dart's Random() where Random.secure() was needed — a one-identifier difference. And now Coldcard: a hardware TRNG and a software fallback living in the same firmware, with a broken switch between them.

In every single case, the fatal ingredient was the same: a second, weaker generator present in the code that the application could silently select.

That ingredient does not exist in Vault12 Guard. There is exactly one RNG path. There is no fallback generator, no conditional RNG selection, no polyfill, and no Math.random anywhere in the seed-generation flow — a property we verify across the entire codebase. Our cryptographic libraries are exact-version-pinned with integrity hashes, and they are built to throw an error rather than degrade if the platform CSPRNG is unavailable.

Which leads to the second structural property: the pipeline fails closed. We recently commissioned a multi-agent adversarial security review of the entire generation flow — independent investigation tracks, with every finding re-tested by adversarial agents instructed to refute it. The review traced every failure mode it could construct: the worker failing to load, the CSPRNG throwing, the hashing API missing, users double-tapping buttons, canceling mid-generation. Every single path ends the same way — generation halts and the Continue button stays disabled. There is no code path from any failure to a seed phrase. The review's conclusion was blunt: no code path can deliver a weak, short, or non-random phrase. A Coldcard-style silent substitution has no foothold, because there is nothing to substitute.

Tranparency

Our multi-round, multi-megabyte generation ceremony is defense-in-depth and legitimate whitening — but we do not pretend it adds strength beyond the source. If the platform CSPRNG were itself compromised, no amount of hashing would repair it. That is the Coldcard lesson, and we refuse to rely on hashing volume as a security claim.

That means our design carries exactly one residual trust assumption: that the operating system's CSPRNG is honest. It is a far better bet than trusting vendor firmware reviewed by a handful of people — WebCrypto's getRandomValues has no documented, exploited real-world failure in any mainstream browser or system WebView, ever, a track record no other primitive in this story can claim. Coldcard users who mixed in 50+ dice rolls were the ones who walked away untouched; independent-source mixing is that same principle, built in.

Entropy is also not a new obsession for us. Back in 2017 we published True Entropy, open-source research (and a free iOS app) that turns a phone camera's thermal sensor noise — fundamentally quantum-level physics — into true random numbers at 18 Mb per minute, cleaned through a von Neumann extractor and validated against NIST's SP800-90B entropy test suite. We have been thinking about where randomness comes from since before it was a $89 million question.