A user with funds in MetaMask, Trust Wallet, or Phantom decides to try Rabby as an EVM-focused alternative. The logical first step is to import the recovery phrase—the 12 or 24-word seed that supposedly gives access to all accounts. After pasting the phrase into Rabby and confirming, the user discovers that one or more wallets appear empty. The phrase itself was correct, recognized by the application, and accepted without error. Yet the expected balance does not appear. This scenario is not a bug in Rabby, nor is the recovery phrase compromised. It is a direct consequence of how BIP39 and BIP44 standards work, how different wallets interpret them, and where those interpretations diverge.

Understanding the import process requires distinguishing between three layers that are often conflated: the recovery phrase itself, the derivation path that converts it into account addresses, and the specific network or token contract being checked. A seed phrase is portable in principle, but portability depends on whether the receiving wallet uses the same path to generate addresses from that seed. When Rabby shows a zero balance after importing a phrase that held funds elsewhere, the account exists—it is simply at a different address than the one being checked. The phrase was never the problem. The derivation standard was.

The BIP39 standard creates a master seed from a recovery phrase

A recovery phrase is not the private key itself. It is a human-readable encoding of entropy—randomness—that gets converted into a single master secret through a function called PBKDF2 (Password-Based Key Derivation Function 2). BIP39, the Bitcoin Improvement Proposal that standardizes this conversion, takes the 12 or 24 English words, treats them as a sequence of numbers, and combines them with a user-supplied passphrase (if one exists) to produce a 512-bit master seed.

This master seed is deliberately abstract. It cannot be used directly to sign transactions. Instead, it serves as the root from which all subsequent keys and addresses are derived. If two wallets use the same recovery phrase but apply different derivation methods, they will generate different addresses—and therefore control different accounts. The phrase itself remains identical; the cryptographic path diverges. This is why importing a phrase into a new wallet sometimes reveals different balances or accounts.

The standardization of BIP39 is why phrases created in MetaMask, Phantom, or Trust Wallet can be recognized by Rabby at all. All three use the same word list and the same PBKDF2 function to convert the phrase into a master seed. Without that common foundation, the phrase would be rejected immediately as invalid. Rabby, like most modern wallets, validates the checksum embedded in the phrase—the last word is mathematically dependent on the first 11 or 23—before proceeding. If you paste a corrupted or mistyped phrase, the wallet will not accept it. That acceptance is not a guarantee that the imported accounts will show the same balances elsewhere; it only confirms that the phrase itself is correctly formatted.

The distinction is subtle but crucial. A valid BIP39 phrase is a prerequisite for importing. It is not sufficient to guarantee that balances will match across wallets.

BIP44 defines how wallets derive addresses from the master seed

Once a master seed exists, BIP44—another standardization proposal—defines the path taken to generate addresses. Rather than deriving addresses in a simple sequence, BIP44 introduces a hierarchical structure: purpose, coin type, account, change, and address index. These are expressed as a path such as m/44’/60’/0’/0/0, where each number represents a branching decision. The purpose field (44) indicates that BIP44 is being used. The coin type (60) represents Ethereum. The account number (0) selects which account within that coin type. The change designation (0 for external addresses, 1 for internal change addresses) separates receiving and spending patterns. The final number is the sequential index of the address.

This hierarchical structure serves practical functions. A single master seed can support hundreds of independent accounts, each with its own sequence of addresses, without requiring separate recovery phrases. A user can create a “hot” account for frequent transactions and a “cold” account for storage, both derived from the same phrase but managed separately. This is why a recovery phrase is more powerful than a single private key—it encodes not one account but potentially thousands.

However, BIP44 is only a standard, not a law of physics. Individual wallets can deviate from it. Some wallets use alternative paths. Ledger, for instance, historically used m/44’/60’/0’/0 (note the different structure for account derivation) on certain devices. MetaMask follows the standard path m/44’/60’/0’/0/n, where n increments for each account. Phantom, which began as a Solana wallet, uses m/44’/501’/0’/0’/0′ for Solana but applies m/44’/60’/0’/0/n for Ethereum. Trust Wallet, a multichain wallet by Binance, similarly creates accounts across multiple coin-type paths depending on the network.

Rabby, as an Ethereum-focused wallet, defaults to the standard m/44’/60’/0’/0/n derivation path for Ethereum and EVM networks. This alignment with MetaMask’s path means that importing a MetaMask recovery phrase into Rabby should produce the same addresses. But if the original wallet deviated from the standard, the addresses will not match, and balances will appear missing—even though the phrase, the master seed, and the cryptographic material are all identical.

Why MetaMask imports usually work but others sometimes don’t

MetaMask is one of the most widely used Ethereum wallets and one of the earliest to implement BIP39 and BIP44 correctly for Ethereum. Its path m/44’/60’/0’/0/n is precisely the standard that Rabby uses by default. When a user exports a recovery phrase from MetaMask and imports it into Rabby, the wallets compute the same master seed and follow the same derivation path to reach the same addresses. The funds remain at those addresses on the blockchain regardless of which wallet is used to view them; importing simply points to an existing account rather than creating a new one.

