A user restores a wallet from a seed phrase and sees zero balances on accounts that previously held funds. The seed phrase is correct, the wallet software is legitimate, but the recovered accounts appear empty. This scenario repeats across cryptocurrency forums and support channels with predictable frequency, and the cause is almost always the same: the wallet is deriving accounts from a different path than the original wallet used. BIP32 hierarchical deterministic derivation means that a single seed phrase can generate millions of valid addresses across multiple standards, and if the recovery path does not match the original, the recovered accounts will be mathematically valid but functionally useless.

Understanding wallet path derivation is therefore not an optional technical detail for users managing browser wallets. It is the difference between successful recovery and permanent loss of access to funds. The problem extends beyond simple confusion about which wallet to use; it involves competing standards, wallet-specific implementations, blockchain-specific conventions, and the fact that most browser wallets make these choices silently in the background. A user who knows why a Ledger wallet on Ethereum derivation path m/44’/60’/0’/0 produces different addresses than a MetaMask wallet on the same seed phrase has a clear recovery strategy. A user who does not may spend hours testing wallets and watching balances remain at zero.

How hierarchical deterministic wallets generate accounts from seed phrases

A seed phrase is a human-readable encoding of a root secret, typically 12 or 24 words. When imported into a wallet application, that seed is converted into a root extended private key, which then serves as the mathematical foundation for deriving child keys. This derivation is not random; it follows a deterministic path defined by BIP32 (Bitcoin Improvement Proposal 32), the standard that introduced hierarchical deterministic wallets. Every step down the derivation path is irreversible: you cannot derive the parent key from a child key, but given the parent key and the path specification, you can regenerate the same child key infinitely.

The derivation path is written in a notation that looks like a file directory: m/44’/60’/0’/0/0 tells the wallet exactly which sequence of derivations to perform. The m represents the master key derived from the seed. The first number after a forward slash is the first derivation step, the second number is the second step, and so on. The apostrophe symbol (‘) indicates a “hardened” derivation, which has a particular cryptographic property: it ensures that a compromised child extended public key cannot be used to derive sibling keys. Different wallet types, blockchain networks, and implementation choices all use different paths.

A browser wallet typically makes this choice invisible to the user. When you create a new wallet or import a seed phrase, the software silently selects a derivation path, derives the first account, and displays that account’s address. The user sees only the final address, not the derivation mathematics underneath. If the user later restores the same seed phrase in a different wallet application, that second application might use a different standard derivation path. The seed phrase is identical, the cryptography is valid in both cases, but the addresses are completely different because they were derived via different mathematical paths.

BIP44 and the multi-purpose derivation standard

BIP44 built on BIP32 by adding an additional layer of structure specifically designed for wallets that need to manage multiple blockchains and multiple accounts. The full BIP44 path follows the pattern m/purpose’/coin_type’/account’/change/address_index. The purpose field is always 44′ to indicate that BIP44 rules apply. The coin_type field identifies the blockchain: Bitcoin uses 0′, Ethereum uses 60′, Litecoin uses 2′, and so on. The account’ field allows a single wallet to maintain separate accounts on the same blockchain, each with its own derivation branch. The change field distinguishes between addresses used for receiving payments (0) and addresses used for returning change from transactions (1). The address_index is simply the counter that generates the first address, second address, third address, and so on within that specific branch.

BIP44 was designed to solve a real usability problem: a user should be able to restore a single seed phrase into any compliant wallet and retrieve the same accounts and balances. If Wallet A derives account 1 using m/44’/60’/0’/0/0 and Wallet B also uses BIP44 for Ethereum, Wallet B should derive the same address at m/44’/60’/0’/0/0 and therefore recover the same account. This interoperability is theoretically perfect but practically fragile because not every wallet implements BIP44 correctly, and some wallets use non-standard variations or entirely custom paths.

Ledger, for example, uses m/44’/60’/0’/0/n for Ethereum accounts on BIP44, but the wallet also supports m/44’/60’/n’/0/0, which is a non-standard variant that changes the account derivation structure. MetaMask by default uses the standard BIP44 path for Ethereum, but it also allows custom paths. MyEtherWallet offers multiple derivation path options including Ledger’s non-standard variant. This fragmentation means that a user restoring a Ledger-generated seed phrase into MetaMask might see completely different accounts unless they explicitly select the matching derivation path from a settings menu that many casual users never notice exists.

