bug: MetaMask RPC router race after wallet_addEthereumChain — eth_chainId reports new chain before tx routing switches, causing tx to land on old chain (CCTP 'Invalid destination domain')

[osr21]

Summary

After a successful wallet_addEthereumChain or wallet_switchEthereumChain, MetaMask's eth_chainId briefly reports the new chain ID before its internal JSON-RPC router has fully switched to the new endpoint. Any transaction submitted in this ~200–500ms window is routed to the old chain, not the new one.

This is distinct from #89 (where wallet_switchEthereumChain silently returns without actually switching). Here, the switch does appear to succeed and #89's workaround — polling eth_chainId until it matches — is already in place, but there is still a brief window where eth_chainId matches the new chain while the transaction submission still goes to the old RPC endpoint.

---

Reproduction

Observed consistently when bridging USDC Base Sepolia → Arc Testnet via CCTP V2 in the Arc Relay Bridge:

1. Burn completes on Base Sepolia via ERC-4337 UserOp
2. Attestation received from Circle Iris (source domain 6 → destination domain 26)
3. Code calls wallet_addEthereumChain to switch to Arc Testnet, then polls eth_chainId until it returns 0x4CEF52
4. Code acquires BrowserProvider → getSigner() and submits MessageTransmitter.receiveMessage(message, attestation)

Expected: receiveMessage lands on Arc Testnet (domain 26) ✅
Actual: receiveMessage lands on Base Sepolia (domain 6) → reverts with "Invalid destination domain" ❌

On-chain evidence

Tx	Chain	Result	Notes
0x1008a1d8e2209e776d852684deece36780eba747167c093a863ab7229d1cbd6b	Base Sepolia	❌ Reverted	receiveMessage submitted to wrong chain; message dest domain = 26, chain domain = 6
0x0fc42da8bd52440dc7391bf141e2e5822090d6d654ea0d4ed0cb9054b203adb2	Arc Testnet	✅ Success	Same attestation, correct chain

Decoded the CCTP message embedded in the failing calldata:

• Source domain: 6 (Base Sepolia)
• Destination domain: 26 (Arc Testnet)
• The message and attestation were correct — only the chain the tx was submitted to was wrong.

---

Root cause

wallet_addEthereumChain("Arc Testnet")
  → MetaMask: ok  (eth_chainId now returns 0x4CEF52)
  → [~200–500ms gap]
  → MetaMask: RPC router fully switched to Arc Testnet RPC endpoint

There is a timing gap between when eth_chainId reflects the new chain and when the internal RPC transport has caught up. Polling eth_chainId — as the standard #89 workaround does — is not sufficient to guarantee the next eth_sendTransaction hits the correct RPC endpoint.

---

Fix / Workaround

After the chain switch (and after eth_chainId confirms the new chain), verify that the provider itself reports the correct network via provider.getNetwork() before submitting any transaction. Unlike eth_chainId, getNetwork() goes through the same RPC transport that eth_sendTransaction will use.

async function getSignerOnChain(
  expectedChainId: number,
  maxRetries = 6
): Promise<ethers.JsonRpcSigner> {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    if (attempt > 0) await new Promise(r => setTimeout(r, 500 * attempt));
    const provider = await getProvider();   // fresh BrowserProvider
    const signer   = await provider.getSigner();
    const network  = await provider.getNetwork();
    if (Number(network.chainId) === expectedChainId) return signer;
  }
  throw new Error(
    `Wallet is still on the wrong network after ${maxRetries} attempts. ` +
    `Please switch to the destination chain manually in MetaMask and try again.`
  );
}

The key difference from polling window.ethereum.request({ method: "eth_chainId" }) directly: provider.getNetwork() sends the eth_chainId call through the same underlying transport that eth_sendTransaction uses, catching the race that direct polling misses.

---

Affected environments

• MetaMask browser extension with Arc Testnet (chain ID 5042002, 0x4CEF52)
• Reproduced on Base Sepolia → Arc Testnet CCTP V2 bridge
• Likely affects any dApp that switches to a custom EVM network and immediately submits a transaction

Related

• bug: wallet_switchEthereumChain fails silently for Arc Testnet in MetaMask — wallet_addEthereumChain must be used unconditionally #89 — wallet_switchEthereumChain fails silently for Arc Testnet; must use wallet_addEthereumChain unconditionally

[osr21]

Confirmed workaround in production — wallet_switchEthereumChain-first pattern

We hit both the original #89 (silent no-switch) and the router-lag race described here while building the Gas Refuel feature, where the wallet needs to be on Arc Testnet before submitting a USDC transfer. The following pattern has been reliable across Arc Testnet, Ethereum Sepolia, Base Sepolia, and Avalanche Fuji:

async function switchToChain(chain: ChainConfig): Promise<void> {
  const addChain = () =>
    window.ethereum!.request({
      method: "wallet_addEthereumChain",
      params: [{
        chainId: chain.hexId,
        chainName: chain.name,
        nativeCurrency: chain.nativeCurrency,
        rpcUrls: [chain.rpcUrl],
        blockExplorerUrls: [chain.explorerUrl],
      }],
    });

  try {
    // Try switch first — works for any chain already in MetaMask,
    // and avoids the nativeCurrency.symbol mismatch error (see below).
    await window.ethereum.request({
      method: "wallet_switchEthereumChain",
      params: [{ chainId: chain.hexId }],
    });

    // Verify the RPC router committed — Arc Testnet can succeed here
    // but the next sendTransaction still goes to the old chain (#89 + router lag).
    const hexId = await window.ethereum.request({ method: "eth_chainId" });
    if (parseInt(hexId, 16) !== chain.id) await addChain();
  } catch (err) {
    const code = (err as { code?: number })?.code;
    if (code === 4001) throw err; // user rejected — propagate immediately
    // 4902 = unknown chain; any Arc-specific non-standard error → fall back to addChain
    await addChain();
  }
}

After this call, we wait 800 ms before constructing new ethers.BrowserProvider(window.ethereum) — the combination has eliminated the "wrong chain" submission.

Additional related issue: nativeCurrency.symbol mismatch

If you call wallet_addEthereumChain directly on a chain the user already has in MetaMask (e.g. added manually from Arc docs), MetaMask throws:

nativeCurrency.symbol does not match currency symbol for a network the user 
already has added with the same chainId. Received: ARC

The wallet_switchEthereumChain-first pattern avoids this entirely because no nativeCurrency params are sent when switching a known chain. This error appears to be distinct from the router-lag race but shares the same fix path.