guide7 min read

Scroll Mainnet RPC for Wallet Builders

What to check before a wallet points at Scroll mainnet: chain ID 534352 / 0x82750, Scroll zkEVM vs Ethereum L1 and OP Stack, Scroll Sepolia mix-ups, and public vs dedicated endpoints.

By RPC Directory•
#Scroll#ETH#RPC#Wallet#Chain ID#zkEVM
$scroll-mainnet-rpc.md

Scroll is a zkEVM Layer 2 on Ethereum, not "Ethereum with a different RPC URL" and not an OP Stack chain like Base or Optimism. Wallet builders who paste chain ID 1, point an Ethereum gateway at a Scroll network row, or reuse a Scroll Sepolia config key for mainnet will ship the wrong network, the wrong explorer, or a funds bug. Before you wire MetaMask, Rabby, Rainbow, Phantom, or your own wallet_addEthereumChain flow, prove chain ID 534352, separate L1 from this zkEVM L2, and probe the URL you intend to ship.

This is not a ranking of providers. Use the Scroll Mainnet hub to compare endpoints and paid rows, then run the checks below on the URL you configure.

Chain ID 534352 is not Ethereum and not Scroll Sepolia

Mainnet chain ID is 534352, hex 0x82750. Scroll Sepolia is 534351 / 0x8274f. Ethereum mainnet is 1. Those are different networks. A wallet that already has Ethereum added still needs a separate Scroll network entry.

Wallet-add fields for mainnet:

  • Network name: Scroll (or Scroll Mainnet if the product already scopes the list)
  • Chain ID: 534352 (or 0x82750 if the form wants hex)
  • Currency symbol: ETH
  • RPC URL: a JSON-RPC HTTPS endpoint you have already probed
  • Block explorer: https://scrollscan.com

Native gas is ETH with 18 decimals, same symbol as Ethereum L1. The shared ticker is a common UX trap: users think they are on Ethereum when the network list says "ETH." Show the network name and chain ID in the UI, not the symbol alone.

Call eth_chainId on the exact RPC URL you will ship. Expect 0x82750. A gateway that returns 0x1 is Ethereum. A gateway that returns Scroll Sepolia (0x8274f), times out, or answers HTML is not Scroll mainnet for that transport. Do this after any load balancer or fallback so you are not checking a different backend than production. Official public RPC listed for mainnet is https://rpc.scroll.io (already on the hub); treat it as a probe target, not as proof that every upstream behind a branded gateway is Scroll.

zkEVM quirks that matter for wallets

Scroll is a zkEVM L2 with bytecode-level Ethereum compatibility and Ethereum as the parent chain. That matters for wallets more than the marketing line "EVM compatible":

  • Deposits and withdrawals go through the Scroll bridge against Ethereum L1, not as a simple same-chain transfer. Bridge UX needs an L1 RPC policy even when the dapp only calls Scroll for day-to-day sends.
  • Finality language follows zkEVM / L2 semantics (safe / finalized and sequencer tip vs L1-anchored confirmation). Soft / sequencer tip is fine for tip UX. Do not copy "wait N Ethereum blocks" heuristics into a Scroll receipt poller without checking what your RPC returns for those tags.
  • Contract addresses are not portable from Ethereum. The same dapp on Ethereum and Scroll uses different deployments. Hard-coding an Ethereum USDC or Uniswap address into a Scroll wallet path is a funds bug.
  • Parent Ethereum still needed for bridge. Keep chain ID 1 configured for deposit and withdraw flows. Never reuse the Scroll RPC URL for L1 calls.
  • Not OP Stack. Scroll is not Base or Optimism. It does not use OP Stack Flashblocks preconfirmations or OP Stack derivation assumptions. Do not import a Base Flashblocks pending matrix or an Optimism sequencer-only confirmation policy into a Scroll wallet path just because all three are Ethereum L2s.

Wallet-add gotchas that show up in QA

