How OneKey Wallets Generate Your Recovery Phrase — and Where the Randomness Comes From

This article walks through how each OneKey model produces the entropy and the recovery phrase when you create a new wallet, and why the recent concerns about certain software RNG implementations don't apply to OneKey's wallet-creation paths.

Wallet security starts with randomness nobody can predict

The security of a wallet begins with one thing: entropy — the unpredictable random bits used to create it. A recovery phrase is just a human-readable encoding of that entropy. If the entropy is predictable at the moment of creation, nothing you add afterward — a PIN, where you store the phrase, how addresses are derived — can undo the damage.

Different OneKey models don't all pull their randomness from the same place. Here's exactly where the entropy behind your recovery phrase comes from on each device.

The issue that's been in the news traces back to a misconfigured Yasmarang PRNG in libngu, where certain builds ended up bypassing the chip's TRNG. OneKey's relevant firmware paths don't use libngu, Coinkite, Coldcard, or any CKCC dependency, and multiple rounds of audit confirm they genuinely call the hardware or secure-element TRNG. Below, we go device by device through the actual hardware randomness interface each one uses.

What is entropy, and why can't a wallet live without it?

Think of entropy as a measurable amount of unpredictability, usually counted in bits. 128 bits of entropy means 2^128 possible starting values; absent some other flaw, an attacker has nothing to do but guess. Your private keys, your addresses, and your ability to sign are all derived deterministically from that single starting secret.

So the safety of a recovery phrase doesn't come from the fact that a dozen English words "look like a lot." It comes from how unpredictable the raw entropy behind them is:

• 128 bits of entropy → 12 BIP39 words;
• 192 bits of entropy → 18 BIP39 words;
• 256 bits of entropy → 24 BIP39 words.

Weak randomness lets an attacker reproduce the inputs from the moment your wallet was created and land on the exact same phrase and private key. No amount of SHA-256, PIN protection, or secure-element storage can turn a predictable input into genuinely unpredictable entropy.

From a random number to a recovery phrase: how the math actually works

The details differ by model, but every BIP39 wallet shares the same computation model:

Hardware true random number generator (TRNG)
        ↓
Draw 128 / 192 / 256 bits of entropy (ENT)
        ↓
Take the first ENT / 32 bits of SHA-256(ENT) as the checksum (CS)
        ↓
Split ENT || CS into 11-bit groups, map each to one of 2048 BIP39 words
        ↓
12 / 18 / 24 words → seed → private keys, addresses, and signing keys

For example, a 12-word phrase uses 128 bits of entropy plus a 4-bit checksum — 132 bits total, which divides cleanly into 12 groups of 11 bits. Each group is an index into the BIP39 word list.

The SHA-256 step here is only computing the BIP39 checksum; it is not a random number generator. The randomness of the phrase still rests entirely on the raw entropy captured at creation time.

So why is OneKey's implementation untouched by the ColdCard issue? Below we break down, device by device, how each model's initial random number is produced and whether it ever lands in the affected code path.

OneKey Pro

OneKey Pro

Is it affected?

No — not by the ColdCard libngu / Yasmarang issue. Pro's current build enables THD89 by default. When you create a wallet on the device, the THD89 TRNG provides the random input, and the firmware handles the BIP39 or SLIP39 encoding that follows.

How it's generated

THD89 TRNG → wallet initialization entropy → firmware encodes BIP39 or SLIP39.

Pro's random.bytes() defaults to source=1, which calls se_random_encrypted() under the default USE_THD89=1 build.

Notes on the randomness

• Pro's default build enables THD89, and the random bytes come from se_random_encrypted() — not from the Yasmarang or libngu software-PRNG path.
• Per the OneKey Help Center, the TRNG in today's EAL6+ secure element grounds its randomness in physical processes such as electronic noise.

OneKey Classic 1S

OneKey Classic 1S

Is it affected?

No — not by the ColdCard libngu / Yasmarang issue. Classic 1S's current, public on-device creation flow takes its entropy from the THD89 secure-element TRNG, and the BIP39 phrase string is encoded by the MCU firmware.

How it's generated

THD89 TRNG → 128 / 192 / 256 bits of entropy → MCU encodes the BIP39 phrase.

Notes on the randomness

• Saying "the phrase is generated by THD89" isn't quite accurate: THD89 supplies the random input, while the BIP39 word encoding happens in the MCU firmware.
• The firmware calls THD89's se_random_encrypted() interface and does not use Yasmarang or libngu. Per the OneKey Help Center, the TRNG in today's EAL6+ secure element produces randomness from physical processes such as electronic noise.

OneKey Classic 1S Pure

OneKey Classic 1S Pure

Is it affected?

No — not by the ColdCard libngu / Yasmarang issue. The public code doesn't give Classic 1S Pure a separate entropy-generation branch; it shares the same firmware-classic1s codebase as Classic 1S. So when you create a wallet, Pure's entropy also comes from the THD89 TRNG and is encoded into a BIP39 phrase by the MCU.

Verified flow

THD89 TRNG → 128 / 192 / 256 bits of entropy → MCU encodes the BIP39 phrase.

Pure being a battery-free product doesn't change this public creation path.

Notes on the randomness

• Don't assume Pure has a different entropy mechanism just because it's sold as its own model.
• Just like Classic 1S, the public creation code calls the THD89 randomness interface and does not use Yasmarang or libngu.

OneKey Classic

OneKey Classic

Is it affected?

No — not by the ColdCard libngu / Yasmarang issue. On the secure-element-enabled Classic firmware path, the SE provides the random material used to create the wallet, and the MCU turns it into a BIP39 phrase.

How it's generated

SE provides random material → the first 32 bytes are taken as entropy → MCU encodes the BIP39 phrase.

Notes on the randomness

• This path obtains its random material through the SE's init and export interfaces, and does not call the Yasmarang or libngu RNG implementation — so it never lands in the affected code path under discussion.
• The public code can't individually pin down the SE model and certification for every batch of Classic. When describing it publicly, go by the chip documentation for the specific batch rather than applying another model's certification to Classic.

OneKey Mini

OneKey Mini

Is it affected?

No — not by the ColdCard libngu / Yasmarang issue. Mini's on-device creation flow draws its entropy from the STM32 MCU's hardware random number generator, and the MCU then encodes it into a BIP39 phrase.

How it's generated

STM32 MCU TRNG → 128 / 192 / 256 bits of entropy → MCU encodes the BIP39 phrase.

In Mini's older firmware, random32() reads the STM32 RNG peripheral directly and rejects consecutive duplicate outputs. The on-device creation flow uses exactly this randomness to generate the phrase.

Notes on the randomness

• The MCU reads the STM32 hardware RNG peripheral directly, and the firmware also rejects consecutive duplicate outputs. This path does not use Yasmarang or libngu.

Security advice for users

• No matter where the entropy comes from, once a recovery phrase leaks, anyone can restore the wallet. Backing it up offline and accurately is always your responsibility.
• If a recovery phrase is lost, no device, app, or manufacturer can recover it for you.

Further reading and sources

• OneKey Help Center: How does a OneKey hardware wallet generate a recovery phrase and guarantee its randomness?
• OneKey Pro: reset_device
• OneKey Pro: random source implementation
• OneKey Pro: build config that enables THD89 by default
• Classic 1S: reset.c
• Classic 1S: config.c
• OneKey Classic / Mini: reset.c
• Historical commit: Mini using Microchip ATECC608