Restored the Seed Phrase but Got a Different Address? Match the Derivation Fingerprint

If a wallet accepts your seed phrase but shows a different address, do not assume the funds disappeared and do not enter the phrase into an online derivation tool. A seed phrase can derive many accounts and addresses, and the result also depends on details such as an optional passphrase, derivation path, account index and blockchain. First find one public address that you know belonged to the original wallet. Your recovery is proven when the restored setup reproduces that address—not when an app merely says the seed phrase was accepted.

The address is a better recovery check than the balance

Start with a public address you know belonged to the wallet before recovery. Find it in an old transaction, a withdrawal record, a verified address book or a blockchain explorer record you already trust. A wallet balance can be hidden by an unsupported network, missing token or incomplete account discovery; reproducing the exact historical address is stronger evidence that you have reached the correct key branch.

Use the Address Derivation Fingerprint

The expected address appears only when the relevant recovery coordinates match.

• Recovery root — the exact seed or wallet backup that created the original keys
• Optional passphrase — the exact additional passphrase, if one was used
• Account source — derived from this phrase, imported by private key/JSON, or connected from another hardware wallet
• Derivation path — the key-tree branch the original wallet used
• Account and address index — which account or child address held the funds
• Network and address type — for example Ethereum account, Solana account, Bitcoin legacy, SegWit or Taproot

Verdict zero — if the old address actually matches, stop diagnosing derivation

If the restored wallet can reproduce the same historical address but the balance or token is missing, the recovery root is probably not the main problem. Switch to network, token-display, RPC or synchronization troubleshooting. ELLIPAL's current recovery guidance makes the same distinction: an address match points away from an address-derivation mismatch.

Fingerprint 1 — confirm that this is the correct recovery phrase

A phrase can be syntactically accepted and still belong to another wallet. Users often have multiple backups from old devices, test wallets or separate accounts. Phantom's current recovery guidance says unfamiliar accounts after import can mean the recovery phrase is different, and Ledger says a zero-balance account with no expected history often indicates the device contains a different Secret Recovery Phrase.

Do not prove the phrase by typing it into a website

Use the legitimate restore flow of the original wallet or a trusted hardware device. Never paste a live seed phrase into a browser-based address generator, support chat, search result or 'recovery checker'. Public addresses are safe to compare; the recovery phrase is the secret that can authorize the wallet.

A checksum error and a wrong valid wallet are different states

Some wallet software can reject a phrase because its words, order or format do not satisfy the expected mnemonic rules. A different but valid recovery phrase can instead open normally and derive a completely different wallet. 'The app accepted the words' therefore proves format compatibility, not that you restored the wallet that held the old address.

Fingerprint 2 — ask whether an optional passphrase was used

An optional BIP39-style passphrase changes the wallet derived from the recovery backup. Trezor documents that every unique passphrase creates a unique hidden wallet with unique addresses, and the exact same backup plus exact same passphrase is required to reproduce the same wallet.

A one-character passphrase difference creates another valid wallet

Trezor warns that passphrases are case-sensitive and that spaces and punctuation matter. A typo does not necessarily produce an error; it can create another empty-looking hidden wallet. If you previously used a passphrase, test only plausible versions you actually used rather than inventing endless guesses.

Ledger passphrase accounts also remain separate from standard accounts

Ledger's current missing-account guidance says passphrase-protected accounts do not reappear merely by restoring the standard 24-word Secret Recovery Phrase. The passphrase must be configured again exactly as before to regain the separate account set.

Do not confuse a wallet PIN or app password with the seed passphrase

A device PIN or application password protects local access. A seed passphrase changes the derived cryptographic wallet. Entering an old PIN where a wallet asks for an optional passphrase can therefore derive an entirely different address set instead of unlocking the original one.

Fingerprint 3 — determine whether the missing account was derived from the phrase at all

A wallet application can contain accounts from several credential sources. MetaMask and Phantom both document that accounts imported separately with private keys or connected hardware wallets do not necessarily return when only the main recovery phrase is restored. The phrase cannot regenerate an account that was never derived from it.

MetaMask imported accounts are a common false recovery failure

MetaMask currently says accounts originally imported by private key or JSON file, and hardware-wallet accounts using other recovery material, must be re-added separately. If the missing historical address was one of those accounts, repeatedly restoring the MetaMask Secret Recovery Phrase will never derive it.

Phantom can also contain accounts from several independent sources

Phantom's current account model includes accounts derived from the main recovery phrase, accounts from another imported recovery phrase, imported private keys, connected Ledger accounts and watch-only accounts. Each source has its own backup requirement. Identify which source created the historical address.

A watch-only account proves visibility, not signing authority

If an old address was added only as watch-only, restoring the wallet's main phrase cannot create spending authority for it. A watch-only entry can display balances and history without containing the private key. Recovery requires the credential source that actually controls that address.

Fingerprint 4 — re-add later accounts before changing derivation paths