Why wallet recovery shows zero balances on the wrong path

When a browser wallet imports a seed phrase, it derives one or more accounts and checks the blockchain to see if those accounts hold funds. If the derived path happens to be different from the original derivation path, the wallet will find a perfectly valid set of accounts with zero balances. This is not a software error; it is mathematically correct behavior. The wallet derived accounts correctly according to its specified path. Those accounts simply do not contain the funds because the funds were sent to accounts derived from a different path.

The user’s task is then to determine which derivation path was used originally. If the original wallet is still available, the solution is straightforward: use that wallet or a compatible wallet on the same path. If the original wallet has been deleted or the user cannot remember which wallet was used, recovery becomes a process of systematic testing. Some wallets support multiple derivation paths in their settings. A user might enable “Ledger derivation mode” in MetaMask, for instance, which switches to the non-standard path used by Ledger devices. If that path contains the expected balance, the problem is solved. If not, the user tests the next standard.

This trial-and-error recovery process reveals a critical weakness in user-facing wallet design: most browser wallets do not make the derivation path visible or easily adjustable. A sophisticated user can access browser developer tools or wallet source code to discover what path a particular wallet uses, but an ordinary user with a critical recovery situation cannot. The result is that thousands of users have funds in valid accounts on deterministic paths they cannot access because their recovery wallet chose a different path. The funds are not lost; they exist on the blockchain in addresses derived from the original seed. But they are practically unreachable without either restoring the original wallet or learning the original derivation path.

Browser wallet implementations and path variation across platforms

The landscape of browser wallets includes not only different implementations but also different blockchain networks, each with their own coin_type conventions and community standards. Alby for Lightning and Bitcoin uses a specific derivation approach optimized for the Lightning Network. Ambire, Backpack, Braavos, and other Solana-focused wallets use Solana’s coin_type 501′. Ethereum wallets including Coinbase, MetaMask, and Exodus typically default to coin_type 60′, but their implementations of the account and address index layers can differ.

Browser-based wallets also differ in how they handle the change field (the 0 or 1 in the path). Some wallets strictly separate receive and change addresses; others mix them or ignore the convention entirely. When a transaction is sent from a wallet, the change (the portion of the input not sent to the recipient) is typically sent back to an address derived at change index 1. If a user imports their seed into a wallet that does not use the same change convention, the wallet might derive and display only receive addresses from index 0, leaving change addresses completely hidden. Funds sent as change to those hidden addresses would appear to vanish from the user’s perspective.

Hardware wallets like Ledger and Trezor have their own derivation standards, and browser extensions that connect to hardware wallets must match those standards. Ledger’s Ethereum app uses a non-standard variation that has become widely adopted through popularity, creating a de facto standard that conflicts with the published BIP44 specification. When a user exports a Ledger seed phrase and tries to import it into a software wallet like MetaMask, they must actively select “Ledger Derivation Path” from the wallet’s recovery options. If they do not know this setting exists or forget to use it, recovery fails silently.

Recovery procedures and path verification across multiple wallets

The safest recovery procedure begins before any loss occurs: when creating a wallet for the first time, a user should record not only the seed phrase but also which wallet was used and, if possible, which derivation path the wallet employs. This information is rarely provided in user-facing documentation because wallet developers assume users will restore to the same wallet. In practice, wallets disappear, developers cease support, browser compatibility breaks, and users discover they cannot run the original wallet on their new device.

When recovery becomes necessary, the starting assumption should be that no funds are lost; they are simply on a derivation path the current wallet is not checking. The first step is to determine whether the original wallet is still available or whether documentation about it survives. If the original wallet software can be run, use it to verify that the accounts with funds are still accessible. Take a screenshot or write down one address from the original wallet and confirm it is recorded on the blockchain with the expected balance. If the original wallet is unavailable, research which wallets support your blockchain and which derivation paths they offer.

For Ethereum recovery, testing multiple derivation paths is practical because several major wallets exist. A user might test accounts using MetaMask’s default BIP44 path, then switch to Ledger’s non-standard variant, then try MyEtherWallet’s options. Modern guidance for browser wallets should include this path information, though finding it may require checking multiple sources or wallet documentation. For less common blockchains or wallet combinations, recovery might require using a tool like Ian Coleman’s BIP39 derivation tool, which allows manual entry of seed phrases and derivation paths to see which addresses they produce. This tool should be used only in a secure environment and never on an internet-connected device with malware risk.