This is why MetaMask to Rabby imports are generally seamless. The addresses match, the balances appear immediately, and the user can send transactions without any intermediate steps. No funds need to move. The recovery phrase acts as a set of keys to the same front door, approached from different applications.

Trust Wallet introduces complications because it is a multichain wallet designed to support dozens of networks, not just Ethereum. When generating accounts for Ethereum, Trust Wallet does use coin type 60 and the path m/44’/60’/0’/0/n. However, Trust Wallet also displays accounts derived from different paths for backward compatibility and for non-Ethereum networks. If a user created an account in Trust Wallet for Ethereum but the wallet showed multiple derived addresses (which Trust Wallet does), the address that held funds might not be the one that Rabby generates when the phrase is imported. This happens because Trust Wallet may prioritize or display addresses differently than the standard path suggests, or the user may have manually created accounts at non-standard indices.

Phantom, which began as a Solana-native wallet and later added Ethereum support, originally applied Solana’s derivation paths to its Ethereum accounts when the feature was first introduced. Users who set up Phantom before Ethereum support was refined may be using m/44’/60’/0’/0’/0′ (note the extra apostrophes, indicating hardened derivation) rather than the standard soft path. When such a phrase is imported into Rabby, which uses the standard soft path, the addresses diverge completely. A user might have significant ETH or token balances at one address in Phantom but see an empty account when viewing the same phrase in Rabby.

Detecting the derivation path mismatch and recovering access

The first diagnostic step is to confirm that the phrase itself is being accepted correctly. If Rabby recognizes the phrase (validates the checksum and does not reject it), the issue is derivation, not the phrase. The second step is to verify the address that is actually holding the funds. Open a blockchain explorer, search for the address shown in the source wallet (MetaMask, Trust Wallet, or Phantom), and confirm that it holds the expected balance on the EVM network in question.

Once the correct address is identified, the user can check whether it appears in Rabby at all. Rabby, like most wallets, displays multiple derived accounts sequentially. By default, it shows the first five accounts; additional accounts can be viewed by scrolling. If the address from the source wallet is not among the displayed accounts, the derivation path is likely different. The solution at this stage is not to treat the import as failed. Rather, the funds are at a known address that exists on the blockchain; they simply are not visible through Rabby’s standard derivation path.

Rabby provides a workaround for this scenario: the ability to manually add an account using a private key or connect via a hardware wallet initialized with the same recovery phrase. However, revealing a private key carries obvious security risks. A safer approach is to check whether Rabby supports alternative derivation paths or whether the source wallet offers an option to export the private key for a specific account. If the source wallet (such as MetaMask) allows exporting the private key for the problematic account, that key can be imported into Rabby separately. This keeps the recovery phrase secure while granting access to the specific funds.

The most straightforward solution, if the funds are not enormous, is to use the source wallet (MetaMask, Trust Wallet, or Phantom) to transfer the balance to a Rabby-controlled address. This requires paying network gas fees but eliminates the derivation path problem entirely. The user then has their funds in an account that Rabby will automatically recognize if the recovery phrase is re-imported in the future. This approach treats the symptom rather than solving the underlying incompatibility, but it is often the most practical path for users who want to migrate away from their original wallet.

Multichain portfolio viewing across EVM networks adds another layer

Rabby supports multiple EVM-compatible networks: Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, and Linea. When a recovery phrase is imported, Rabby derives addresses on each of these networks using the same hierarchical path. A single account number generates a different address on each network—the coin type field determines which network, and the rest of the path specifies which account and address index.

This means that if a user had MetaMask set up to use account 0 on Ethereum but never connected it to Polygon, and then created account 0 in Trust Wallet and used it on Polygon, those two accounts are derived differently. Ethereum on MetaMask might be m/44’/60’/0’/0/0, while Polygon on Trust Wallet might involve a different coin type or path altogether. When importing the Trust Wallet phrase into Rabby, the Polygon account derived at Rabby’s standard path will not match the Trust Wallet Polygon account. The balances will appear on different addresses, and the imported wallet will show an empty Polygon account.

Rabby’s unified portfolio view shows all supported networks in one interface, which is convenient for users who hold assets across multiple chains. However, it also means that a derivation path mismatch is amplified across multiple networks simultaneously. A phrase that imports correctly on Ethereum might show empty accounts on every other network if the source wallet used different standards. This is why checking balances on a block explorer for each network is important after importing. The recovery phrase is not wrong; the path expectations are simply different between wallets.

Why address reuse and manual account creation cause further confusion

Some users create accounts manually within a wallet rather than using the auto-generated sequence. In MetaMask, this is straightforward: click “Create Account” and a new account is added to the list. In Trust Wallet or Phantom, the process may be less visible but functionally similar. When a user manually creates an account, it still follows the BIP44 path—the wallet simply increments the account index (the fourth field in the path). So a manually created second account would be m/44’/60’/1’/0/0 rather than m/44’/60’/0’/0/1.

