OnFinality

Posted on Sep 12 Originally published at onfinality.io

RPC BNB: Connect to BNB Smart Chain Endpoints

#web3 #blockchain #devops #tutorial

If you searched for "RPC BNB," you probably want one of two things: the exact settings to connect to BNB Smart Chain, or a clear way to decide which endpoint to use for your app. This page gives you both. It starts with the chain settings you can paste into a wallet or config, then walks through endpoint options, a working request example, and the failure modes that show up most often when teams move from a quick test to real traffic.

BNB Smart Chain (often called BSC, and part of the wider BNB Chain ecosystem) is an EVM-compatible network. That means any tool that speaks standard Ethereum JSON-RPC — ethers, viem, web3.js, Hardhat, Foundry, MetaMask — can talk to it once you point it at a BNB Chain RPC URL. The main differences you will notice are the chain ID, the native token, the block explorer, and the way some workloads (log queries, archive reads) behave under load.

Chain settings at a glance

Use these values when adding BNB Smart Chain to a wallet, a backend config, or a deployment script. They match the network configuration OnFinality publishes for BNB Chain.

Setting	BNB Smart Chain Mainnet	BNB Smart Chain Testnet
Chain ID	56	97
Chain name	BNB Smart Chain Mainnet	BNB Smart Chain Testnet
Native currency	BNB (18 decimals)	tBNB (18 decimals)
Block explorer	https://bscscan.com	https://testnet.bscscan.com
Public RPC (OnFinality)	https://bnb.api.onfinality.io/public	https://bnb-testnet.api.onfinality.io/public
Transports	HTTP, WebSocket	HTTP

A few practical notes on this table:

Chain ID is the field that most often causes "wrong network" errors. If a wallet or SDK is on 56 but your contract is deployed to 97, transactions will fail or land on the wrong chain.
The native token symbol matters for gas estimation and for anything that displays balances. On testnet it is tBNB, not BNB.
The public endpoints above are fine for development, scripts, and low-volume reads. For production traffic, plan for a managed or dedicated endpoint instead — see the next section.

When a public endpoint is enough, and when it is not

This is the decision most readers actually need to make. The right answer depends less on the network and more on your workload shape.

A public endpoint is usually fine when:

You are prototyping, running a local script, or testing a contract deployment.
You are reading a handful of balances or calling a few view functions per minute.
You are validating that your chain settings are correct before wiring up anything else.

Move to a managed or dedicated endpoint when:

You run a backend that serves many users, a bot, or an indexer.
You depend on eth_getLogs over wide block ranges, which is heavy on any shared node.
You need archive data (historical state) or trace/debug methods.
You need WebSocket subscriptions and want a stable connection rather than a shared one.
You want predictable throughput and a clear place to ask for help when something breaks.

OnFinality offers BNB Chain RPC as a managed API service and as dedicated node infrastructure. The managed API is the faster path for most teams; dedicated nodes make sense when you need isolation, custom configuration, or a specific capacity profile. You can compare plans on the RPC pricing page and see the full list of supported RPC networks.

If you are still deciding between providers generally, the RPC provider selection guide covers the evaluation criteria in more depth. For BNB Chain specifically, the BNB Chain network page lists the endpoint and transport details.

Making your first request

The fastest way to confirm an endpoint works is a single JSON-RPC call. This asks the node for the current block number:

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

A healthy response looks like a hex block number:

{"jsonrpc":"2.0","id":1,"result":"0x2a1f3c4"}

If you get a result field, your endpoint and chain settings are working. If you get an error object instead, jump to the troubleshooting section below.

In JavaScript, the same call through viem looks like this:

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

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

const blockNumber = await client.getBlockNumber()
console.log(blockNumber)

For a wallet, the network config is the same data in a different shape:

{
  "chainId": "0x38",
  "chainName": "BNB Smart Chain Mainnet",
  "nativeCurrency": { "name": "BNB", "symbol": "BNB", "decimals": 18 },
  "rpcUrls": ["https://bnb.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://bscscan.com"]
}

Note that 0x38 is 56 in hex. Wallets expect the hex form; most SDKs accept the decimal form. Mixing the two is a common source of confusion.

WebSocket and subscription support

BNB Chain supports both HTTP and WebSocket transports. HTTP is request/response: you ask, the node answers, the connection closes. WebSocket keeps a connection open so the node can push events to you — new blocks, pending transactions, or logs matching a filter.

Use WebSocket when you need:

Real-time reaction to new blocks (for example, a bot that acts on each block).
Log subscriptions instead of polling eth_getLogs on a timer.
Lower overhead for high-frequency reads where opening a new HTTP connection each time is wasteful.

A minimal subscription with ethers looks like this:

import { WebSocketProvider } from 'ethers'

const provider = new WebSocketProvider('wss://bnb.api.onfinality.io/public')

provider.on('block', (blockNumber) => {
  console.log('new block', blockNumber)
})

Two operational notes. First, WebSocket connections can drop; your client should reconnect and re-subscribe rather than assume the stream is permanent. Second, if you are running many subscriptions, that is a signal you may want a dedicated endpoint rather than a shared one.

Common failure modes and how to read them

