The hardware wallet industry has recently seen a security incident involving the randomness of recovery phrases. Many users have started to worry: are hardware wallets unsafe after all? The episode is a reminder that the security of a hardware wallet depends not only on whether the private key is kept offline, but also on how that key was generated in the first place.
The conclusion first: recovery phrases generated by the SafePal S1, S1 Pro and X1 are not affected by this incident. But more importantly, than just stating "we're fine" is the question the incident raises: random number generation is the most fundamental stage of hardware wallet security, and also the easiest one to overlook. In this article we want to explain, as plainly as we can, the random number architecture behind a SafePal recovery phrase.
TL;DR
You don't need to do anything. Recovery phrases generated by the SafePal S1, S1 Pro and X1 are unaffected by this incident. There is no need to regenerate a phrase or migrate assets.
Why: Every time SafePal hardware wallet generates a seed phrase, it obtains fresh true random numbers on the spot, then processes them through a dual-chip architecture and cryptographic mixing. It does not depend on any single chip or any single source of randomness.
The one exception: if your recovery phrase was originally generated on affected Coldcard firmware, that phrase remains in an affected state even if you later imported it into SafePal or another wallet. Follow the official migration guidance published by Coldcard. What matters is where the phrase was first generated, not which wallet you use today.
The quality of the random number sets the ceiling on security
Generating a random number is like laying a foundation. If there is a structural defect at the moment the concrete is poured, no amount of careful work on the floors above will bring the building up to standard. Foundational problems of this kind are usually very hard to fix afterward.
Cryptographic algorithms such as SHA3-256 play the role of further processing and reinforcement. They thoroughly mix the input so that no pattern remains visible in the result, but they cannot conjure randomness that was not there to begin with.
This is the core of the recent incident. If the initial random seed sits within a small, enumerable range, then no matter how complex the subsequent processing is, an attacker can still work through that limited range to find the corresponding result.
SafePal's primary principle and approach: obtain true randomness first, then process it
SafePal's approach is simple and straightforward: Make sure you have enough fresh, genuinely secure random data, then process it, not the other way around.
In practice, every time a new wallet is created, SafePal calls the device's secure random number interface again to obtain the initial entropy needed for a 12- or 24-word recovery phrase, then adds checksum information and maps it to the words the user sees, in accordance with the BIP39 standard.
SafePal does not start from a fixed value, a predictable state, or a low-entropy pseudorandom number and then "stretch" it with a hash algorithm into a 256-bit number that merely looks complicated. A hash can mix, compress, and conceal the structure of its input, but it cannot manufacture randomness that was never there.
If secure random data cannot be obtained correctly at any step, if the returned data is too short, or if the call fails, wallet creation stops outright. It does not quietly fall back to low-quality software randomness and carry on generating a recovery phrase without the user knowing.
With that established, let’s go a step further into why SafePal uses a dual-chip architecture, and what role each input plays in the randomness generation process.
SafePal's design philosophy: never depend on a single random number generator
Most modern chips include a hardware true random number generator (TRNG), and under normal conditions these are highly reliable. However, security design has never been about normal conditions alone. It also has to account for the low-probability failures that cannot be undone once they happen: the random number module failing, firmware calling or configuring it incorrectly, or data being read repeatedly.
A recovery phrase is usually generated once and may be used for many years. If something goes wrong with the randomness at the exact moment of generation, the device returning to normal operation afterward doesn’t retroactively make that already-generated seed phrase secure.
That’s why SafePal’s hardware wallets (the S1 and X1 series) use a dual-chip architecture:
• One Secure Element chip
• One application chip (MCU)
Each of the two chips has its own independent hardware random number generator and its own unique device identifier.
When generating a random number, SafePal combines random data from both chips, their respective unique identifiers, the device's runtime timer, and the dynamic state produced by the user's own actions. The data is then mixed through cryptographic algorithms to form the random data ultimately used to generate the recovery phrase and keys.
What each input contributes
| Input source | Role |
| Random data from each of the two chips | The primary source of unpredictability. Two independent sources mean that if one behaves abnormally, the other can still supply randomness. |
| The unique identifiers of the two chips | Each chip receives a unique identifier at the factory. It is not a secret and is not used as randomness itself; its role is to ensure that two devices running an identical process do not arrive at an identical internal state. (These identifiers are stored only on the device. SafePal does not upload them or maintain any corresponding database.) |
| The device runtime timer | Every device runs its own independent clock. Device startup time, the moment the wallet creation flow is entered, and how long the user spends on each step all change the internal state. It is not a primary source of randomness, but it widens the differences between devices and between sessions. |
| Dynamic state from user interaction | Button presses, page changes and confirmations create additional dynamic input. Users do not need to deliberately "produce randomness", these actions serve as supplementary input alongside the chip randomness and other device state. |
Why mix multiple sources?
SafePal does not take raw data from any one source as the final result; it mixes several sources together. The thinking behind this is not that every source of randomness will always work correctly, but that if one link in the chain fails, the sources still functioning can hold up the security of the whole.
Cryptography cannot create randomness out of nothing, of course. If every source genuinely providing randomness fails at once, no algorithm can turn predictable data into truly random data. What a multi-source design solves is not "nothing will ever go wrong" but "one thing going wrong should not bring down the entire mechanism."
Random number security is more than "does the chip have a TRNG?"
Judging whether a hardware wallet's randomness is secure cannot come down to whether a TRNG appears on the chip's specification sheet. What actually determines security is:
- whether the firmware calls the random number module correctly
- whether data of sufficient length is read
- whether error returns are handled correctly
- whether repeated or uninitialized data can occur
- whether the design relies on a single source of randomness
- whether the mixing algorithm is sound
- whether adequate testing follows every firmware update
Random number security has always been something hardware and software achieve together. That is the part of this incident genuinely worth reflecting on for every hardware wallet manufacturer.
Public code and community review
The firmware code for the SafePal X1 is public, and the random number generation logic in the S1 and S1 Pro is the same. Interested developers and security researchers can read the relevant source directly.
Ordinary users do not need to understand every line of it. The point of open source is that the community and professional security researchers can inspect the actual implementation, verify that our public description matches the code, and help us find potential problems.
Do I need to regenerate my recovery phrase and migrate my assets?
No. The problem disclosed in this incident comes from a specific implementation in a specific product, and does not mean that every hardware wallet shares it. There is currently no evidence that SafePal users need to regenerate a recovery phrase or migrate assets because of it.
The one exception: if your recovery phrase was originally generated on the affected hardware wallet, that phrase remains in an affected state even if you later imported it into SafePal or another wallet. Follow the official migration guidance published by the relevant manufacturer. What matters is where the phrase was first generated, not which wallet you use today.
One further note: please do not rush to import your recovery phrase into another device, website or piece of software simply because of discussion on social media. A hasty migration, a phishing site, or an exposed phrase often poses a more immediate risk to your assets than this incident does.
Whichever hardware wallet you use, we recommend the following:
- prefer devices with a dedicated secure element and a true random number generator
- do not import a recovery phrase generated by another wallet unless you understand how it was generated
- never photograph, screenshot, or store a recovery phrase electronically in any form
- never enter a complete recovery phrase into any web page
- download and update firmware only through official channels
- send a small test transaction before any large transfer
- when you see a security advisory, confirm which models and versions are affected before acting
Treat any website that asks you to enter your recovery phrase in order to "check its randomness," "fix a vulnerability," "upgrade firmware," or "claim compensation" as phishing, without exception.
In closing
What the user sees is just 12 or 24 words. Behind them is a critical process carried out jointly by a dual-chip architecture, hardware random number generators, internal device state, dynamic user input and cryptographic algorithms. A building's upper floors are only as safe as the foundation beneath them.
SafePal's design philosophy has not changed: never assume any single source of randomness will always work, and never let one localized failure cascade into a collapse of the entire mechanism. We will continue to welcome scrutiny from the community and from security researchers, and to keep refining our random number generation and our overall security design, so that we can offer users more reliable and more secure hardware wallets.
About SafePal:
Founded in 2018, SafePal is a next generation non-custodial crypto wallet suite backed by Animoca Brands, Binance and Superscrypt. The suite empowers access to decentralized and centralized finance on 200+ blockchains across its hardware, software, and browser extension wallet solutions.
Encompassing a diverse mix of crypto asset management solutions like cross-chain swapping, trading and yielding tools, centralized exchange (CEX) mini programs, a fiat gateway and Mastercard for users — SafePal serves 30 million users globally across 200+ regions and countries in 16 languages.
SFP is a decentralized BEP-20 and ERC-20 token fuelling the SafePal ecosystem with various utilities such as discounts on SafePal products, staking boost and airdrop rewards, seamless conversion to gas tokens, and more.
Stay informed about SafePal here
