A user imports a seed phrase into Rabby Wallet and discovers that expected balances do not appear. The wallet shows zero in accounts that held substantial assets in MetaMask or Trust Wallet. The funds are not lost—they exist on the blockchain—but the imported wallet is not displaying them. The user has encountered a derivation path mismatch, one of the most persistent problems in non-custodial wallet management. Rabby Wallet, like all Ethereum and EVM-compatible wallet software, must choose which account addresses to generate from a single seed phrase, and that choice is not automatic or universal.
Derivation paths are the mathematical instructions that determine which specific addresses a wallet displays when given a recovery seed. Two wallets using the same seed phrase but different derivation paths will generate completely different addresses. This is not a bug in Rabby Wallet or a security failure; it is the direct consequence of how BIP32 and BIP44 standards work. However, because many wallet providers use non-standard or customized derivation paths, understanding the mechanics becomes essential for anyone managing assets across multiple wallet applications or recovering wallets after device loss.
The BIP44 standard and why Rabby Wallet uses it
BIP44 (Bitcoin Improvement Proposal 44) defines a hierarchical deterministic (HD) derivation structure. From a single seed phrase, a wallet can generate theoretically unlimited child keys following a precise mathematical path. The standard format is: m / purpose / coin_type / account / change / address_index. The master key begins with “m”. The purpose field is typically 44 for BIP44 wallets. The coin_type field identifies the blockchain—Ethereum uses coin type 60. The account field allows multiple independent accounts from one seed. The change field distinguishes between receiving addresses (0) and change addresses (1). The address_index specifies which particular address within that derivation line.
Rabby Wallet setup follows the BIP44 standard for Ethereum with the path m/44'/60'/0'/0/n, where n represents sequential address indices. This means Rabby derives accounts on the Ethereum mainnet from the same seed using a consistent, predictable formula. When you import a recovery phrase into Rabby, it scans the blockchain using this specific path and displays any addresses with non-zero balances or transaction history. The derivation is deterministic: the same seed always produces the same addresses in the same order.
However, BIP44 is a standard, not a law. Wallet developers can and do implement variations. MetaMask, by default, uses the same BIP44 path for Ethereum that Rabby does, but it also supports adding custom accounts that may derive from different paths. Trust Wallet, Ledger Live, Coinbase Wallet, and other providers sometimes use identical paths for Ethereum, sometimes diverge slightly, and sometimes implement entirely custom derivation schemes. The blockchain network itself does not care which path was used to generate an address—all valid Ethereum addresses are treated equally. The problem arises only when a user tries to recover or import a wallet and the software cannot find their funds because it is looking in a different derivation location.
Why importing from other wallets sometimes fails
The most common failure point is a path mismatch between the source wallet and Rabby Wallet. If a user created a wallet in Trust Wallet using a non-standard derivation path, exported the seed phrase, and imported it into Rabby expecting to see the same accounts, Rabby will generate addresses that do not match the ones that actually hold the funds. Rabby cannot know that the user intended a different derivation path; it can only apply its default standard path.
A concrete example illustrates the problem. A user creates a wallet in a privacy-focused wallet client that uses the path m/44'/60'/0'/0/0 for their first account. This generates address 0x123abc… holding 10 ETH. They export the seed phrase, import it into Rabby Wallet, and Rabby also looks at address m/44'/60'/0'/0/0. By coincidence, both wallets use the same BIP44 path, so the import works seamlessly. But if that original wallet instead used a custom path like m/44'/60'/1'/0/0 (account 1 instead of account 0), Rabby would generate a different address—0x456def…—which has zero balance. The user would see no funds in Rabby despite owning the seed phrase that could unlock them.
Another failure mode involves hardware wallets and account number shifts. Ledger devices, for example, use standard BIP44 derivation but may number accounts differently depending on which Ledger application or firmware version was used. A user who created multiple accounts on a Ledger device via Ledger Live, then connected the same Ledger to Rabby, might find that Rabby displays the accounts in a different order or skips accounts that Ledger Live showed. This is because the wallet applications count and index accounts differently, even though they both have access to the same underlying key material.
The role of key derivation formats: uncompressed, compressed, and address encoding
The derivation path determines the private key itself, but the address generated from that key can vary depending on how the key is formatted and encoded. Ethereum, unlike Bitcoin, uses uncompressed public keys directly—it takes the Keccak-256 hash of the uncompressed public key and uses the last 20 bytes as the address. This process is deterministic: the same private key always produces the same Ethereum address. However, other blockchains and older wallet implementations sometimes use compressed public keys or different hashing schemes, which can produce different addresses even when the underlying private key is identical.
Rabby Wallet, as an EVM-focused wallet, consistently uses the Ethereum address derivation method for all Ethereum and EVM-compatible chains. This means that a private key imported into Rabby will generate the same address on Ethereum mainnet, Polygon, Arbitrum, Optimism, and other EVM chains. However, if a user previously imported the same seed into a wallet that uses a different public key format or hash method, the addresses will not match. This is rare for mainstream EVM wallets but can occur when migrating from non-EVM blockchains (such as Bitcoin or Cosmos) or from legacy wallet software.
Address checksums and capitalization also matter for verification but not for wallet derivation. An Ethereum address is functionally identical whether written as 0x123abc… or 0x123ABC…, but the checksum (determined by hashing the address and comparing bit patterns) will differ. Rabby displays checksummed addresses by default, which is a best practice because it allows users to catch typing errors. When comparing addresses across wallets, always verify the checksummed version or convert both to lowercase for comparison to avoid false mismatches.
Custom derivation paths and account discovery in Rabby
Rabby Wallet does not currently expose a user interface for manually specifying a custom derivation path. The wallet derives accounts using the standard BIP44 path and displays all addresses with non-zero balances or transaction history. This is a deliberate design choice: it prevents less technical users from accidentally deriving empty accounts and assuming their funds are lost. However, it also means that if a user’s funds are stored at a non-standard path, Rabby will not automatically discover them.
The practical recovery path depends on how the original wallet was created. If the original wallet is still available on the user’s device, the simplest approach is to keep using both wallets in parallel rather than attempting a migration. If the original wallet is no longer installed or accessible, the user needs to identify the exact derivation path used. This information is rarely documented in wallet applications; most users do not know which path their wallet used unless they explicitly specified it at creation time. Some wallet communities and documentation resources, such as on this site, maintain lists of common wallet derivation paths by provider.
For users with hardware wallets, the recovery process is slightly more controlled. A Ledger device stores no assumptions about derivation paths; instead, the connected wallet application (such as Ledger Live, MetaMask, Rabby, or others) requests keys at the path of its choosing. Connecting a Ledger to different wallet applications will generate the same addresses from the same account number because hardware wallets are stateless key-generation devices. The issue arises only if the user has manually created accounts with non-sequential indices, in which case a new application may not discover all accounts without explicit account enumeration.
Why recovery and password reset are impossible for non-custodial wallets
Rabby Wallet is a non-custodial wallet, which means the provider has no access to user private keys, recovery phrases, or passwords. This architecture is a strength for security—Rabby cannot be hacked to steal keys—but it creates an inflexible recovery boundary. If a user forgets their Rabby password, Rabby cannot reset it because no central service stores that password. If a user loses their recovery phrase, Rabby cannot retrieve it because it never leaves the user’s device. If a user imports a seed phrase and discovers they used the wrong derivation path, Rabby cannot automatically search for funds at non-standard paths because the wallet has no authority to redefine how derivation works.
This constraint is not unique to Rabby; it applies to all self-custody wallets. MetaMask, Trust Wallet, and hardware wallets all operate under the same principle: the user is the sole custodian of the keys, and recovery requires either the original recovery phrase or access to the original device. For Rabby Wallet setup, this means users must treat the recovery phrase and device backup as the single source of truth. There is no “forgot password” link, no account recovery email, and no customer service recovery option. The user’s responsibility for security is absolute.
The implication for derivation path issues is that users must plan for recovery before loss occurs. If you use Rabby with a standard Ethereum wallet seed and never manually specify non-standard paths, import into Rabby should be straightforward on any device. However, if you have managed complex multi-path accounts in other wallets, you should document which paths hold which assets before losing access to the original wallet. Keep that documentation separate from the recovery phrase—a written note in a safe deposit box noting “Trust Wallet account 2: m/44’/60’/2’/0/0” is invaluable if you later need to recover those specific funds.
Practical steps to verify derivation and prevent account loss
Before importing a seed phrase into Rabby, export a list of addresses from the source wallet. Open Rabby, import the seed, and compare the first few generated addresses against the source list. If they match, the derivation paths are compatible and the import is safe. If they do not match, do not proceed with deleting or replacing the original wallet; instead, keep both wallets installed and use Rabby only for compatible accounts.
For users managing hardware wallets with Rabby, the standard BIP44 path will typically work, but verify by looking at a few account details. Connect your hardware wallet to Rabby and confirm that the displayed accounts match the accounts shown when the hardware wallet is connected to the manufacturer’s application (Ledger Live for Ledger, for example). If the account numbers or addresses differ, document which wallet application uses which numbering scheme and maintain a mapping to prevent confusion during future transactions.
When creating a new wallet in Rabby, record the recovery phrase in a secure offline location immediately. Do not screenshot it, email it, or type it into notes applications connected to the cloud. Write it by hand or use an encrypted password manager specifically designed for offline key storage. The recovery phrase is the decryption key to every account Rabby can ever derive from that seed; anyone with the phrase can access all addresses, current and future. The device where Rabby is installed is also critical: if the device is lost or compromised, an attacker can potentially access all accounts without the recovery phrase if no password protects the wallet. Rabby allows setting a password to unlock the wallet on the current device, which is a valuable second factor if the device itself is compromised.
Derivation paths across different EVM chains and why they matter less on Ethereum
One reason Rabby’s standard BIP44 derivation works well is that Ethereum and EVM-compatible chains share identical address generation. The same private key at the same derivation path will produce the same address on Ethereum mainnet, Polygon, Arbitrum, Optimism, Base, and dozens of other EVM networks. This means a user who imports a seed into Rabby gets access to the same accounts across all supported EVM chains without any additional derivation configuration. The blockchain itself is specified by the RPC endpoint Rabby uses to query balances, not by the account derivation path.
This design simplifies the user experience but creates a subtle trap. A user might assume that because the addresses are the same, the security and privacy properties are identical across chains. They are not. A transaction on Ethereum mainnet is immutable and public on one of the most-watched blockchains in the world. The same transaction broadcast on a smaller EVM chain might have different cost assumptions, different consensus guarantees, and different levels of indexing by major block explorers. Similarly, a low-liquidity token on a secondary EVM chain might be subject to different risks than the same token on Ethereum.
For users managing cross-chain assets via Rabby, the derivation path consistency is convenient but should not override careful transaction verification. Rabby’s transaction analysis feature displays potential balance changes before signing, which is valuable across all chains. However, a high slippage warning on a secondary chain might indicate insufficient liquidity rather than a malicious transaction, and the user should verify the actual swap terms and counterparties rather than assuming that Rabby’s analysis covers all context-specific risks.
When to use account indices versus creating separate wallets
BIP44 allows unlimited sequential accounts using the same seed phrase. In Rabby, this is implemented via the account index (the second-to-last level in the derivation path). A user can generate account 0, account 1, account 2, and so forth, each deriving completely different addresses but all backed by the same recovery phrase. Rabby displays the default account (account 0) and allows adding additional accounts through the interface. This is useful for separating funds by purpose, counterparty, or risk profile while maintaining a single recovery phrase.
However, there is a practical limit to account discovery. Rabby scans sequentially through account indices looking for non-zero balances or transaction history. If a user creates account 3 but leaves accounts 1 and 2 empty, Rabby might stop scanning before discovering account 3, depending on the wallet’s discovery heuristic. Users should explicitly note which account indices they have used. Some wallets and recovery utilities scan up to a fixed limit (often 20 or 100 accounts) to balance thoroughness against performance; Rabby’s specific behavior on import is worth testing before relying on it for recovery.
An alternative approach for certain use cases is to create entirely separate wallets, each with its own recovery phrase. This increases backup and recovery complexity—multiple phrases to store and protect—but it also provides stronger isolation. If one wallet is compromised, the attacker has access only to that wallet’s assets, not the entire account hierarchy. For users managing substantial assets or operating in high-security contexts, maintaining multiple independent wallets is a defensible strategy despite the added complexity.
Frequently asked questions
Why does Rabby Wallet not show my assets after importing my seed phrase?
The most likely cause is a derivation path mismatch. If your original wallet used a non-standard BIP44 path, Rabby’s standard path will generate different addresses. Verify by exporting the first few addresses from your original wallet and comparing them to the addresses Rabby displays. If they differ, your funds are stored at a non-standard path that Rabby cannot access without manual configuration. Keep both wallets installed rather than assuming the funds are lost.
Can Rabby Wallet support custom derivation paths if my wallet used a non-standard one?
Rabby does not currently expose a user interface to specify custom derivation paths. The wallet derives accounts using the standard BIP44 format and discovers accounts with non-zero balances automatically. If your original wallet used a custom path, you will need to either continue using that original wallet or consult advanced recovery tools designed to scan multiple paths simultaneously. Document any non-standard paths you use before losing access to the original wallet.
If I use the same seed phrase in Rabby and MetaMask, will I see the same accounts?
Probably yes, for Ethereum and EVM chains, because both wallets use the standard BIP44 derivation path m/44’/60’/0’/0/n by default. However, if either wallet has custom accounts or you have modified account paths, the addresses may differ. Always verify by comparing the first few generated addresses before trusting an import. If addresses match, you can access the same accounts from either wallet.