Many wallet restores initially show only a subset of accounts. Before assuming a technical path mismatch, recreate the derived accounts in their original order using the wallet's documented account-add flow. This is especially important when the funded address was not Account 1.

MetaMask account indexes are deterministic

MetaMask says derived accounts can be manually re-added after a Secret Recovery Phrase restore. Account 4 before the restore corresponds to Account 4 after the restore, even if its custom name was not preserved. The address remains deterministic; the interface may simply not have recreated that account yet.

Phantom may not automatically show every unused or inactive account

Phantom's July 2026 recovery guide says it restores accounts with on-chain activity from oldest to newest, while accounts without balance or transaction history may not appear automatically. Add missing accounts through the official interface before concluding that the seed generated the wrong wallet.

Use the known address as the account-index stopping rule

Do not create hundreds of accounts blindly. Add accounts in the sequence documented by the original wallet and compare each generated public address with the historical address. When the address matches, the account-index problem is solved. If the expected range is exhausted, move to derivation-path or credential-source checks.

Fingerprint 5 — compare the derivation path

Hierarchical deterministic wallets can derive many branches from one root. BIP44 defines a structure such as m / purpose' / coin_type' / account' / change / address_index. If two wallet applications choose different branches, the same recovery seed can lead their interfaces to different addresses.

Cross-wallet restoration is where derivation-path differences become visible

Restoring a phrase in the wallet that originally created it is the cleanest diagnostic baseline. If the expected address appears there but not in a different app, the phrase is likely correct and interoperability is the problem. Phantom explicitly tells users with missing accounts to try the original app; if the address appears there but not in Phantom, an unsupported derivation path may be responsible.

MetaMask does not scan every possible Ethereum derivation path

MetaMask currently says imported seed phrases use its default BIP44 Ethereum path m/44'/60'/0'/0. Its Ledger connection offers specific Ledger-related path choices, but arbitrary seed imports do not search every historical wallet convention. A correct phrase from another wallet can therefore require the original application's path behavior.

Phantom documents several active and legacy path families

Phantom's June 2026 documentation lists current bip44Change, alternate bip44 and deprecated derivation groupings for recovery-phrase and Ledger accounts. It explicitly says addresses that do not match another wallet are often a derivation-path issue. This makes Phantom a useful example of why 'same seed' does not mean every wallet app scans the same branches.

Bitcoin address type is part of the path problem

Bitcoin HD wallets can derive different address families under different standards. Trezor's standards documentation describes BIP44 for legacy-style accounts, BIP49 for wrapped SegWit and BIP84 for native SegWit, each using a different purpose branch. If the original wallet used another address type, a restore that scans only one family can show different addresses.

A Bitcoin address prefix is useful evidence, not sufficient recovery data

An old address beginning with 1, 3, bc1q or bc1p can help identify the likely address family, but do not derive private keys manually from that clue. Use the original wallet's supported account types or documented recovery interface and compare the resulting public address.

Fingerprint 6 — verify the network you are actually viewing

The same recovery root can produce addresses for many blockchains. Trezor lists a disabled or missing network as one cause of apparently missing crypto, and Phantom derives separate Solana, EVM and Bitcoin addresses from the same recovery phrase. Comparing a Solana address with an Ethereum address is not a recovery test.

EVM networks can reuse one account address without sharing balances

Ethereum, Base, Polygon and other EVM-compatible networks can display the same account address while keeping separate network state. If the expected 0x address matches but the asset does not appear, verify the network and token before changing the seed or derivation path.

Solana and EVM addresses from one Phantom wallet are supposed to differ

Phantom currently groups accounts by index across networks but derives Solana and EVM addresses using different paths and address formats. A different Solana address than Ethereum is normal. The correct comparison is old Solana to restored Solana, or old Ethereum to restored Ethereum, at the same intended account source and index.

Do not move funds to the new-looking address until recovery is proven

An unfamiliar restored address can be perfectly valid but belong to the wrong seed, passphrase, path or account. Sending new funds there complicates the investigation and may mix two wallets. First reproduce the historical address or establish exactly why it cannot be derived from the current recovery material.

Do not overwrite or wipe the last device that still shows the original wallet

If an old phone, browser profile or hardware device can still display the expected address, preserve it while diagnosing the backup. Record public addresses and account names, and identify imported or hardware accounts. Do not expose the seed phrase merely to make a screenshot. The surviving device is valuable evidence about the original account structure.

Do not export private keys unless the official recovery path genuinely requires it

A private key can restore one account but exposes direct spending authority. Prefer re-adding accounts or using the original wallet's supported recovery method. Phantom notes that private-key import can help when a derivation path is unsupported, but that is an advanced migration step and the private key should only be handled in trusted software.

A safe recovery worksheet uses public data

You can diagnose most mismatches without recording the secret words.

