Summary: EIP-3085 is best understood as wallet chain-registration infrastructure rather than as a convenience RPC for adding custom networks. Its core move is to give dapps a standard way to suggest chain metadata to wallets while keeping final validation, storage, and approval inside the wallet. The mechanism significance is that EIP-3085 formalizes a control surface that sits below account abstraction but above raw RPC: who gets to define which chains are legible to the wallet, which RPC endpoints are trusted, and whether chain metadata is accepted, ignored, or overridden by wallet-maintained registries.
What it does:
Defines wallet_addEthereumChain, an RPC method for requesting that a wallet add an EVM-compatible chain
Standardizes an AddEthereumChainParameter object with chainId, rpcUrls, optional currency metadata, optional block explorers, and optional icons
Requires wallets to validate chain IDs, URLs, and RPC endpoint responses before accepting a request
Explicitly says a successful add does not imply the chain becomes the currently selected chain
Prevents duplicate registrations of the same chainId and bans insecure http: and file: URLs
Leaves wallets free to require additional fields, ignore requester-supplied metadata, or prefer their own chain registries
Key claims:
The canonical EIP says it adds a wallet-namespaced RPC method for adding Ethereum chains, which is the clearest reason to catalog it as wallet control-plane infrastructure rather than chain-discovery UX alone
The spec says only chainId is formally required, but wallets MAY require additional fields or ignore submitted metadata, which means the wallet remains the real authority over what it means to “add” a chain
The method MUST reject missing or empty rpcUrls, invalid URLs, and any RPC URL whose reported eth_chainId does not match the requested chainId, showing that endpoint validation is part of the standard’s security boundary
The EIP says wallets MUST reject http: and file: URLs and should never use a chain ID returned by an RPC endpoint for signing, which makes endpoint trust and anti-spoofing central to the design
The rationale explicitly says adding a chain and switching to a chain are separate concerns, which matters because EIP-3085 governs wallet registry state, not active-chain routing
The privacy section warns that auto-success for already-added chains leaks which networks a user has configured, so implementers should consider prompting even when the chain is already known
MetaMask’s current network-management docs show the live ecosystem pattern clearly: switching can accept an optional chainConfiguration so unknown chains are effectively added in the same UX flow, which is useful evidence that EIP-3085 functions as real wallet plumbing even while the EIP itself remains stagnant
Whitepaper: No standalone EIP-3085 whitepaper or litepaper surfaced in this pass. The strongest sources were the canonical EIP, the raw spec text, and current MetaMask network-management documentation collected in ../../whitepapers/eip-3085-primary-sources-2026-05-09.md.