What is the BNB RPC name and how do you configure it?

When a wallet or library asks for the "BNB RPC name", it usually wants a small set of network parameters: the chain name, the RPC URL, the chain ID, the native currency, and the block explorer. Those values are what let a client identify BNB Smart Chain and route JSON-RPC calls to it. This page gives you the exact settings for mainnet and testnet, shows how to apply them in MetaMask and in code, and explains how to choose an endpoint that stays usable as your traffic grows.

Chain settings at a glance

Use these values when adding BNB Smart Chain to a wallet, a dApp network switcher, or a backend config. The chain ID is the field most tools actually use to disambiguate the network, so keep it consistent everywhere.

A quick note on naming: people say "BNB RPC", "BSC RPC", and "BNB Chain RPC" interchangeably. They all refer to the same EVM-compatible chain. BNB Smart Chain is the current name; BSC is the older short form you will still see in tooling and docs. If a provider lists "BSC", treat it as the same network and check the chain ID to be sure.

Which endpoint should you actually connect to?

The RPC name is just a label. The endpoint behind it is what determines whether your app feels instant or flaky. Before you paste a URL into production, decide which category fits your workload.

• Public endpoints are fine for local development, quick scripts, and low-volume reads. They are shared, so throughput and rate behavior are outside your control.
• Managed RPC API access gives you a keyed endpoint with a defined service relationship, which is the usual choice for apps with real users.
• Dedicated nodes give you isolated capacity for heavy eth_getLogs, archive queries, or high request volume where shared endpoints become a bottleneck.

If you are still deciding between these tiers, the RPC provider selection guide walks through the tradeoffs. For BNB Chain specifically, OnFinality's BNB Chain RPC covers both managed API access and dedicated node options, and RPC pricing shows how the tiers are structured.

Adding BNB Smart Chain to a wallet

Most wallets accept a custom network through the same five fields. In MetaMask, open Settings, then Networks, then Add a network manually, and enter the mainnet values from the table above. The chain ID 56 is what prevents the wallet from confusing BNB Smart Chain with another EVM chain.

You can also trigger the same flow from a dApp using wallet_addEthereumChain. This is the cleaner path because it lets your app request the network switch directly instead of asking users to type settings by hand.

const BNB_MAINNET = {
  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'],
};

await window.ethereum.request({
  method: 'wallet_addEthereumChain',
  params: [BNB_MAINNET],
});

One detail that trips people up: chain IDs are passed as hex strings in wallet_addEthereumChain. Mainnet 56 becomes 0x38, and testnet 97 becomes 0x61. If you pass the decimal value, some wallets reject the request silently.

Wiring the endpoint into ethers or viem

In code, the RPC name matters less than the URL and chain ID you construct the client with. Both ethers and viem let you point at any endpoint, so the choice of provider is a config decision rather than a code rewrite.

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider(
  'https://bnb.api.onfinality.io/public',
  56 // chainId
);

const block = await provider.getBlockNumber();
console.log('BNB Smart Chain head:', block);

With viem, the same idea uses a chain definition plus a transport:

import { createPublicClient, http } from 'viem';
import { bsc } from 'viem/chains';

const client = createPublicClient({
  chain: bsc,
  transport: http('https://bnb.api.onfinality.io/public'),
});

If you later move to a keyed or dedicated endpoint, you change the URL string and nothing else. Keeping the endpoint in an environment variable from day one makes that switch painless.

Verifying the connection with a raw JSON-RPC call

Before you debug application code, confirm the endpoint itself answers. A single eth_chainId call tells you whether you are talking to the chain you think you are.

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

The response should return 0x38 for mainnet. If you get 0x61, you are pointed at testnet. If the call times out or returns an error object, the problem is the endpoint or your network path, not your contract logic.

Common failure modes and how to read them

Most "BNB RPC name" problems are really configuration or endpoint problems wearing a confusing error message. Here is how to map symptoms to fixes.

That last row is worth separating out. A stuck transaction is usually a nonce or gas problem, not a network naming problem. If you are chasing that class of bug, the explanation of transaction nonces is a better starting point.

Mainnet versus testnet: keep them separate

Testnet uses chain ID 97 and the tBNB symbol, and it lives at a different endpoint. Mixing the two is one of the most common sources of confusion, because a dApp that hardcodes mainnet settings will fail quietly against testnet data.

A practical pattern is to define both networks in one config object and select by environment:

const NETWORKS = {
  mainnet: {
    chainId: 56,
    rpc: 'https://bnb.api.onfinality.io/public',
    explorer: 'https://bscscan.com',
  },
  testnet: {
    chainId: 97,
    rpc: 'https://bnb-testnet.api.onfinality.io/public',
    explorer: 'https://testnet.bscscan.com',
  },
};

const active = process.env.CHAIN_ENV === 'testnet'
  ? NETWORKS.testnet
  : NETWORKS.mainnet;

Testnet tBNB comes from a faucet rather than a purchase, so you can exercise contract deploys and transaction flows without spending real BNB. See the BNB Chain Testnet network page for the current endpoint details.

When a public endpoint stops being enough

Public endpoints are genuinely useful, and for a prototype they are often all you need. The friction appears when request volume, log queries, or WebSocket subscriptions grow. At that point the shared endpoint becomes a variable you cannot control, and debugging gets harder because failures are intermittent rather than consistent.

The usual progression is: public endpoint for development, a managed RPC API for staging and early production, then dedicated nodes once you have predictable heavy workloads such as indexers, analytics, or trading-adjacent services. OnFinality offers BNB Chain RPC API access and dedicated node infrastructure so you can move along that path without changing your application code, only the endpoint URL. You can review the full set of supported RPC networks if you also operate on other chains and want consistent tooling.

Key Takeaways

• The BNB RPC name is a set of network parameters, not a single string. The important ones are chain name, RPC URL, chain ID, currency, and explorer.
• Mainnet uses chain ID 56 and BNB; testnet uses chain ID 97 and tBNB. Keep them in separate config entries.
• Chain IDs are hex strings in wallet_addEthereumChain: 0x38 for mainnet, 0x61 for testnet.
• Verify any endpoint with a raw eth_chainId call before debugging application code.
• Public endpoints suit development; managed RPC API access and dedicated nodes suit production traffic and heavy log queries.
• BNB, BSC, and BNB Chain all refer to the same EVM-compatible network.

Frequently Asked Questions

What is the BNB RPC name?

It is the network label plus the parameters a client needs to reach BNB Smart Chain: the chain name (BNB Smart Chain), the RPC URL, the chain ID, the native currency, and the block explorer. Wallets and libraries use these together to identify and connect to the network.

What is the chain ID for BNB Smart Chain?

Mainnet is 56 and testnet is 97. In wallet_addEthereumChain requests these are written as hex strings, 0x38 and 0x61.

Is BSC the same as BNB Chain?

Yes. BSC was the earlier short name for BNB Smart Chain. The chain ID is the reliable way to confirm you are on the right network regardless of which label a provider uses.

Why does my wallet say wrong network?

The chain ID in your wallet config does not match the network you are trying to use. Check that mainnet is set to 56 and testnet to 97, and that the RPC URL matches the same network.

Can I use a public RPC endpoint in production?

You can, but shared endpoints give you limited control over throughput and rate behavior. For apps with real traffic, a managed RPC API or dedicated node is the more predictable option.

Does BNB Chain support WebSocket RPC?

Mainnet endpoints can support WebSocket transport for subscriptions, while testnet availability may differ. Confirm transport support on the specific endpoint you plan to use before building subscription logic around it.