A user holds a recovery phrase of twelve or twenty-four words generated by their SafePal S1 hardware wallet. From those words alone, in a specific mathematical sequence, the device derives hundreds or thousands of unique private keys\u2014one for each cryptocurrency account, each address, each layer of their financial identity. The mechanism is not arbitrary. It follows standards established by the Bitcoin Improvement Proposals 39 and 44, which define how a single seed generates a hierarchical tree of key material. Understanding that process is essential for anyone using SafePal for serious asset storage, recovery, or managing multiple accounts across different blockchains and address types.<\/p>\n
The distinction between seed, derivation path, and private key is not semantic. When a SafePal S1 device generates a wallet, the secure element chip creates a seed\u2014random data that becomes the root of all downstream keys. That seed never leaves the device. Instead, mathematical operations applied to that seed produce different keys depending on the derivation path requested. A user or custodian who understands how SafePal implements these standards can verify that recovery will work as expected, manage multiple accounts without confusion, and avoid common mistakes that expose key material or create unrecoverable addresses.<\/p>\n
<\/p>\n
The recovery phrase is not the seed itself. It is an encoding of the seed into human-readable words. BIP39 (Bitcoin Improvement Proposal 39) defines a standard mapping from a list of 2048 English words to entropy. When SafePal generates a wallet, the secure element chip first creates random entropy\u2014typically 128 bits (12-word phrase) or 256 bits (24-word phrase). This entropy is then passed through a standardized algorithm that produces a mnemonic phrase: twelve or twenty-four words from the official BIP39 word list.<\/p>\n
The phrase itself includes a checksum. The last word is not independent; it is calculated from the others. This means a user who accidentally omits or misorders a word will receive a clear error rather than silently importing the wrong wallet. SafePal enforces this check during recovery, preventing a common failure mode where a slightly incorrect phrase imports successfully but generates different addresses than expected.<\/p>\n
The conversion from phrase back to seed uses a key derivation function called PBKDF2. The user enters their recovery phrase and may optionally provide a passphrase (sometimes called a “25th word”). The phrase and passphrase are processed through PBKDF2 with HMAC-SHA512, producing a 512-bit seed. That seed is deterministic: the same phrase and passphrase always produce the same seed, and thus the same keys. If a user imports their recovery phrase into another wallet implementation that also follows BIP39, they will recover the same accounts and addresses\u2014provided the derivation path is also standard.<\/p>\n
The passphrase is a lesser-known but powerful option. Adding a passphrase creates an entirely different wallet from the same recovery phrase. For example, a user might backup the 12-word phrase, create one wallet without a passphrase for frequent use, and create a second “hidden” wallet using a non-obvious passphrase known only to them. If someone recovers the 12-word phrase, they will see the first wallet but not the second. SafePal supports this model, but the responsibility shifts entirely to the user: if the passphrase is forgotten and not backed up separately, the hidden wallet is permanently inaccessible.<\/p>\n
BIP44 defines a hierarchical structure for deriving multiple accounts from a single seed. Without a standard, each wallet developer would organize keys differently, making recovery and interoperability impossible. BIP44 establishes a tree with specific branches: one for Bitcoin, one for Ethereum, one for Litecoin, and a unique number for each supported blockchain. Within each coin type, there are multiple accounts, and within each account, there are separate address chains for external (receive) and internal (change) addresses.<\/p>\n
The derivation path is written in a notation that looks like: m\/44’\/0’\/0’\/0\/0<\/strong>. The “m” means master key (derived from the seed). Each number separated by “\/” is a step down the tree. The apostrophe indicates hardened derivation, which provides stronger isolation between keys. The first hardened level (44′) is fixed by the standard. The second (0′) specifies the coin type: 0′ for Bitcoin, 60′ for Ethereum, and so forth. The third (0′) is the account number, allowing unlimited sub-accounts from the same seed and coin type. The fourth (0) is the change designation: 0 for external addresses (those a user would give someone to send funds), 1 for change addresses (where a wallet places leftover funds from transactions).<\/p>\n SafePal’s implementation creates a wallet from a single seed that can hold thousands of cryptocurrencies simultaneously. When a user selects Bitcoin, the app derives keys along the Bitcoin path (m\/44’\/0’\/0’\/0\/x). When they select Ethereum, the app follows the Ethereum path (m\/44’\/60’\/0’\/0\/x). Each blockchain gets its own branch, so a single seed produces independent private keys for each supported asset. The secure element chip performs all derivation internally; the mobile app never handles the derivation process or intermediate keys.<\/p>\n Account numbers add another layer of organization. A user could theoretically create m\/44’\/0’\/0’\/0\/0 for one Bitcoin account and m\/44’\/0’\/1’\/0\/0 for a second. This is useful for separating funds by purpose: one account for long-term storage, another for frequent trading, a third for specific business transactions. SafePal allows this, but most users never need it. The default single account is sufficient for most scenarios because within that account, SafePal can generate an unlimited number of addresses by incrementing the final index (x in m\/44’\/0’\/0’\/0\/x).<\/p>\n Once a derivation path is established, SafePal derives the actual private key for that path using another HMAC-based function called HMAC-SHA512. The output is split: the left 256 bits become the private key, the right 256 bits become a “chain code” used for further derivation if needed. The private key is never exposed outside the secure element chip unless the user explicitly backs it up (which they typically do not\u2014the recovery phrase is sufficient).<\/p>\n Hardened derivation, indicated by the apostrophe, means that the chain code itself is used in the HMAC calculation rather than the public key derived from the private key. This has a critical security consequence: without the private key, an observer cannot derive child keys from a hardened parent. If a user’s public key and chain code are compromised, hardened-only paths are still safe. In contrast, non-hardened paths allow public-key-only derivation. A merchant or observer with only a public key and chain code could theoretically generate all downstream addresses on a non-hardened path, which may enable address linking or privacy analysis.<\/p>\n BIP44 uses hardened derivation for the coin type and account levels specifically to prevent this risk. If a user backs up their extended public key (xpub) for a specific account, a third party with that xpub can see all current and future addresses and amounts on that account\u2014but not the private keys, and not the addresses from other hardened accounts. SafePal keeps the full extended public key on the mobile app so it can derive addresses without asking the hardware device each time. The private keys remain on the secure element chip, signing transactions when needed.<\/p>\n The final index (address position) is typically non-hardened. This allows the mobile app to efficiently generate new addresses without consulting the hardware device, improving user experience. Each time a user opens SafePal and navigates to their Bitcoin account, the app does not request a new address from the hardware device; instead, it increments an index and derives the next address using the xpub. This speed comes with a privacy trade-off: an observer with the xpub knows all addresses on that account, though they still cannot spend from them.<\/p>\n While BIP44 is the standard, SafePal also permits custom derivation paths for advanced use cases. A user or developer might need to recover a wallet created with a different path structure, or manage keys that were generated before BIP44 became universal. The SafePal S1 accepts custom path input through its QR code interface, allowing a user to specify any path they understand, though this responsibility is theirs alone.<\/p>\n Custom paths create real risks. If a user enters the wrong path, they will derive correct-looking addresses and keys\u2014but not the ones where funds are actually stored. For example, if funds were generated on path m\/44’\/0’\/0’\/0\/0 but the user attempts recovery using m\/44’\/0’\/0’\/1\/0 (changing the change designation), they will see an empty account. The backup phrase is correct, the derivation is mathematically valid, but it does not match the original setup. This is not a fault of SafePal or BIP39; it is a consequence of determinism itself. Recovery depends not just on having the correct recovery phrase, but on the correct derivation context.<\/p>\n Some older wallets used non-BIP44 structures, such as sequential key generation without hierarchical organization. Users migrating from those systems sometimes need to recover using custom paths. SafePal’s support for custom derivation paths is powerful for this scenario, but it shifts responsibility to the user. Before attempting custom recovery, a user should document their original derivation structure, test the path on a small amount if possible, and keep detailed records of success or failure. The secure element chip will faithfully execute whatever path is requested; it cannot warn the user if that path does not match the original setup.<\/p>\nAddress generation and the difference between hardened and normal derivation<\/h2>\n
Custom derivation paths and non-standard recovery scenarios<\/h2>\n