Here are all of the cases in the front-end where we treat built-in and custom Mainnet differently, or where we incorrectly use network ID rather than chain ID:

~~tx-helper will filter transactions by network ID (as does incomingTxListSelector, unconfirmedTransactionsCountSelector and confirm-transaction-base.container.js)~~ (fixed in add chainId to all new transaction metadata #10528)
~~getEtherscanNetworkPrefix uses network ID rather than chain ID~~ (fixed in prefer chainId when building block explorer urls #10587)
~~getAccountLink uses network ID rather than chain ID~~ (Fixed in use etherscan-link for account-link #10590)
~~Cached balances are accessed via network ID (this needs to be fixed in the front-end and background simultaneously)~~ (fixed by cache balances by chain id #10545)
~~The ENS input component uses network ID rather than chain ID to determine whether the network supports ENS~~ (Fixed in use chain id for enabling ENS IPFS resolution #10507)
- Possibly related, the error handling in the Send flow (getToErrorObject) checks whether the current network is an "ETH network" using the network ID rather than chain ID (Pending in prefer chainId over networkId in most cases #10594)
~~The token asset page uses the network ID to generate the Etherscan link~~ (Fixed in prefer chainId when building block explorer urls #10587)
The deposit ether modal uses the network ID to determine which faucet to show, and to determine the network name (Pending in prefer chainId over networkId in most cases #10594)
See all uses of getCurrentNetwork and getCurrentNetworkId and isEthNetwork (Pending in prefer chainId over networkId in most cases #10594)

Treat custom RPC networks with mainnet chainId as mainnet #8668

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions