Connecting MetaMask to Sonic, Berachain, and Monad
The script for joining any new EVM chain has been the same since 2019: open MetaMask, "Add network manually," fill in five fields. The fields don't change. Only the values do.
But "the values" is exactly the friction. Every new chain's docs page bury them slightly differently. The official public RPC works for 30 seconds before rate-limiting you. The block explorer URL is sometimes explorer.x.io and sometimes xscan.org and sometimes a Blockscout fork the team forgot to register. By the time you get a working setup, you've already lost the urgency that brought you to the chain.
This post is the five-field reference for Sonic, Berachain, and Monad — three of the biggest EVM L1/L2 launches in the past year. Paste, save, switch, done. Plus the boring failure modes I see people hit.
The five fields, every time
Whatever EVM chain you're adding, MetaMask wants:
- Network Name — cosmetic; pick anything
- New RPC URL — the only field that affects whether anything actually works
- Chain ID — integer; wrong value silently breaks signing
- Currency Symbol — cosmetic; just the display ticker
- Block Explorer URL — used by "View on explorer" links
The RPC URL is the field that matters. Most chains publish a public one. They're fine for testing — they're terrible for production use because they share rate limits across the whole world. We'll come back to that.
Sonic
The Fantom successor (FTM migrated 1:1 to S in early 2025). Sub-second block times, EVM-compatible, the same Solidity tooling works unchanged.
| Field | Value |
|---|---|
| Network Name | Sonic |
| New RPC URL | https://rpc.swiftnodes.io/rpc/sonic?key=YOUR_API_KEY |
| Chain ID | 146 |
| Currency Symbol | S |
| Block Explorer URL | https://sonicscan.org |
For WebSocket-using dApps: wss://rpc.swiftnodes.io/ws/sonic?key=YOUR_API_KEY.
If you don't want a dedicated key yet, the official public RPC is https://rpc.soniclabs.com — works for casual use, throttles past ~5 RPS.
Berachain
Proof-of-Liquidity L1 launched mainnet in 2025. EVM-compatible execution, three-token economy (BERA for gas, BGT for governance, HONEY as the stablecoin). Block times ~5 seconds.
| Field | Value |
|---|---|
| Network Name | Berachain |
| New RPC URL | https://rpc.swiftnodes.io/rpc/berachain?key=YOUR_API_KEY |
| Chain ID | 80094 |
| Currency Symbol | BERA |
| Block Explorer URL | https://berascan.com |
WebSocket: wss://rpc.swiftnodes.io/ws/berachain?key=YOUR_API_KEY.
Public RPC: https://rpc.berachain.com — heavily rate-limited, fine for adding the network but you'll want a proper provider before doing anything in volume.
Monad
High-performance EVM with parallel execution targeting 10k+ TPS. Mainnet launched 2025. Familiar Solidity/EVM tooling on the surface, very different execution model underneath.
| Field | Value |
|---|---|
| Network Name | Monad |
| New RPC URL | https://rpc.swiftnodes.io/rpc/monad?key=YOUR_API_KEY |
| Chain ID | 143 |
| Currency Symbol | MON |
| Block Explorer URL | https://monadexplorer.com |
WebSocket: wss://rpc.swiftnodes.io/ws/monad?key=YOUR_API_KEY.
Public RPC: https://testnet-rpc.monad.xyz for testnet, https://rpc.monad.xyz for mainnet — both work, both throttle.
Step-by-step in MetaMask
If you've never added a custom network before:
- Click the network dropdown at the top of MetaMask (it says "Ethereum Mainnet" by default)
- Click Add network at the bottom
- On the page that opens, click Add a network manually at the bottom
- Paste the five values from one of the tables above
- Click Save
- MetaMask will run a quick chain ID + connection check. Green check = working. Error = check the table values match exactly, no extra whitespace
- Select the new network from the dropdown to switch to it
Repeat for each chain you want.
Why not just use the public RPC?
The public endpoints (rpc.soniclabs.com, rpc.berachain.com, rpc.monad.xyz) are fine for adding a network and signing a few transactions. They're not fine for any of:
- A bot or dApp making more than ~5 RPC calls per second — you'll hit shared rate limits
- Anything reading state in a loop — the public endpoints have aggressive caching that returns slightly stale data
- Real-time WebSocket subscriptions — most public RPCs don't expose
wss://at all - Historical/archive queries (
eth_callagainst blocks more than ~128 deep) — almost never supported on public endpoints
For production work on these chains, you need a provider that gives you your own throughput allocation, WebSocket support, and archive access. The SwiftNodes URLs above do all three on every plan including the free tier.
Common errors when this goes wrong
The five most-likely failure modes, in order of frequency:
"Could not connect to network. Please check the RPC URL."
Means MetaMask sent a test RPC call and got no response (or an HTTP error). Usually: typo in the URL, missing the https://, or a bad API key. Open the URL in a browser — you should get a JSON-RPC error response, not a 404 or a generic "page not found."
"This network's currency symbol doesn't match the chain's mainnet currency."
MetaMask checks the symbol you entered against a known list. Cosmetic warning — you can save anyway. Just shows up because you typed MONAD instead of MON, or BERACHAIN instead of BERA.
"Chain ID returned by the RPC doesn't match the one entered." Means the RPC URL is for a different chain (or for testnet and you entered mainnet's chain ID, or vice versa). Double-check the table values match — the chain ID is the only field where a typo silently breaks signing in subtle ways. MetaMask catches the most obvious cases at save time, but if you're hitting "your transaction was rejected" later for no apparent reason, this is the first thing to check.
Transactions succeed in MetaMask but never confirm. You're using a stale or wrong-network RPC. The transaction was broadcast somewhere it can't be mined. Solution: switch networks once away and back in MetaMask to force a re-connect, or remove the network and add it again with the correct RPC URL.
Wallet shows wrong balance / "0 BERA" when you know you have funds. Almost always a stale RPC reading. Same fix as above — reconnect the network. If it persists, the issue is on the RPC side and you need a different provider.
A note about chain IDs and signing safety
This is the one technical detail worth understanding before you sign transactions on a new chain:
EVM transaction signatures include the chain ID as part of the message being signed. This was added in EIP-155 to prevent "replay attacks" where a signed transaction on chain A could be re-broadcast on chain B and still be valid.
If your MetaMask custom network has the wrong chain ID, signatures will technically work — but they'll be valid for the wrong chain. In practice this just means the transaction fails silently. But on rare occasions (when chain IDs collide or when bridges are involved) it can mean a signed transaction gets executed on a chain you didn't intend.
Bottom line: copy the chain ID from a trusted source (the chain's official docs or a reputable RPC provider, not a random screenshot), and double-check it matches before signing high-value transactions.
The takeaway
Adding any EVM chain to MetaMask is a five-field paste-and-save operation. The values are stable per chain — copy them once, save the network, you're done. The only field where mistakes are costly is the chain ID; the RPC URL just decides whether you have a fast experience or a slow one.
For each of Sonic, Berachain, and Monad, paste the table above and you'll have a working network in about 90 seconds.
SwiftNodes supports all three of these chains on the same API key — same key works for Sonic, Berachain, Monad, plus Ethereum, Base, Arbitrum, Solana, and 70+ other chains. See the supported chains list or grab a free API key — no credit card, no KYC.
Related posts
- Nonce Management for High-Throughput Senders
One stuck nonce can freeze every transaction behind it. If you're sending from a hot wallet at volume — a relayer, a market maker, a bridge — leaning on eth_getTransactionCount('pending') will eventually stall you. Here's how nonces actually work and how to manage them locally at scale.
- eth_getBlockReceipts: Every Receipt in a Block, One Call
Fetching every receipt in a block one transaction at a time is the N+1 problem in disguise — hundreds of round-trips per block. eth_getBlockReceipts returns all of them in a single call. Here's how it works, when to use it over JSON-RPC batching, and how to fall back when a node doesn't support it.
- Did It Actually Succeed? Reading eth_getTransactionReceipt
A transaction being mined does not mean it worked — a reverted transaction still lands in a block and still costs you gas. The receipt is where the truth lives: the status flag, the event logs, the real gas paid, and how many confirmations you should wait. Here's how to read one.