How do I add a BNB Chain RPC to MetaMask?

MetaMask does not ship with BNB Smart Chain preloaded, so the first thing most people need is the network form: chain ID, RPC URL, symbol, and explorer. That form is easy to fill in, but the RPC URL you choose is the part that decides whether your wallet or app stays responsive when traffic picks up. This page gives you the exact BNB Smart Chain settings, walks through adding them in MetaMask, and then explains how to check that the endpoint you picked is actually doing its job.

Which BNB Chain endpoint should you put in MetaMask?

For a wallet you use by hand, a public endpoint is usually fine. For anything scripted, a dapp, a bot, or a team that shares an RPC URL, the choice matters more. Use this as a starting point:

OnFinality provides a public BNB Smart Chain endpoint you can paste straight into MetaMask, plus managed RPC API and dedicated node options when a shared endpoint is no longer enough. You can see the network details on the BNB Chain RPC page, and compare plans on RPC pricing.

If you are not sure which tier you need, the short version is: start public, move to managed when you have real users, move to dedicated when your workload is continuous or log-heavy.

BNB Smart Chain network settings for MetaMask

These are the values MetaMask asks for when you add a custom network. Mainnet and testnet differ only in chain ID, RPC URL, symbol, and explorer.

A few notes that save time later:

• Chain ID 56 is mainnet. If a dapp says it cannot find your network, the chain ID is the first thing to check.
• The currency symbol field is cosmetic in MetaMask, but keep it as BNB so balances read correctly.
• Testnet uses tBNB, which you get from a faucet. Testnet BNB has no value.
• If you paste an RPC URL with a trailing space, MetaMask will reject it. Copy cleanly.

Adding BNB Chain to MetaMask step by step

1. Open MetaMask and click the network selector at the top left of the wallet.
2. Choose Add network, then Add a network manually.
3. Fill in the fields from the table above. For mainnet, use chain ID 56 and the mainnet RPC URL.
4. Save. MetaMask switches to the new network and shows your BNB balance.
5. If the balance looks wrong, switch to another network and back, which forces a refresh.

You can also add the network programmatically from a dapp. This is the same flow MetaMask uses internally, and it is useful when you want to onboard users without asking them to type settings:

await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0x38", // 56 in hex
    chainName: "BNB Smart Chain",
    nativeCurrency: { name: "BNB", symbol: "BNB", decimals: 18 },
    rpcUrls: ["https://bnb.api.onfinality.io/public"],
    blockExplorerUrls: ["https://bscscan.com"]
  }]
});

For testnet, swap in chainId: "0x61" (97), the testnet RPC URL, tBNB, and the testnet explorer. Keep the hex and decimal chain IDs consistent, because MetaMask expects hex in this call and decimal in the manual form.

Verifying the endpoint before you trust it

Before you blame MetaMask for a stuck balance or a failed transaction, check the endpoint directly. A quick JSON-RPC call tells you whether the node is responding and whether it is on the chain you expect:

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

You should get back "0x38", which is 56 in hex. If you get a different value, you are pointed at the wrong network. A second call confirms the node is synced:

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Compare that block number against a public explorer. If the node is far behind, transactions may appear pending even though they have already confirmed.

From a JavaScript app, the same checks look like this with ethers:

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://bnb.api.onfinality.io/public");
const network = await provider.getNetwork();
console.log(network.chainId); // 56n
console.log(await provider.getBlockNumber());

If chainId is not 56n, your app is talking to the wrong chain, and MetaMask will show confusing balances as a result.

When a public BNB RPC stops being enough

A public endpoint is shared. That is fine for a wallet, but it shows up as a problem in a few predictable ways:

• Rate limiting under bursts. A dapp that fires many eth_call requests per user can hit shared limits during peak activity.
• Slow or missing logs. eth_getLogs over wide block ranges is heavy. Shared endpoints often cap the range or time out.
• No archive history. If you need balances or state from long ago, you need an archive-capable node.
• No visibility. With a public endpoint you cannot see error rates, latency, or which method is failing.

When you hit those, the fix is not a different public URL. It is a managed RPC API with higher limits and monitoring, or a dedicated BNB Chain node for continuous workloads. OnFinality offers both, and the BNB Chain network page lists what is available for the chain. If you want help matching a workload to a tier, the provider selection guide walks through the criteria.

Debugging common MetaMask and BNB RPC problems

Most issues fall into a small set of causes. Match the symptom to the likely fix:

Two habits prevent most of these. First, keep the RPC URL in one place in your codebase so the wallet and the app cannot drift apart. Second, log the chain ID your app sees at startup, so a wrong-network bug is obvious immediately.

BNB Chain testnet in MetaMask

Testnet is where you should try network changes first. Use chain ID 97, the testnet RPC URL from the table, symbol tBNB, and the testnet explorer. Get testnet BNB from a faucet, then run the same curl checks against the testnet endpoint to confirm you are on chain 0x61.

A common mistake is deploying to testnet but leaving the mainnet RPC URL in the frontend. The contract exists on one chain and not the other, so calls fail in a way that looks like a contract bug. Check the chain ID before you debug the contract. The BNB Chain Testnet page has the network details if you need them.

Key Takeaways

• BNB Smart Chain mainnet uses chain ID 56, symbol BNB, and explorer bscscan.com.
• BNB Smart Chain testnet uses chain ID 97, symbol tBNB, and the testnet explorer.
• The RPC URL is the setting that affects reliability. Public endpoints suit wallets; managed and dedicated endpoints suit apps and heavy workloads.
• Verify any endpoint with eth_chainId and eth_blockNumber before debugging your own code.
• Keep one RPC URL in your codebase so the wallet and the app do not drift to different networks.
• Move to managed RPC when you have real users, and to a dedicated node when your workload is continuous or log-heavy.

Frequently Asked Questions

What is the BNB Chain RPC URL for MetaMask?

For mainnet you can use https://bnb.api.onfinality.io/public with chain ID 56. For testnet, use https://bnb-testnet.api.onfinality.io/public with chain ID 97. Any valid BNB Smart Chain RPC URL works in the form, but the endpoint you choose affects reliability under load.

Why does MetaMask not show BNB Chain by default?

MetaMask ships with Ethereum and a few testnets. Other EVM chains, including BNB Smart Chain, are added as custom networks using the chain ID, RPC URL, symbol, and explorer.

Is BNB Smart Chain the same as BSC?

Yes. BSC, BNB Smart Chain, and BNB Chain are used interchangeably for the same EVM network with chain ID 56. The native token is BNB.

Can I use a public RPC endpoint in production?

You can, but shared endpoints have limits that show up under bursts, wide log queries, and archive requests. For production apps, a managed RPC API or a dedicated node gives you more predictable capacity and a support path.

How do I check which chain my RPC is on?

Call eth_chainId. BNB Smart Chain mainnet returns 0x38 (56) and testnet returns 0x61 (97). If you get anything else, the endpoint is pointed at a different network.

Do I need an archive node for BNB Chain?

Only if you query historical state or wide log ranges. Standard nodes serve recent data. If your app reads old balances or backfills events, you need archive access, which is available on dedicated BNB Chain nodes.

Next steps

If you are setting up a wallet, the settings above are all you need. If you are building on BNB Chain, decide your endpoint tier early: start with the public endpoint on the BNB Chain network page, then move to a managed RPC API or a dedicated node as your request volume grows. You can review RPC pricing and the full list of supported RPC networks to plan the next step.