docs: clarify Arc Testnet chain ID is 5042002, not 1516

[memosr]

Closes #94.
Fixes #81.

Summary

Arc Testnet's chain ID is 5042002 (0x4cef52), but some third-party chain registries and older community guides circulate the incorrect value 1516, causing wallet connection failures. Separately, several Arc Testnet block explorer URLs that circulate in external guides and wallet configs are dead (unreachable / login-gated).

Note: this repo's code and config were already consistent on 5042002, and contained no dead explorer URLs — both bad values circulate outside this repo. The gap was the lack of a clear, discoverable network reference for people setting up wallets/tooling. This PR adds one.

Changes

• Add a Networks section to README.md:
  • Official chain IDs for Mainnet (5042), Testnet (5042002), Devnet (5042001)
  • Arc Testnet wallet-connection parameters (chain ID, RPC URL, currency, explorer)
  • A prominent [!IMPORTANT] callout that 1516 is incorrect, with a curl snippet to verify the chain ID straight from a node (Chain ID inconsistency: some documentation references 1516, actual Arc Testnet chain ID is 5042002 #94)
  • A [!NOTE] callout naming testnet.arcscan.app as the canonical block explorer and flagging the non-usable explorer.testnet.arc.network (unreachable) and explorer.arc.io (team-login-gated) URLs (docs: multiple Arc Testnet block explorer URLs are dead — testnet.arcscan.app is the live explorer #81)

Out of scope

Issue #94 also suggests submitting a PR to ethereum-lists/chains, and #81's remaining fixes live in third-party registries / MetaMask guides. Those are external registries, separate from this repo.

Test plan

• README renders correctly on GitHub (tables + callouts)
• Chain IDs match crates/shared/src/chain_ids.rs

[osr21]

Confirming 5042002 — also documenting the USDC-as-native-gas decimal trap

We've been running on Chain ID 5042002 (0x4cef52) throughout our DApp development without issues, confirming the corrected value.

One additional nuance that trips up first-time Arc wallet integrations beyond the chain ID confusion:

The nativeCurrency.decimals: 18 requirement

When registering Arc via wallet_addEthereumChain, nativeCurrency.decimals must be 18, not 6 — even though USDC is a 6-decimal ERC-20 at 0x3600000000000000000000000000000000000000. The EVM gas layer uses 18-decimal wei units. Setting decimals: 6 causes MetaMask to show gas costs 10^12× too high.

// Correct wallet_addEthereumChain params for Arc Testnet
{
  chainId: '0x4cef52',   // 5042002
  chainName: 'Arc Testnet',
  nativeCurrency: { name: 'USDC', symbol: 'USDC', decimals: 18 }, // 18, NOT 6
  rpcUrls: ['https://rpc.testnet.arc.network'],
  blockExplorerUrls: ['https://testnet.arcscan.app'],
}

Full Arc Testnet reference (for anyone landing here)

Item	Value
Chain ID	5042002 (0x4cef52)
RPC	https://rpc.testnet.arc.network
Explorer	https://testnet.arcscan.app
USDC ERC-20	0x3600000000000000000000000000000000000000
EURC ERC-20	0x89B50855Aa3bE2F677cD6303Cec089B5F319D72a
nativeCurrency.decimals (for wallet registration)	18
CCTP Domain ID	26
TokenMessengerV2	0x8FE6B999Dc680CcFDD5Bf7EB0974218be2542DAA
MessageTransmitterV2	0xE737e5cEBEEBa77EFE34D4aa090756590b1CE275
minFinalityThreshold for CCTP v2	2000

Source: wallet.tsx + contracts.ts

[memosr]

Thanks @osr21
And the decimals: 18 point is the important one to surface here. It's the flip side of the same USDC dual-view: USDC is a 6-decimal ERC-20 at 0x3600…0000, but the native gas layer denominates in 18-decimal (wei-equivalent) units, so nativeCurrency.decimals has to be 18. Set it to 6 and the wallet misreads the raw value and shows gas ~10^12× too high - exactly what you hit.

Independently checked the rest of your table against Circle's references earlier and it lines up: chain ID 5042002 / 0x4cef52, USDC at 0x3600…0000, CCTP domain 26, and the V2 TokenMessenger/MessageTransmitter addresses. Handy to have it all in one place for anyone landing on this PR.

[osr21]

Confirming the table from our Arc Relay Bridge implementation (CCTP V2 Arc ↔ Sepolia / Base Sepolia / Fuji). Three additions for anyone going past wallet setup into CCTP integration:

RPC reliability: rpc.drpc.testnet.arc.network has been the more stable primary in practice. We use rpc.testnet.arc.network as fallback. Both are worth including in any config that accepts a fallback RPC list.

CCTP V2 selector: All Arc Testnet CCTP contracts require the V2 7-param depositForBurn (selector 0x8e0250ee). The V1 4-param variant (0x6fd3504e) will require(false) silently — no revert reason, just a failed tx. If you are porting from a CCTP V1 reference implementation, the ABI is the first thing to swap before debugging anything else.

minFinalityThreshold: 2000 significance: The table lists 2000 correctly, but worth stating why: this is the "finalized" threshold. Lower values (0 = fast, 1000 = safe) do not speed up attestation on Arc — Circle's Iris API simply will not issue an attestation until the burn block is finalized regardless of what the caller requested. Using a lower threshold just means your attestation poll loops indefinitely. 2000 is the only value that produces a result on Arc.

eth_estimateGas on Arc: For receiveMessage calls (the mint step on Arc as destination), eth_estimateGas returns unreliable data. We apply a hard gasLimit: 600_000 override for Arc-destined mint transactions. Not relevant for wallet registration, but relevant for anyone building the relay or mint path programmatically.

---

The nativeCurrency.decimals: 18 note in this thread and the evmVersion: "paris" constraint (Arc and some testnets reject PUSH0 from the Shanghai EVM upgrade, so Solidity contracts must be compiled with evmVersion: "paris" or they revert on deployment) are the two other practical traps worth surfacing in the README's developer notes section if the scope ever expands there.