Most "RPC BNB" problems fall into a small set of categories. Here is how to tell them apart quickly.

Symptom	Likely cause	What to check
`chainId` mismatch or "wrong network" in wallet	Wallet set to a different chain	Confirm chain ID 56 (mainnet) or 97 (testnet)
`method not found`	Method not supported by that node tier	Try a standard method first; check whether you need archive or trace support
Timeouts on `eth_getLogs`	Block range too wide for a shared node	Narrow the range, or move to a dedicated endpoint
Intermittent 429 / rate errors	Shared endpoint under load	Reduce polling, batch requests, or upgrade the plan
Empty result for old state	Node is not an archive node	Request archive access if you need historical state
WebSocket disconnects	Idle or unstable connection	Add reconnect logic with backoff

A quick diagnostic sequence when something is wrong:

Run the eth_blockNumber curl above. If it fails, the problem is connectivity or the endpoint, not your contract.
Run eth_chainId and confirm it returns 0x38 for mainnet. If not, you are pointed at the wrong network.
If simple calls work but log queries fail, the issue is usually query shape or node tier, not the endpoint itself.
If everything works locally but fails in production, compare request volume and concurrency between the two environments.

Choosing between shared, managed, and dedicated

Once you are past prototyping, the decision is mostly about isolation, capacity, and how much operational work you want to own.

Option	Best for	Trade-off to weigh
Public endpoint	Scripts, tests, low-volume reads	Shared capacity; not built for sustained production load
Managed RPC API (OnFinality)	Most production apps, bots, backends	You share infrastructure but get managed reliability and support
Dedicated node (OnFinality)	High-throughput, archive, trace, or isolated workloads	Higher cost; you get predictable, isolated capacity
Self-hosted node	Teams with specific control or compliance needs	You own syncing, upgrades, monitoring, and on-call

A useful rule of thumb: if your app has users waiting on a response, or a bot that must not miss blocks, do not run it on a public endpoint. Move to a managed API first, and only go dedicated when you can point to a specific reason — archive reads, trace calls, sustained high request rates, or a need for isolation.

Operational checklist before you ship

Before you point production traffic at any BNB Chain endpoint, confirm the following:

Chain ID and native token are correct in every environment (mainnet and testnet).
You have a fallback endpoint or provider in case the primary has an issue.
Your log queries use bounded block ranges and are not scanning the entire chain history on each call.
WebSocket clients reconnect and re-subscribe automatically.
You monitor error rates and latency, not just uptime.
You know which methods your workload needs (standard, archive, trace) and that your endpoint supports them.

A simple monitoring probe you can run on a schedule:

#!/usr/bin/env bash
RESP=$(curl -s -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}')
echo "$RESP" | grep -q '"result"' && echo "OK" || echo "FAIL: $RESP"

Run something like this from the same region as your app so the latency you measure reflects reality.

Key Takeaways

BNB Smart Chain is EVM-compatible, so standard Ethereum JSON-RPC tooling works once you set the correct chain ID (56 mainnet, 97 testnet) and RPC URL.
Public endpoints are fine for development and low-volume reads; production apps, bots, and indexers should use a managed or dedicated endpoint.
WebSocket support matters for real-time block and log subscriptions; plan for reconnects.
Most failures trace back to chain ID mismatches, unsupported methods, wide log queries, or shared-endpoint rate limits.
OnFinality provides BNB Chain RPC as a managed API and as dedicated nodes; see RPC pricing and supported networks for details.

Frequently Asked Questions

What is the RPC URL for BNB Smart Chain?
OnFinality publishes a public endpoint at https://bnb.api.onfinality.io/public for mainnet and https://bnb-testnet.api.onfinality.io/public for testnet. For production, use a managed or dedicated endpoint from the BNB Chain network page.

What is the chain ID for BNB Chain?
BNB Smart Chain mainnet uses chain ID 56 (0x38 in hex). BNB Smart Chain testnet uses chain ID 97 (0x61 in hex).

Does BNB Chain RPC support WebSocket?
Yes. OnFinality's BNB Chain mainnet endpoint supports both HTTP and WebSocket transports. Testnet is HTTP only in the published configuration.

Why does eth_getLogs time out on BNB Chain?
Wide block ranges are expensive. Shared nodes may reject or time out on large ranges. Narrow the range, paginate, or move to a dedicated endpoint if you need broad historical queries.

Do I need an archive node for BNB Chain?
Only if you need historical state — balances or contract storage at old blocks. Standard endpoints serve recent state; archive access is a separate capability.

Can I use MetaMask with a BNB Chain RPC endpoint?
Yes. Add a custom network with chain ID 56, the RPC URL, and the BscScan explorer URL. The wallet config example above shows the exact fields.

How do I test BNB Chain without spending real BNB?
Use BNB Smart Chain testnet (chain ID 97) with tBNB from a faucet, and point your app at the testnet endpoint. See the BNB Chain Testnet page.

When should I move from a public endpoint to a dedicated node?
When you have sustained request volume, need archive or trace methods, require isolation, or want predictable capacity. Until then, a managed API is usually the right next step — see dedicated nodes for when isolation is worth it.

Related resources

Originally published at OnFinality.

DEV Community