Once you identify the correct derivation path by finding a known address from your original wallet, the remaining recovery process depends on wallet availability. If the original wallet is still functional, use it. If not, find another wallet that supports the same derivation path. This might require using a less convenient wallet than you prefer, but correctness takes priority over convenience when funds are at stake.

Multi-coin wallets and blockchain-specific derivation confusion

Browser wallets that support multiple blockchains introduce an additional layer of complexity because each blockchain has its own coin_type in the BIP44 standard. Exodus, Crypto.com wallet, and similar multi-asset browsers wallets maintain separate accounts for Bitcoin (coin_type 0′), Ethereum (coin_type 60′), and other networks. A user who exports a seed phrase from Exodus, which might have been managing Bitcoin, Ethereum, and Litecoin across three separate coin_type branches, might then try to import that seed into a Bitcoin-only wallet. That Bitcoin wallet would only search the Bitcoin coin_type 0′ branch, and if the user’s funds were actually on a different blockchain’s branch, recovery would fail.

The inverse problem also occurs: a user who creates a seed phrase in a single-coin wallet like a Bitcoin-only browser extension and then tries to use that seed in a multi-coin wallet might accidentally create Ethereum accounts without realizing it. They send Ethereum to an address they believe they generated from an empty account, but unknown to them, a recovery wallet had already derived that same address on the Ethereum coin_type 60′ branch weeks earlier, where it was receiving funds. The address appears to be a fresh receiving address in one context and an old active address in another.

Coin-switching recovery is particularly risky with tokens built on blockchain networks like Ethereum. A user might restore an Ethereum wallet and see zero ETH, then conclude the recovery failed, without realizing that their actual funds were in ERC-20 tokens at the same Ethereum address. The tokens are there, but the wallet interface might not display them unless the token contract addresses are explicitly configured or imported. Recovery success and recovery failure can look identical on screen.

Testing and verification before moving funds

After recovering a wallet on what you believe is the correct derivation path, the next step is verification before moving large amounts. Send a small test amount from your recovered account to an external address you control. Confirm that the transaction broadcasts successfully and that the recipient receives it. This step accomplishes two things: it confirms that the derived account is actually functional and not read-only or otherwise restricted, and it demonstrates that the derivation path is indeed correct because the account actually holds spendable funds.

Only after the test transaction completes should you move remaining funds. If the test transaction fails with an error message, investigate the error rather than retrying. Common failure modes include the wallet being derived as read-only or using a different signing mechanism than the account expects. Some browser wallets derive public-key-only accounts for security reasons and require an external signer like a hardware wallet or connected signing service. If the recovered account is read-only and you do not have access to the corresponding hardware wallet or external signer, you may need to use a different recovery wallet.

The testing process also catches mistakes in address copying or network selection. A user who is meant to recover an Ethereum account but accidentally selects a Polygon network might derive valid Polygon addresses at the same path and spend time trying to figure out why the account holds zero MATIC tokens. Recording which blockchain each wallet operates on and confirming the network before each recovery step prevents this common error.

Documentation gaps and wallet responsibility

The broader problem underlying recovery failures is that most browser wallet applications do not adequately document their derivation path choices. A user opening Coinbase Wallet, MetaMask, Ambire, or Backpack for the first time sees a simple “Create Wallet” or “Import Wallet” button with no indication of which BIP standard they will implement or which path they will use. After the wallet is created, that path information is typically inaccessible from the user interface. Recovery documentation often exists in GitHub repositories or technical forums rather than in user-facing help sections.

This is a design choice, not an oversight. Wallet developers assume that users will stick with one wallet and consider detailed technical documentation a distraction. The assumption holds for users who never lose devices, never need to switch wallets, and never have to recover from seed phrases. It fails for the substantial minority of users who do. The consequence is that wallet recovery, which should be a standardized and reliable process, instead becomes a troubleshooting adventure where users test different wallets hoping to match an unknown path.

Some wallets have begun to address this by offering settings menus where users can select alternative derivation paths. This is an improvement, but it shifts responsibility to users to understand what each option means and to remember which path they need. The ideal solution would be for browser wallets to make derivation paths visible and adjustable by default, similar to how hardware wallet interfaces display the path before each transaction. Until that standard emerges, users must learn these technical details independently and document their wallet choices carefully.