Restoring a Seed on Another Manufacturer's Wallet: What BIP39 Guarantees and What It Does Not

Anyone who holds crypto assets in self-custody usually buys a device from a company to do it. That company can make mistakes, lose customer data, discontinue a model or one day cease to exist. From that follows an uncomfortably concrete question: does your access to the funds depend on that company?

The answer is not in the vendors' marketing. It is in three technical specifications that have been publicly available for more than ten years. They are called BIP39, BIP32 and BIP44. Anyone who understands what they set down can answer the vendor question without taking an advertising claim on trust. And anyone who knows the limits of those standards also understands why recovery on another manufacturer's hardware still goes wrong on a regular basis.

This article explains both: what the standard guarantees you, and where it leaves you on your own. At the end there is a test you can run on a quiet evening, one that gives you a solid answer instead of an assumption.

Hardware wallet vendor lock-in: what actually depends on the manufacturer

A hardware wallet is a small computer with exactly one job. It generates a random value, keeps it shielded and signs transactions with it without ever revealing it. What depends on the vendor is the firmware, the companion software on your computer and customer support. The key itself depends on the vendor only if the device departs from the open standards.

That distinction is the whole heart of the matter. Firmware, companion software and support are replaceable. A key that exists only in a proprietary format would not be. Which is precisely why it is worth reading the specification before money moves onto a device.

BIP39: how 128 to 256 bits of randomness become twelve to 24 words

BIP39 describes how a random seed value is translated into a memorable sequence of words. The specification stipulates that the initial entropy must be a multiple of 32 bits and lie between 128 and 256 bits. A checksum is formed from that entropy by appending the first ENT/32 bits of its SHA256 hash. The result is split into groups of eleven bits, and each group, as a number between 0 and 2047, points to an entry in a word list of 2048 items. The text of the specification is public and short enough to read in an evening.

That produces the familiar lengths. 128 bits of entropy plus four checksum bits give twelve words; 256 bits plus eight checksum bits give 24 words. In between sit the rarer variants of 15, 18 and 21 words. A 24-word sequence therefore uses the same technique as a 12-word sequence, simply with more initial randomness.

The sentence that decides the vendor question comes next. The actual seed value is computed from the word sequence using the PBKDF2 function: the word sequence as the password, the string "mnemonic" plus an optional passphrase as the salt, 2048 iterations, HMAC-SHA512 as the underlying function, 512 bits as the result. That procedure is fully deterministic and contains, at no point, any identifier of the device, the firmware or the vendor. Enter the same words into a different device that implements the same standard and you get the same 512-bit value. That is the guarantee at issue here, and it is mathematical in nature.

The checksum catches typing errors but corrects nothing

The checksum is short, and the specification itself spells out the consequence: roughly one in 256 random errors goes unnoticed, and the procedure offers no correction facility. In practice that means a mis-transcribed word will usually produce an error message, but not always. In the unlucky case the device accepts the input and generates a completely different, empty wallet. Which is exactly why every backup needs a check in which the words are actually read in once.

The word list is part of the procedure

Because the calculation runs from the word sequence itself and not from the original entropy, the same sequence of numbers in a word list of another language produces an entirely different seed value. The specification points this out explicitly and recommends the English list for that reason. Anyone who created a backup using the French or Japanese word list will later need a device that knows precisely that list. With the English list the problem practically never arises, because every serious implementation supports it.

The passphrase is a word that appears in no backup

The optional passphrase enters the calculation as part of the salt. Every passphrase therefore turns the same word sequence into its own, entirely valid wallet. A typing error in the passphrase produces no error message. It produces a different, empty wallet, because the procedure cannot distinguish between "wrong" and "different" at all.

For recovery on another manufacturer's hardware this is one of the most common pitfalls. The new device accepts the word sequence, shows an empty wallet and thereby looks like proof that portability does not in fact work. In reality only one component is missing, one the user set themselves and wrote down nowhere. How to keep a passphrase sensibly without storing it next to the words is something we described on August 8, 2026 in our article on storing a seed phrase safely.

BIP32 and the derivation path: why the same seed yields different addresses

The 512-bit seed value is not yet an address. BIP32 describes how any number of key pairs are derived from it hierarchically, and BIP44 gives that derivation a fixed order with five levels: purpose, coin type, account, change flag and address index. It is written as a chain of numbers separated by slashes, known as the derivation path.

The five levels of a BIP44 path

A typical path reads 44'/0'/0'/0/0 and denotes the first address of the first bitcoin account in the classic address format. The apostrophe marks a hardened level, from which subordinate keys cannot be computed without the seed value. The first number stands for the address format: 44 for the classic form, 49 for the nested SegWit variant, 84 for native SegWit. Change that single number and every address below it changes.

This is the most practically important point in this article. Two devices can process the same seed entirely correctly and still display completely different addresses, because they have different paths preset. The seed is right every time. A balance only becomes visible on the path where it actually sits.

The derivation path is the most common reason for an apparently empty wallet

How far practice departs from the standard is set out with remarkable candour by one manufacturer in its own developer documentation. The Ledger Live documentation on derivation paths states that by no means every wallet adheres to BIP44, that many ask the user directly for a path, and that numerous exceptions have been built in over time to absorb those deviations. For Ethereum the software therefore scans addresses under 44'/60'/0'/x and counts up to ten empty accounts before it ends the search.

