A user restores their hardware wallet’s recovery phrase into a MetaMask wallet extension and expects to see the same addresses and balances. Instead, the interface shows an empty account. The same seed phrase, the same wallet software, but different addresses—and the funds appear to have vanished. This scenario repeats often enough to generate support tickets and forum posts. The explanation lies not in lost keys or missing coins, but in how different wallet implementations calculate addresses from a single recovery phrase using different derivation paths.
Understanding account derivation paths is essential for anyone managing cryptocurrency across multiple wallet interfaces. A recovery phrase is mathematically capable of generating trillions of unique addresses. The specific sequence of mathematical steps used to arrive at a particular address is determined by a standard called BIP-44, but different wallets interpret that standard in subtly different ways. When a MetaMask wallet extension connects to a hardware device or when a user switches wallet software, these differences become a practical problem: the same secret can unlock many different sets of addresses depending on which path the wallet follows.
What a recovery phrase actually contains
A recovery phrase, typically twelve or twenty-four words, encodes a single cryptographic seed. That seed is not an address; it is the root from which all addresses and private keys are derived. The seed itself never appears on the blockchain. Instead, it generates a master key, which then follows a mathematical path downward into branches and sub-branches, ultimately producing specific private keys and their corresponding addresses.
This structure exists because a single recovery phrase needs to support multiple accounts, multiple blockchains, and multiple address types without requiring the user to generate and memorize separate seeds for each one. The standard that defines how this branching works is BIP-32, which establishes the concept of hierarchical deterministic (HD) derivation. Every time a wallet reads a recovery phrase, it must decide which branch to follow. That decision is encoded in what is called a derivation path, a notation that looks like m/44’/60’/0’/0/0, where each number represents a step down the hierarchy.
The critical insight is that changing a single number in the derivation path produces a completely different address from the same recovery phrase. If wallet A uses m/44’/60’/0’/0/0 and wallet B uses m/44’/60’/1’/0/0, they will generate different addresses even though they both start from the same seed. The funds sent to the address generated by wallet A will not appear in wallet B, not because the recovery phrase is wrong, but because wallet B is looking at a different branch of the same tree.
The recovery phrase is therefore more accurately understood as a master key to many possible wallets rather than a single wallet itself. Private key control—the ability to recover funds and authorize transactions—rests with whoever has the recovery phrase. But which addresses correspond to the phrase depends entirely on the derivation path chosen by the wallet software. This distinction is often missed by users who assume that a recovery phrase should produce identical results in any wallet.
BIP-44 standard and why implementations diverge
BIP-44 is a widely adopted standard that defines a common format for derivation paths, primarily to allow wallets to interoperate. The full path includes five levels: purpose (44 for BIP-44), coin type (60 for Ethereum, 0 for Bitcoin), account (which account within the wallet), change (whether the address is for receiving or internal change), and index (which specific address in that sequence). For Ethereum on a standard wallet, the path m/44’/60’/0’/0/0 means: use BIP-44 standard (44), use Ethereum coin type (60), use the first account (0), use receiving addresses (0), and get the first address (0).
Despite a unified standard, wallet implementations make different assumptions about which part of the path is most important. The MetaMask wallet extension typically derives one address per account on the Ethereum network and does not increment the final index number when adding additional accounts within MetaMask itself. Instead, it increments the account level (the third zero in m/44’/60’/0’/0/0). This means the first MetaMask account is at m/44’/60’/0’/0/0, the second at m/44’/60’/1’/0/0, and so on. This approach matches the BIP-44 standard but reflects a particular design choice about how to organize multiple accounts.
Hardware wallets, particularly Ledger and Trezor, often follow a different convention. Ledger’s Ethereum application traditionally uses m/44’/60’/0’/0/n, where n increments (0, 1, 2, 3) for each new address, rather than incrementing the account level. This difference is not a bug; both implementations follow BIP-44. They simply made different choices about which part of the path to use for account management. When a user imports their Ledger recovery phrase into MetaMask, the wallet extension looks for accounts at m/44’/60’/0’/0/0, m/44’/60’/1’/0/0, m/44’/60’/2’/0/0, while the funds were stored at m/44’/60’/0’/0/0, m/44’/60’/0’/0/1, m/44’/60’/0’/0/2. The addresses are completely different.
Certain older hardware wallet versions and specialized software (such as MEW—MyEtherWallet) used even different paths, including non-standard deviations designed for specific use cases or legacy support. Some users may find that their hardware wallet was initialized with a custom derivation path that differs from the defaults in both MetaMask and modern hardware wallet software. This creates a situation where the recovery phrase is correct, but the wallet software is searching the wrong branch of the key tree.
Why MetaMask and hardware wallets produce different addresses
The specific conflict between MetaMask wallet extension and hardware wallets arises from a fundamental difference in how they handle account management. When you connect a hardware wallet to MetaMask, the two devices must agree on which derivation path to use. MetaMask offers an option during the connection process to select either “Ledger Live” path or “Legacy” path (or similar terminology depending on the hardware device). This option exists precisely because different accounts may be stored on different derivation paths.
If a user initialized their hardware wallet in Ledger Live, the addresses follow the Ledger Live path (m/44’/60’/0’/0/n). If they then connect that same hardware wallet to MetaMask and MetaMask defaults to its own path (m/44’/60’/0’/0/0, then m/44’/60’/1’/0/0), no matching addresses will appear. The recovery phrase is intact. The hardware wallet is functioning correctly. The private keys are accessible. But MetaMask is asking for addresses that were never generated on the hardware wallet in the first place.
The confusion is amplified because connecting a hardware device to a MetaMask wallet extension does not import the recovery phrase into MetaMask. Instead, MetaMask requests signatures from the hardware device for specific addresses. MetaMask tells the device, “I want the private key for address m/44’/60’/0’/0/0,” and the device generates it on the fly without revealing the recovery phrase itself. This design protects the recovery phrase but also means that if MetaMask is asking for the wrong derivation path, it receives signatures for addresses that hold no funds on the blockchain.
This also explains why a user who imports their recovery phrase directly into MetaMask (rather than using a hardware wallet connection) sees different addresses than their hardware device. If the recovery phrase was initialized on a hardware wallet using the Ledger Live path, and the user copies the recovery phrase and imports it into MetaMask, MetaMask will immediately apply its own default path and show addresses that differ from those on the hardware device. The funds are not lost; they remain at the addresses generated on the hardware wallet under the hardware wallet’s chosen path. MetaMask simply cannot see them because it is looking in the wrong place.
Finding your addresses on the correct derivation path
The first diagnostic step is to confirm which derivation path actually holds your funds. If you used a hardware wallet, the original device should still be able to display your addresses under the path it originally chose. Open the hardware wallet software (Ledger Live, Trezor Suite, or equivalent) and navigate to the account settings. The addresses shown there are the ones where your funds are located. Write them down or screenshot them. Do not share this information with anyone, but use it as a reference point.
Next, compare those addresses to what MetaMask shows. If you are connecting a hardware wallet to MetaMask for the first time, look for an option to select the derivation path or account type. For Ledger devices, MetaMask typically offers “Ledger Live” as one option (corresponding to m/44’/60’/0’/0/n) and “Legacy” as another (an older Ledger standard). Select the path that matches the accounts visible in Ledger Live itself. If you are using Trezor, check whether the hardware wallet software shows “SLIP44” or another variant and ensure MetaMask is set to match.
If you have directly imported a recovery phrase into MetaMask and want to find the addresses that were originally generated on a hardware wallet, you may need to use a different tool. Block explorers and address derivation tools can help you explore different paths from the same recovery phrase without moving funds. Some tools like Ethers.js or the BIP-39 standard derivation calculator allow you to input your recovery phrase and specify a path, then see the resulting addresses. Never paste your recovery phrase into an online tool unless you absolutely trust the source and have confirmed it is not a phishing site. The safer approach is to verify with your original hardware wallet device which path was used, then explicitly configure MetaMask to match that path when connecting.
How to recover funds stuck on an inaccessible derivation path
If your funds are confirmed to be at addresses on a derivation path that your current wallet software does not access, recovery is possible but requires deliberate steps. The principle is simple: you control the recovery phrase, so you can access any address derived from it, provided you use the correct derivation path. The challenge is ensuring that you are using that path correctly and securely.
The most straightforward recovery method is to use the original wallet software or device that generated those addresses. If your funds are on a Ledger wallet’s default path, use Ledger Live. If they are on a Trezor, use Trezor Suite. These tools will display the correct addresses and allow you to transfer funds to an address on a path that your current wallet software (such as MetaMask wallet extension) can access. This requires paying a network fee, but it moves the funds to an address that both your hardware wallet and MetaMask can see going forward.
If the original wallet software is unavailable or the hardware device is lost, you have a second option: import the recovery phrase into a wallet that supports custom derivation path configuration. Some wallets explicitly allow users to choose their derivation path rather than enforcing a default. This approach requires extreme caution. Importing a recovery phrase into any software wallet, even temporarily, exposes the secret to potential compromise. Ideally, this should only be done on a device that is disconnected from the internet, using trusted open-source software that you have verified. After moving the funds to a more accessible derivation path, you should consider the recovery phrase compromised and plan to rotate it by moving all funds and deriving new addresses from a new seed phrase.
A third option, if the amounts are significant and the technical steps are uncertain, is to consult a professional recovery service that specializes in cryptocurrency key derivation and fund movement. These services charge a fee but can handle the technical details while minimizing the risk of exposing your recovery phrase to additional compromise. Always verify that such a service is reputable and uses secure, offline processes before sharing any sensitive information.
Preventing the problem when using hardware wallets
The most effective prevention strategy is to establish your wallet configuration early and document it clearly. When you first set up a hardware wallet, the initialization process will guide you to create or import a recovery phrase. At that moment, note which wallet software you are using (Ledger Live, Trezor Suite, MetaMask, MEW, etc.) and which derivation path is being applied. This information should be written down in a secure location, not stored online or in cloud services.
If you plan to use MetaMask wallet extension as a primary interface while holding your recovery phrase on a hardware device, establish that connection immediately and verify that the addresses match before moving any significant funds. When you first connect a hardware wallet to MetaMask, the interface will typically show one address or ask you to select from a list. Confirm that address against what your hardware wallet software displays. If there is a mismatch, do not proceed; instead, disconnect and check the path settings before attempting to connect again.
For users who prefer to keep a hardware wallet as a backup or secondary signer while using MetaMask as a daily interface, the best practice is to initialize the hardware wallet in a way that produces addresses compatible with MetaMask’s default paths. This may involve using MetaMask to generate the recovery phrase in the first place (though this is less common) or explicitly configuring the hardware wallet to match MetaMask’s derivation standard during initial setup. Different hardware wallet devices have different configuration options; consulting the device documentation or support team before initialization can prevent confusion later.
Multi-chain complications and non-EVM blockchains
The derivation path problem becomes even more complex when you move beyond Ethereum to other blockchains. Bitcoin uses coin type 0 (m/44’/0’/0’/0/0), Litecoin uses coin type 2 (m/44’/2’/0’/0/0), and Solana uses a non-BIP-44 path entirely (m/44’/501’/0’/0’/0′). If you have a single recovery phrase that backs multiple blockchains, each blockchain will have its own derivation path. A hardware wallet that supports Bitcoin, Ethereum, and Solana will generate completely separate address sequences for each, all from the same recovery phrase.
The MetaMask wallet extension primarily focuses on EVM-compatible blockchains (Ethereum and networks like Polygon, Arbitrum, etc.). If you also use your recovery phrase for Bitcoin or Solana through different wallet software, be aware that those software tools will use entirely different coin type values in the derivation path. The recovery phrase itself is universal, but the addresses it generates are specific to the path and the blockchain. This design is actually a feature—it isolates addresses across different blockchains and reduces the risk that a pattern of addresses on one chain can be linked to the same wallet on another chain. However, it requires users to track multiple sets of addresses for the same recovery phrase.
Some hardware wallets provide unified interfaces that support multiple blockchains while deriving addresses from a single recovery phrase. Trezor, for instance, allows you to manage Bitcoin, Ethereum, Solana, and many other assets in a single software dashboard. The underlying recovery phrase is unchanged, but the device generates appropriately-scoped addresses for each blockchain. When connecting to external applications like MetaMask wallet extension, ensure you understand which blockchain the connection is using and whether the address being presented matches the blockchain you intended.
Key takeaways for preventing and resolving path mismatches
The core issue is that a recovery phrase is not synonymous with an address or an account. It is a master key that, combined with a derivation path, produces addresses. Different wallet software and hardware devices follow different conventions for deriving that path, even when they all claim to follow the BIP-44 standard. Before moving significant funds, verify that your MetaMask wallet extension is displaying the same addresses as your hardware wallet or original wallet software. If an address mismatch exists, do not assume the funds are lost or the recovery phrase is wrong. Instead, identify the derivation path being used by the wallet software that actually holds your funds, then configure your current wallet software to match that path or use the original software to move the funds to a compatible path.
Recovery is almost always possible because the recovery phrase itself has not been compromised. The challenge is matching the correct derivation path to access the address tree where the funds actually reside. This requires patience, documentation, and careful verification at each step. If you are ever uncertain, it is better to spend time confirming the correct path with a hardware device that you control than to rush and expose your recovery phrase to unnecessary risk. The funds are recoverable as long as you have the recovery phrase and the security of that phrase remains intact.
Frequently asked questions
Why does my recovery phrase show different addresses in MetaMask than on my hardware wallet?
MetaMask wallet extension and hardware wallets often use different derivation paths by default. The same recovery phrase combined with different paths generates different addresses. MetaMask typically increments the account level (m/44’/60’/0’/0/0, m/44’/60’/1’/0/0), while some hardware wallets increment the address index (m/44’/60’/0’/0/0, m/44’/60’/0’/0/1). The recovery phrase is correct; the wallet software is looking at different branches of the same key tree.
How do I connect my hardware wallet to MetaMask and see the correct addresses?
When connecting a hardware wallet to a MetaMask wallet extension for the first time, look for an option to select the derivation path or account type. For Ledger, choose “Ledger Live” if your addresses were generated in Ledger Live, or select an alternative if they were generated using a different path. Verify that the addresses shown in MetaMask match those displayed in your hardware wallet software before moving any funds.
What should I do if my funds are on an inaccessible derivation path?
Use the original wallet software or hardware device that generated those addresses to access them and transfer the funds to an address on a path that both your hardware wallet and MetaMask wallet extension can access. This will require paying a network fee but recovers access to your funds. Alternatively, if the original device is unavailable, import the recovery phrase into wallet software that allows custom derivation path configuration, though this should only be done on a secure, offline device using trusted open-source tools.