The failures that show up in support and QA are usually config, not cryptography:

  1. Wrong chain ID - Ethereum 1 or Scroll Sepolia 534351 pasted into a mainnet form.
  2. Ethereum RPC on a Scroll network row - eth_chainId will not return 0x82750.
  3. Explorer mismatch - pointing users at etherscan.io for Scroll tx hashes, or at a Sepolia explorer for mainnet hashes.
  4. One shared "scroll" RPC bucket in app config - separate keys for scroll and scroll-sepolia so a fallback cannot silently swap networks.
  5. Missing parent Ethereum - bridge and withdraw flows need L1 configured even when the product UI lives on Scroll.
  6. OP Stack assumptions - treating Scroll like Base or Optimism for pending tags, Flashblocks, or sequencer URLs.

wallet_addEthereumChain vs wallet_switchEthereumChain

When you implement wallet_addEthereumChain, send a full EIP-3085 payload: chainId: "0x82750", a complete nativeCurrency object ({ name: "Ether", symbol: "ETH", decimals: 18 }), rpcUrls pointing at your probed HTTPS endpoint, and blockExplorerUrls: ["https://scrollscan.com"]. Wallets that receive only symbol on add can reject the request.

For wallet_switchEthereumChain, send only { chainId: "0x82750" }. Metadata fields belong on add, not switch. Prefer one primary RPC in the wallet payload; put failover in your own client, not as five public URLs the wallet may pick at random.

Public vs dedicated for wallet traffic

Public endpoints are fine for:

  • Local development and wallet QA
  • Low-volume eth_chainId / eth_blockNumber probes
  • One-off scripts and docs examples

They are a poor primary path when you:

  • Run production wallet RPC for many users (balance, nonce, send, receipt polls)
  • Need predictable latency and a support channel when the gateway 429s
  • Depend on historical state, wide eth_getLogs, or sustained WebSocket traffic
  • Cannot absorb shared-node brownouts during a mint, airdrop, or market spike

Probe the candidate URL before you call it ready:

  1. eth_chainId returns 0x82750.
  2. The latest block or head advances when you poll twice a few seconds apart. Do not use an unchanged account balance as proof the node is live.
  3. One balance or receipt read against a known Scroll mainnet address (not an Ethereum or Scroll Sepolia address).
  4. If you need push updates, a WebSocket path that survives a disconnect (many public sockets do not).
  5. Optional: compare safe / finalized block tags if your confirmation policy depends on them, and document which tag "confirmed" means next to the RPC URL.

Public rows on the hub are shared and rate-limited. Use them for the probe. For production wallet traffic, compare the paid rows on the same hub for method coverage, archive or historical access if you need it, and quota. Dwellir is one of those rows: a flat response-credit model that is easier to budget when the mix of reads and writes is not stable. It is not the only option. A cheaper URL that fails the probe above is not a savings. The public vs paid guide covers when a shared endpoint stops being enough. The pricing calculator is there for the rest. Log-heavy indexers should also read the eth_getLogs caps guide before assuming a wide filter will pass on every URL.

Practical split for a wallet stack

  • User-facing Scroll network row - chain ID 534352 / 0x82750, ETH symbol, Scrollscan, RPC you probed today.
  • Scroll Sepolia row - chain ID 534351 / 0x8274f, separate config key, never reused as the mainnet RPC (stale Sepolia configs are a common paste trap even when a product no longer ships testnet).
  • Parent Ethereum row - chain ID 1, kept for bridge and withdraw flows, never reused as the Scroll RPC.
  • Backend / indexer - dedicated or paid endpoint with explicit method and archive needs; do not share the browser wallet's public URL.
  • Receipt policy - decide whether "confirmed" means latest, safe, or finalized on this zkEVM L2, and store that next to the RPC URL.

Ship the hub comparison and the probe first. Marketing copy about "Scroll RPC" or "Scroll mainnet RPC" does not replace eth_chainId returning 0x82750.

Back to Blog