The same document contains the sentence on which the practical consequence hangs: anyone stuck on an unusual path who wants to use the software has to move the balance to a conventional path using the original tool. That describes no single vendor's failing. It describes a condition the entire industry works with, because conventions only established themselves after the first implementations.

For you a plain rule follows: the derivation path belongs with the backup. A word sequence with no note of which device and which address format were in use remains recoverable, but in an emergency it costs you search time. Which devices preset which paths, and how openly the respective companion software handles them, can be looked up in our hardware wallet comparison before you settle on a model.

SLIP-0044 gives every chain its own number in the path

The second level of the path is the coin type. Which number belongs to which chain is set out in a public list called SLIP-0044. Bitcoin carries 0 there, Litecoin 2, Dogecoin 3, Ether 60, Bitcoin Cash 145, Solana 501 and the BNB chain 714. The list now runs to several thousand entries and grows with every new chain.

In practice that means two things. Holdings on different chains sit in separate branches derived from the same seed, which is why a device that does not know a chain cannot display its balance either. And some chains have switched coin type over the course of their history, or maintain several numbers in parallel. Anyone missing a balance after changing devices should know this list before assuming a loss.

The gap limit explains why software overlooks a balance that is there

Even within the correct path a trap is waiting. Wallet software scans accounts and addresses in sequence and ends the search as soon as a certain number of consecutive addresses shows no incoming payment. That cut-off is called the gap limit. BIP44 explicitly prescribes this behaviour, because otherwise the search would never end.

The consequence is unpleasant. If an address far down the list was used manually in the past, standard-compliant software can overlook it and display an empty account. The balance remains on the chain and is visible through any block explorer; only the search logic does not reach far enough. The remedy is an application in which the gap limit can be raised or a path entered by hand. Anyone who has been in this position understands why experienced users do not pick their addresses at random from the middle of a list.

Where the standard ends: Shamir shares, multisig and proprietary formats

Not every backup is a BIP39 word sequence, even if it looks like one at first glance. There are three cases you should keep apart, because they restrict portability to different degrees.

The first is the Shamir procedure under SLIP-0039, in which the secret is split into several shares and a minimum number of them suffices for recovery. Such shares look like a word sequence but follow a different procedure and work only on devices that support precisely that procedure. The second case is multisig setups, where several keys sign together: there, in addition to the words, you need the wallet descriptor with all public keys and the rule for how many signatures are required. Without that file the balance cannot be reached with the words alone, and experience shows it goes missing more often than the words themselves. The third case is devices that store the key exclusively in a proprietary format and never hand it out as a readable word sequence.

Before you buy, a single question settles it: does the device output a BIP39 word sequence that can be read into another manufacturer's hardware? If the manual gives only a proprietary term for the backup, with no reference to an open standard, that is reason to look more closely.

What a vendor failure means in practice, and what it does not

This newsroom's own coverage of recent weeks includes several cases in which a provider let its customers down. On July 31, 2026 we reported on a firmware flaw that made generated seeds computable. On August 13, 2026 the subject was a data breach at a service provider that exposed the names and home addresses of a wallet manufacturer's customers. On the custody side at trading venues the question is sharper still, because insolvency law comes on top of the technology there; when custodied coins can be segregated from the estate is something we set out separately on August 18, 2026.

For self-custody a sober balance can be drawn from this. A data breach affects your privacy and raises the risk of targeted fraud attempts by post, phone or email, but it does not touch your key. A manufacturer's insolvency ends firmware maintenance and support, yet leaves a standard-compliant seed untouched; the device becomes a discontinued model, the balance does not. It only becomes serious in the third case, a flaw in the generation of the random value. No standard helps against that. There the only option is moving to a freshly generated seed, and promptly.

The common line that the coins are on the blockchain and not on the device is therefore both correct and incomplete. It holds precisely when the seed was generated cleanly and follows the open standard. Both can be checked, and without specialist knowledge.

The recovery test: how to check today whether your backup holds tomorrow

A backup that has never been read in is an assumption. The following test turns it into a finding. It takes about twenty minutes and costs nothing beyond the network fees on a minimal transfer.

The test with an empty account

First get hold of a second, open-source wallet application on a device you will reset afterwards, and enter your word sequence there along with the passphrase. In that software select the same derivation path your main device uses. Then compare the first receiving address with the address your main device shows in the same position. If both strings match, portability is proven: your balance depends on the word sequence and the path, on no company.

If you want it stricter, send a minimal amount to an address derived exclusively from the backup, and send it back from there. That tests the signature too, not merely the address display. Reset the test device afterwards and remove the software.

Two details go into your notes alongside the words at the end: the full derivation path and the number of words. The passphrase belongs somewhere else, otherwise you defeat its purpose. Anyone already settling what should happen to access in an emergency should add this note straight into their estate documents.

Checking seed recovery: what to take away

1. Run the recovery test before you need it. Read your word sequence into a second, independent application once and compare the first receiving address with that of your main device. Which programs are open source and permit custom derivation paths is set out in our software wallet comparison.
2. Note the derivation path with the backup. The words alone are technically enough; the path saves you hours in an emergency. When you next buy a device, check that the vendor presets conventional paths and outputs a BIP39 word sequence; the models in our hardware wallet comparison differ markedly on this.
3. Separate trading holdings from custody holdings. What you intend to hold long term in self-custody does not belong permanently on a trading account, because none of the standards described here works in your favour there. Which trading venues are regulated and what their withdrawal routes look like is shown in our crypto exchange comparison.

(As of August 19, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)