johnny
October 3, 2025, 6:36pm
1
Recently we have been getting reports of delayed blockchain data coming from Metamask user across our products as well as Opensea, Etherscan, etc.
We have identified the issue as a Metamask bug and reported it to Metamask’s Team on Github , but that does not mean it will be fixed soon necessarily.
The wallet’s data provider gets stuck in time and stop pulling in new blocks and new blockchain data after page load.
This is not a security issue, but it can lead to misleading data displaying on the page, such as the current mint count or current bids being old.
It can also potentially lead to transactions that revert, such as when your Metamask provider thinks the drop is not sold out but it actually is.
To avoid issues, ensure both your Activity network and Connected Network match in Metamask’s UI. This should alleviate the stale data issue.
In the mean time we are warning our community: Be wary when using Metamask for things where time is of the essence on any platform – like auctions on Manifold.
When in doubt, reload the page often or migrate to a more consistent wallet extension, such as Coinbase Wallet or Rainbow Wallet.
Be safe out there and happy minting/bidding!
opened 04:05PM - 02 Oct 25 UTC
type-bug
needs-triage
external-contributor
regression-prod-13.3.2
### 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 state data.
### 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
<img width="403" height="633" alt="Image" src="https://github.com/user-attachments/assets/29bc9ae3-7569-4160-bc5c-86a2d37646d2" />
#### On OpenSea (includes timestamps and current net)
<img width="1013" height="1312" alt="Image" src="https://github.com/user-attachments/assets/a885412a-16e2-427f-b13f-1cfdc88f2b88" />
#### On Etherscan (includes timestamps and current net)
<img width="1019" height="726" alt="Image" src="https://github.com/user-attachments/assets/c959a0b6-0035-4cfb-8ce5-69a3e46c91d9" />
### 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
```shell
None
```
### Detection stage
In production (default)
### Version
13.3.2
### Build type
None
### Browser
Chrome
### Operating system
MacOS
### Hardware wallet
_No response_
### 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.
### Severity
_No response_
