Chainslist is an EVM network directory for choosing wallet entries by chain ID when network names collide. If two entries look alike, the chain ID required by your pending action and an RPC endpoint returning that ID decide which can work. Check each ChainList candidate in Chainslist before accepting the wallet prompt.
Keep these checks in order:
- Get the required chain ID from the app or transaction you are trying to use.
- Check that the candidate RPC returns that same ID.
- After adding the network, confirm which chain the wallet actually selected.
How do you choose between Chainslist entries with the same name?
Choose the entry whose chain ID matches the pending action, then check its RPC; the displayed name alone cannot settle the choice. Start with the destination shown by the app, bridge, or transaction request. If the wallet prompt says only “Mainnet,” find the chain ID in the app’s network settings or the wallet’s request details before approving it.
Suppose your wallet shows two entries called “Mainnet” while an action requires Arbitrum One. Picking by label could leave you on Ethereum Mainnet, chain ID 1 (0x1); the matching choice is Arbitrum One, chain ID 42161 (0xa4b1). Before, the network switch appears to succeed but the app still asks you to change networks. After, the wallet reports 0xa4b1 and the request can proceed.
These numbers are different forms of the same field: wallet requests commonly use hexadecimal, while directories often display decimal. EIP-155 uses the chain ID in transaction signing, which is why a familiar name, ETH as the native currency, or a familiar explorer cannot substitute for it. Also check whether the destination is a production network or a testnet; a matching brand name says nothing about which environment your funds or contract occupy.
Which entry fields need checking before you approve it?
The chain ID and the RPC response must agree; the remaining fields help you catch an unsuitable or misleading entry. An add-network request typically supplies chainId, chainName, one or more rpcUrls, and often nativeCurrency and blockExplorerUrls. EIP-3085 requires a wallet to reject an RPC URL whose eth_chainId response differs from the requested chain ID.
For a Chainslist RPC candidate, send an eth_chainId JSON-RPC request with params set to an empty array, or inspect the response through a client you already use. An Arbitrum One endpoint should return 0xa4b1. A timeout, a different ID, or an endpoint requiring an API key you lack is a reason to try another endpoint for the same chain ID, not to change chains.
Check the native currency separately: Arbitrum One uses ETH with 18 decimals, but that label does not identify the chain because Ethereum Mainnet also uses ETH. Prefer an HTTPS RPC you can account for operationally; the operator can observe your requests and may rate-limit or serve stale data. Where two endpoints return the same ID yet disagree about balances, compare their block numbers and a block hash at the same height against an independent, trusted endpoint. A fork can retain a chain ID, so eth_chainId alone cannot resolve that edge case.
Why is the wallet request pending or failing?
A pending request usually still needs approval in the wallet, while a failed request needs its parameters or endpoint checked. Open the wallet’s pending prompt first; approving a network addition and approving a transaction are separate actions. Adding a network itself has no on-chain gas fee, but a later transaction needs the native gas token on the selected chain.
If the wallet reports an RPC mismatch, recheck the decimal-to-hex conversion and query every RPC URL offered by the entry. If it reports an invalid URL, use a valid HTTPS endpoint; if calls time out, try another endpoint with the same verified chain ID. EIP-3085 also allows a wallet to reject an add request for other reasons, including a user declining it, so the app’s spinner alone does not establish that the network was added.
A different case occurs when the chain ID is already installed. Wallets should not add a second network with that same ID, even if its proposed name or RPC differs. Switch to the existing entry and inspect its RPC settings; if they are stale, update them in the wallet rather than repeatedly approving the same add request.
How do you know you ended up on the intended chain?
Read the wallet’s active chain ID after the request completes, then check the expected balance or contract through an independent source for that chain. A successful add request may save the network without selecting it; a separate switch or manual selection may still be needed. Once the wallet reports the required ID, retry the original action and check its transaction prompt before signing.
If your balance appears empty, confirm the token contract and chain before assuming funds moved or vanished. Changing wallet networks only changes where the wallet reads and sends transactions; it does not bridge assets. Decide differently if the app requires another chain ID, or if endpoints sharing the requested ID disagree on recent block hashes: resolve that identity conflict before signing.