A user installs MetaMask on both their desktop browser and mobile phone, imports the same Secret Recovery Phrase on both devices, and expects to see identical account balances, transaction histories, and token lists. Instead, they observe a discrepancy: the mobile app shows a different balance than the desktop extension, or one device displays a pending transaction that has already confirmed on the other. The user may conclude that one version is unreliable or that their funds have gone missing. In reality, the difference reflects how MetaMask synchronizes data across devices—or fails to do so completely.
MetaMask is a self-custodial wallet, which means the user controls the Secret Recovery Phrase and private keys, not MetaMask’s servers. This architecture provides security and ownership but also introduces a synchronization challenge: MetaMask instances on different devices do not communicate directly with each other. Each device maintains its own cache of blockchain data, makes its own calls to blockchain nodes, and builds its own view of account state. When those views diverge—due to network latency, node inconsistencies, different RPC endpoints, or stale cached data—the user sees mismatched information across devices.
How MetaMask stores and retrieves account data
When a user imports a Secret Recovery Phrase into MetaMask, they derive the same Ethereum addresses on every device that uses that phrase. The address is deterministic—it is the same on mobile, desktop, and hardware wallets connected through MetaMask. The public key and address do not change. However, MetaMask does not store transaction history, token balances, or NFT data on a centralized server tied to that phrase. Instead, each instance of MetaMask queries blockchain data independently whenever the user opens the wallet or triggers a refresh.
The wallet does this through a process called state synchronization. When MetaMask boots up, it calls an RPC endpoint—a node that provides access to blockchain data—and asks for the current balance of the user’s account, the list of tokens held, recent transactions, and other metadata. The response is cached locally on the device. This cache is not synchronized across devices. If the desktop instance cached data ten minutes ago and the mobile instance caches data now, they will show different states unless both have queried the same state of the blockchain.
MetaMask uses several data sources to build its view of an account. For transaction history, it may query the blockchain directly through the RPC endpoint, use Etherscan’s API for supplemental data, or rely on internal indexing. For token balances, it checks the user’s account for ERC-20 token transfers and nonce values. For NFTs, it may query multiple data providers. Each query can return different results if the queried service is experiencing lag, serving stale data, or temporarily offline. A user refreshing their MetaMask app on mobile at a moment when that API is slow will see older data than a user refreshing on desktop at a moment when that API is fast.
The caching strategy also introduces timing windows. MetaMask caches balances and transaction data to reduce load on blockchain nodes and to improve responsiveness. That cache persists even when the app is closed. If a user opens MetaMask mobile after several hours, it may display cached balances from hours ago. The app typically refreshes this data in the background after opening, but that refresh is asynchronous. A user who glances at the balance immediately after opening may see old data for several seconds before the refresh completes.
Why mobile and desktop see different RPC endpoints
MetaMask users can configure which RPC endpoint the wallet uses to query blockchain data. By default, MetaMask uses Infura as the RPC provider for Ethereum mainnet and other EVM-compatible networks. However, desktop and mobile versions may not be configured identically. A user might have changed the RPC endpoint on desktop to a custom node but never repeated that change on mobile, leaving mobile pointed at Infura’s default endpoint. Alternatively, a user might use different hardware wallets on different devices, each with its own preferred RPC configuration.
The practical consequence is that mobile and desktop are querying different nodes. Those nodes may have slightly different views of the blockchain state. A transaction might have been indexed by the Infura node serving desktop requests but not yet indexed by the custom node serving mobile requests. A token transfer might have propagated to one node’s database but not the other. An account balance might show differently if the nodes are on slightly different block heights or if one is experiencing minor synchronization lag with the rest of the network.
Even when both devices use the same RPC provider, that provider may serve slightly different responses depending on load, geographic latency, or network conditions at the moment of query. Infura and similar services maintain multiple nodes and use load balancing. A user’s desktop might connect to one Infura node while their mobile connects to another. Both are correct representations of the blockchain at the moment of the query, but those moments are different, and the blockchain state is changing continuously as new blocks are mined.
The divergence becomes most obvious when a user submits a transaction on one device and checks the other device before that transaction has been fully indexed across all blockchain data providers. The sending device will show the transaction immediately because MetaMask stores pending transactions in local state. The other device may not show that transaction for several seconds or minutes until it queries a blockchain service that has indexed the transaction.
Transaction history and pending state mismatches
A common complaint is that MetaMask shows a transaction as pending on one device and confirmed on another, or fails to show a transaction at all on one device while it appears on the other. This occurs because transaction state is not synchronized between devices, and the data sources used to populate transaction history are not identical.
When a user approves a transaction in MetaMask, the app creates a pending transaction object and stores it in local state. This object is not sent to any server and is not shared with other devices. It exists only in that device’s MetaMask instance. If the user opens MetaMask on their other device before the transaction is mined and indexed, that device has no knowledge of the pending transaction. It only knows about transactions that appear on the blockchain, which takes time to confirm and index.
Once a transaction is mined, it appears on the blockchain and should be visible to any device querying that blockchain. However, the query might still fail to show it if the queried RPC endpoint has not yet indexed the transaction, if there is a filter or search issue, or if the user is checking a different network than the one where the transaction actually occurred. A user who accidentally switched to Polygon on their mobile while the transaction was sent on Ethereum mainnet would see no record of the transaction, even though it exists on Ethereum.
Etherscan integration also plays a role in transaction visibility. MetaMask uses Etherscan’s API to supplement blockchain data and to display human-readable labels, token prices, and transaction details. If Etherscan has not yet indexed a transaction, it will not appear in MetaMask’s transaction history even though it exists on the blockchain. Different devices querying Etherscan at different times might see different indexing lag. A user checking their mobile in an area with poor network connectivity might timeout before Etherscan responds, while the same query on a desktop with a better connection succeeds and shows the transaction.
Token balance caching and stale data problems
Token balances present a particularly frustrating synchronization issue because they update asynchronously and can display stale values for longer than users expect. When MetaMask displays a balance for an ERC-20 token, it is not querying the live state in real time. Instead, it calls a balance-checking function, caches the result, and displays that cached value until the cache expires or the user manually refreshes.
The cache expiration time is not deterministic from the user’s perspective. It may be based on a timer, a block number, or the app’s lifecycle. If a user checks their token balance on mobile, closes the app, and reopens it thirty seconds later, they might still see the cached balance from before the close. If the user then opens desktop and triggers a fresh query, they might see a different balance because that fresh query has reached a more recent block height.
Token balance queries also depend on whether MetaMask is using blockchain-based balance checks or a caching service like Infura’s token balance endpoint. Different endpoints may return different values if they are out of sync with each other. A user who has recently received a token transfer might see the new balance on desktop but not on mobile if the mobile device cached its last query before the transfer was mined and indexed.
Custom tokens add another layer of complexity. If a user adds a custom ERC-20 token on desktop but not on mobile, the mobile app will not display that token’s balance at all, even though the account holds that token on the blockchain. The token exists on the blockchain, but MetaMask mobile has no instruction to display it because the custom token was never added to the mobile wallet’s token list. This creates the illusion that the mobile balance is lower than the desktop balance, when in reality both devices have access to the same funds—the mobile version simply is not displaying one of the tokens.
Network selection and multi-chain synchronization gaps
MetaMask now supports multiple EVM-compatible networks: Ethereum mainnet, Polygon, Arbitrum, Optimism, base, and others. A user might have configured their desktop to actively use and display accounts on Polygon, while the mobile setup remains focused on Ethereum mainnet. When the user switches between devices, they see balances for different networks, creating the impression of missing funds.
The problem intensifies when a user has funds on a network that they configured on desktop but not on mobile. If someone receives USDC on Polygon through a desktop transaction, the balance will show on desktop’s Polygon view. The mobile app, if not configured to show Polygon accounts, will appear to have no USDC balance at all. The funds exist on the Polygon blockchain, but the mobile interface is not displaying them because Polygon is not part of the mobile MetaMask’s active network list.
Bridges between networks also create synchronization confusion. When a user bridges tokens from Ethereum to Polygon on one device, that device shows the source balance decreasing and the destination balance increasing. However, if the user then switches to their other device before the bridge has fully completed, they might see the tokens still on the source network and not yet on the destination. This is not a synchronization failure between MetaMask instances; it is the expected behavior of slow or in-flight cross-chain transactions. However, users often misinterpret it as data loss.
To access a MetaMask crypto wallet on mobile or desktop, users can download from official sources and import their Secret Recovery Phrase. However, adding custom networks to one device requires manually repeating that configuration on the other device. There is no automatic synchronization of network settings or custom RPC endpoints across devices.
Hardware wallet and hardware security module integration
Users who connect a hardware wallet such as a Ledger or Trezor to MetaMask introduce another variable into the synchronization equation. A hardware wallet stores the Secret Recovery Phrase and manages key signing on the device itself, not in MetaMask. MetaMask acts as an interface to that hardware wallet. When a user connects the same hardware wallet to MetaMask on both desktop and mobile, they derive the same addresses because the hardware wallet is the source of truth for the keys.
However, the cache and transaction history are still local to each MetaMask instance. The hardware wallet ensures that the addresses are the same, but MetaMask’s view of that account’s balance and transaction history remains independent on each device. A user with a Ledger connected to both desktop and mobile MetaMask will see the same addresses but potentially different cached balances and transaction lists.
The hardware wallet itself does not synchronize state across devices. It is an offline device that signs transactions. MetaMask queries the blockchain, caches the results, and displays them. If the hardware wallet is connected to desktop via USB and to mobile via Bluetooth, the connection method, data provider, and synchronization timing can all differ. The user should expect that checking the account balance directly on the hardware wallet device (if possible) will show the authoritative balance, while MetaMask on either device may show cached or stale data.
Forced synchronization and refresh strategies
MetaMask does not offer an explicit “sync across devices” button because the wallet is not designed for server-mediated synchronization. However, users can force a refresh of cached data on each device independently. The most reliable method is to clear the cached data on the device showing stale information, then manually refresh the account view.
On mobile, users can try the following steps: open MetaMask, navigate to Settings, select “Advanced,” and look for cache or data refresh options. The exact menu structure varies between iOS and Android versions. On desktop, opening the wallet and waiting for the automatic background refresh usually works. If cached data persists, users can click the wallet icon, select “Settings,” navigate to “Advanced,” and clear cache or reset the app data. After clearing cache, the wallet will rebuild its view of the account state on the next opening.
A more radical but effective approach is to manually trigger a balance refresh by switching networks and switching back. If a user is on Ethereum mainnet and sees a stale balance, switching to Polygon and then back to Ethereum mainnet forces MetaMask to query the blockchain data again for Ethereum. This flushes the cache and rebuilds the balance display with fresh data. Similarly, disconnecting and reconnecting to a hardware wallet forces re-synchronization of the address list and prompts a fresh query for balances.
Users can also verify the true blockchain state by querying the account address directly on Etherscan or another block explorer, using the same network that MetaMask is displaying. If Etherscan shows a different balance than MetaMask, the blockchain is the source of truth, and MetaMask’s cache is simply stale. In this case, waiting a few minutes or manually refreshing MetaMask should resolve the discrepancy. If Etherscan and MetaMask agree but desktop and mobile disagree, the synchronization lag is local to one device’s cache.
Best practices for managing multi-device MetaMask wallets
Users who regularly use MetaMask on both mobile and desktop should adopt habits that reduce synchronization confusion. First, avoid approving critical transactions on one device without opening the other device to verify the balance and confirm the transaction was mined. A user who sends tokens on mobile and then immediately opens desktop might see the old balance, leading them to mistakenly believe the transaction failed. Waiting thirty seconds to a minute and manually refreshing on desktop will typically show the new state.
Second, ensure that both devices are configured with the same RPC endpoints and custom networks. If a user has added a custom network or changed the RPC provider on desktop, repeat that configuration on mobile. This ensures both devices query the same data source and reduces the likelihood of divergent cached states. MetaMask does not synchronize these settings automatically, so the user must manually apply them to each device.
Third, keep custom token lists synchronized. If a user adds a custom ERC-20 token to display on desktop, add the same token to mobile using the token’s contract address. This prevents the confusion of seeing a token balance on one device and not the other due to one device simply not being configured to display that token.
Fourth, for high-value accounts or security-sensitive transactions, use a hardware wallet connected to MetaMask on all devices. The hardware wallet is the source of truth for the account and keys, and it removes the possibility of losing funds due to device-level confusion. The balance display might still be cached on one device, but the user knows they cannot accidentally spend funds they do not actually own.
Fifth, before moving significant amounts of cryptocurrency, verify the balance on a block explorer rather than relying solely on MetaMask’s display. Etherscan or a similar service queries the blockchain directly and is not subject to MetaMask’s caching layer. If the block explorer shows the same balance as MetaMask, the balance is accurate. If they differ, the blockchain value is correct and MetaMask’s cache should be cleared and refreshed.
Frequently asked questions
Why does my MetaMask mobile app show a different balance than the desktop version?
MetaMask instances on different devices maintain separate caches of blockchain data and query data independently through different RPC endpoints or at different times. The blockchain state is constantly changing, so a query on mobile and a query on desktop may return different results if they occur moments apart. Additionally, custom tokens added on one device are not automatically added to the other, causing the mobile balance to appear lower if tokens are hidden. Clear the mobile app’s cache, manually refresh by switching networks and switching back, and verify that both devices have the same custom tokens configured.
How long does it take for a transaction to appear on both my MetaMask mobile and desktop?
A pending transaction appears immediately on the device where you approved it but may not appear on other devices until the transaction is mined and indexed by blockchain data providers. This typically takes 15 seconds to several minutes depending on network congestion and the indexing speed of services like Etherscan. Manually refresh the other device by switching networks or restarting the app to see the updated transaction history. Do not repeat the transaction if it does not immediately appear on the other device.
Can I synchronize my MetaMask settings, custom networks, and token lists across devices automatically?
No. MetaMask is self-custodial and does not sync application settings across devices. Custom networks, RPC endpoints, and custom token lists must be manually configured on each device. If you add a custom network on desktop, you must repeat that configuration on mobile by entering the RPC URL, network ID, and other details. For high-value accounts, use a hardware wallet connected to MetaMask on all devices to ensure the account and addresses are consistent, even though the cached balance display may still differ between devices.