The issue arises when a user assumes that manually created accounts will re-appear in the same order after importing the phrase into a different wallet. If the source wallet had three accounts (indices 0, 1, and 2) and the funds are in account 2, but the new wallet only shows the first account by default, it appears that the funds are missing. In reality, they are at m/44’/60’/2’/0/0, which is a separate derivation branch. Rabby shows account 0 (m/44’/60’/0’/0/0) by default. The user must specifically request to view account 2 to see the funds.

Address reuse within an account (using the same address repeatedly rather than deriving a new one for each transaction) does not directly affect import behavior but can make debugging harder. If a user received funds at multiple transactions to a single address, and that address is at a non-standard index, the confusion multiplies. The blockchain explorer will show the address and its balance; Rabby might not display it without selecting the correct account index. This is why the recovery phrase is never actually wrong in these scenarios. The phrase is doing exactly what it is supposed to do. The problem is that the derivation path assumptions diverged between wallets.

Best practices for importing and migrating between wallets

Before importing a recovery phrase into Rabby, note the address of every account that holds funds in the source wallet. Use a blockchain explorer to verify the balance and assets at each address. Open Rabby, import the phrase, and check whether each known address appears in the wallet. If some addresses are missing, do not assume the import failed. Instead, check whether Rabby shows additional accounts beyond the default first one. Many wallets limit the visible accounts to the first few for simplicity; additional accounts can typically be added or scrolled to manually.

If an important account remains unreachable even after checking all visible derivation indices, the source wallet may have used a non-standard path. At this point, confirm the path used by the source wallet if possible. Some wallets (such as MetaMask) document their standard path; others may require examining settings or help documentation. If confirmation is not feasible, the safest step is to use the source wallet to transfer funds to a Rabby-derived address, then keep the original wallet as a record until the migration is complete.

When setting up Rabby for the first time, note that creating a new wallet generates a unique recovery phrase that has never existed elsewhere. This phrase will work only in Rabby and wallets using the standard BIP44 path. If you plan to use the phrase in multiple applications, test the import process with a small amount of funds before committing significant balances. Download Rabby from the official Rabby website, verify that the browser extension is authentic, and enable it only in trusted browser profiles.

For accounts that span multiple networks, make a comprehensive list of all networks where each account holds balances before switching wallets. After importing, verify each network explicitly by checking Rabby’s multichain portfolio view and cross-referencing with a block explorer. Network fees apply only when transferring funds; viewing balances does not incur costs. Taking time to verify addresses during import prevents the frustration of discovering that a balance is at an inaccessible derivation path weeks or months later.

Comparing Rabby with MetaMask and other alternatives

Rabby and MetaMask both use the standard BIP44 path for Ethereum, which is why Rabby functions as a MetaMask alternative with superior import compatibility. MetaMask supports more networks overall (including non-EVM blockchains through bridging and wrapped assets), while Rabby focuses exclusively on EVM-compatible chains. For users whose assets are primarily on Ethereum and its Layer 2 networks, this focus reduces clutter and speeds up portfolio checking.

Trust Wallet, as a MetaMask alternative marketed by Binance, intentionally supports multichain assets and uses different coin types for different networks. This flexibility creates the import inconsistencies described above. Trust Wallet is powerful for users managing diverse portfolios across many blockchains, but switching from Trust Wallet to Rabby requires more verification work. Phantom, similarly, began with Solana support and added Ethereum as a secondary feature, which means its address derivation priorities and defaults diverge from Rabby’s Ethereum-first design.

The practical conclusion is that importing works smoothly when the source and destination wallets share the same derivation path for the networks in question. Rabby’s single-minded focus on EVM networks makes it highly compatible with MetaMask phrases but requires deliberate verification when importing from multichain wallets. Knowing the difference prevents the false impression that a recovery phrase has become invalid or that the wallet import process is broken. The phrase and the wallet are both functioning correctly; the paths simply diverged at a specific point in the cryptographic hierarchy.

Security considerations when storing and importing recovery phrases

A recovery phrase grants complete access to all accounts derived from it. Treating import as a test opportunity is reasonable only with small amounts. A phrase known to multiple wallets or computers is a phrase that has multiple potential exposure points. If possible, maintain a primary wallet (such as MetaMask or the original source) and use imports only for specific purposes such as checking balances in a security-conscious browser profile or accessing accounts through a dedicated application.

Rabby, like most wallet extensions, stores the recovery phrase locally in the browser’s secure storage, encrypted by the browser’s own security mechanisms. This is materially safer than pasting the phrase into a web form, but it still depends on the security of the device and browser. A compromised computer, a malicious browser extension, or keylogger malware can access the phrase regardless of which wallet holds it. Importing a phrase is not inherently risky if the destination wallet is legitimate, but it should be treated as a deliberate action rather than a casual experiment.

Testing imports with small amounts on a dedicated device or a separate browser profile (such as a privacy-focused profile in Brave or a sandboxed browser) reduces the risk that a compromise of the test environment will affect the main wallet. If an account shows unexpectedly empty after import, avoid the temptation to enter the phrase into multiple wallets simultaneously to debug the issue. Instead, verify the source wallet’s derivation path through its documentation or settings, or use a single verification method such as connecting a hardware wallet initialized with the phrase.