[Bug]: Critical - Provider data stale/bad when connected network differs from activity filter network

[johnnyshankman]

Describe the bug

MetaMask's provider behaves as if the blockchain is frozen at a specific block number when the network connected to the website differs from the network selected in the activity filter dropdown. The eth_blockNumber RPC method returns a static block number that never advances, and all blockchain data remains stale as though no new blocks are being produced.

This occurs regardless of which networks are involved (L1 or L2) and which RPCs they rely on. For example:

• Connecting a website to Ethereum mainnet, then changing the activity filter to Optimism causes the issue on mainnet
• Connecting a website to an L2 like Optimism, then changing the activity filter to any other network causes the issue on that L2

This causes severe issues where all provider information is outdated, and increases the risk of unknowingly submitting bad transactions that will revert due to stale data. Also increases the likelihood of displaying incorrect information on the page.

Expected behavior

The network selected in the activity filter (used only for filtering transaction history) should not affect the provider's behavior on the network actually connected to the website. The eth_blockNumber method should return current block numbers for the connected network, and all blockchain state should reflect the actual current state of that network, regardless of which network is selected in the activity filter dropdown.

Screenshots/Recordings

Setup

On OpenSea (includes timestamps and current net)

On Etherscan (includes timestamps and current net)

Steps to reproduce

1. Install MetaMask extension version 13.0.0
2. Navigate to a dApp website (e.g., Etherscan, OpenSea)
3. Connect MetaMask wallet to the site
4. Note which network is connected to the website (shown in the "Manage permissions" area)
5. Click the network selector dropdown in the activity section (below the main balance area)
6. Select a DIFFERENT network than the one connected to the website
7. Open browser console
8. Run: Number(await window.ethereum.request({method: "eth_blockNumber"}))
9. Wait 1-2 minutes
10. Run the same command again
11. Observe that the block number has not changed despite new blocks being produced on the connected network
12. Change the activity filter back to match the connected network and observe blocks now advance normally

Error messages or log output

None

Detection stage

In production (default)

Version

13.3.2

Build type

None

Browser

Chrome

Operating system

MacOS

Additional context

This issue occurs whenever there is a mismatch between:

1. The network actually connected to the website (shown in "Manage permissions")
2. The network selected in the activity filter dropdown (used to filter transaction history)

The problem affects all blockchain data accessed through the provider, not just block numbers - the entire provider state appears frozen at a specific block.

Other wallet providers (Rainbow, Coinbase Wallet) do not have this issue as they typically don't have separate network selectors for website connection vs. activity filtering.

The root cause appears to be that the activity filter network selection is incorrectly affecting the provider's RPC behavior for the actually connected network.

[johnnyshankman]

Bumping this.

We, dApp developers, are getting flooded with bug reports that directly trace back to this issue which is not solvable by the dApp. Very frustrating for things like auctions and limited time windows for purchases as the blocktime never advances. Users think there is still supply left, or still time left in the auction, or think they are the top bidder -- but all of those are incorrect according to the latest block which is not being fed through the provider.

This is an ecosystem-wide issue now. I've made OpenSea and Etherscan teams aware.