• Original wallet application or hardware wallet
• Known historical public address
• Blockchain and asset
• Address type or prefix when relevant
• Approximate account number or label
• Whether a passphrase/hidden wallet was used
• Whether the account was created normally, imported by private key/JSON, or connected from hardware
• Original and restored wallet software versions where relevant
• Known derivation-path family only if documented by the wallet
• Whether the expected address appears in the original app

Never put the seed phrase into that worksheet

The seed phrase, passphrase and private keys should not appear in screenshots, notes sent to support, forum posts or diagnostic spreadsheets. Support can reason from the public address, wallet type, path information and account history. Anyone who asks you to paste the seed into a website to 'scan all paths' is asking for full wallet authority.

Use six final recovery verdicts

Finish with the first verdict supported by evidence.

• ADDRESS MATCHES — derivation is correct; troubleshoot network, token display, RPC or balance sync instead.
• ACCOUNT NOT RE-ADDED — the correct phrase is restored, but the funded account index is not visible yet.
• SEPARATE ACCOUNT SOURCE — the historical address came from an imported key, another phrase or hardware wallet and cannot be recreated by this seed.
• PASSPHRASE MISMATCH — the same seed with the wrong or missing optional passphrase derives a different wallet.
• DERIVATION / ADDRESS-TYPE MISMATCH — the original app used a branch the restored app is not currently scanning.
• WRONG RECOVERY ROOT — the expected address cannot be reproduced in the original wallet with the expected account structure; re-check which backup actually created it.

The safest diagnostic order

Use this order to minimize unnecessary secret handling.

• 1. Obtain one trusted historical public address.
• 2. Compare the address on the correct blockchain, not just the displayed balance.
• 3. Restore or inspect the wallet using the original application's official method when possible.
• 4. Confirm whether an optional passphrase or hidden wallet existed.
• 5. Re-add derived accounts in their original order.
• 6. Identify separately imported private-key, JSON or hardware-wallet accounts.
• 7. Compare documented derivation paths and Bitcoin address types only after simpler causes are excluded.
• 8. Verify the correct network and token display.
• 9. Resume normal use only after the historical address is reproduced or the separate credential source is identified.

Why this page is separate from seed-phrase safety

Seed-phrase safety asks how to store and protect the recovery secret. This page assumes a user is already performing a legitimate restoration and the resulting address does not match. Its result is a derivation diagnosis—account index, passphrase, path, network or separate account source—not a general backup tutorial.

Why this page is separate from 'wallet address changed'

A wallet can intentionally rotate receiving addresses, especially on Bitcoin-style wallets, while still controlling the old ones. This page addresses a different symptom: after recovery, the expected historical address cannot be reproduced. The question is whether the same cryptographic wallet was restored, not whether an old receiving address remains reusable.

What can change after August 8, 2026

Wallet discovery rules, supported derivation paths, social-login recovery and automatic account restoration can change. The durable evidence is deterministic: use a known public address as the target and reproduce it from the same recovery root, passphrase, derivation branch and account source. Recheck the original wallet's current documentation before forcing a cross-wallet import.

Sources checked on August 8, 2026

Primary wallet and standards documentation was prioritized. The exact-query SERP also contains current wallet-specific recovery pages, but the procedure below relies on official implementations and specifications.

• MetaMask — Add missing accounts after restoring with Secret Recovery Phrase — https://support.metamask.io/configure/accounts/how-to-add-missing-accounts-after-restoring-with-secret-recovery-phrase/
• MetaMask — Import a seed phrase from another wallet / derivation paths — https://support.metamask.io/configure/wallet/importing-a-seed-phrase-from-another-wallet-software-derivation-path/
• Phantom — Recover missing wallets and fix import issues — https://help.phantom.com/hc/en-us/articles/4407240978195-Recover-missing-wallets-and-fix-import-issues
• Phantom — Supported derivation paths — https://help.phantom.com/hc/en-us/articles/12988493966227-Supported-derivation-paths-in-Phantom
• Phantom — Understanding wallets, accounts, and addresses — https://help.phantom.com/hc/en-us/articles/45465816962579-Understanding-wallets-accounts-and-addresses-in-Phantom
• Trezor — I don't see my crypto — https://trezor.io/support/troubleshooting/trezor-suite-issues/i-don-t-see-my-crypto
• Trezor — Passphrase & hidden wallets issues — https://trezor.io/support/troubleshooting/trezor-suite-issues/passphrase-hidden-wallets-issues
• Trezor — What is BIP44? — https://trezor.io/learn/advanced/standards-proposals/what-is-bip44
• Ledger — I can't find my accounts in Ledger Wallet — https://support.ledger.com/article/4413620680721-zd
• Bitcoin BIPs — BIP44 Multi-Account Hierarchy — https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
• ELLIPAL — Why Are My Addresses Different After Recovering with a Seed Phrase? — https://support.ellipal.com/docs/troubleshooting-and-support/loss-security-and-support/why-are-my-addresses-different-after-recovering-with-a-seed-phrase

FAQ