BNB Smart Chain JSON-RPC Quickstart: Endpoint Settings, Chain ID, and First Calls

If you are wiring BNB Smart Chain into a wallet, backend service, or indexer, the fastest path is to confirm the chain settings, send one JSON-RPC request, and then decide how much endpoint capacity your workload actually needs. This page is a practical quickstart and reference for that flow.

Chain settings at a glance

BNB Smart Chain (BSC) is an EVM-compatible network, so the JSON-RPC surface will look familiar if you have worked with Ethereum. The values below are the ones you need to add the network to a client or wallet.

Mainnet is where production traffic and real value live. Testnet is for development, faucet-funded testing, and integration checks before you ship. Keep the two separate in your configuration so you never point a staging key at mainnet by accident.

Decide how you will connect before you write code

The first real decision is not which method to call, it is how you want to reach the chain. That choice shapes your config, your failure handling, and your budget.

• Local development and one-off scripts: a shared public endpoint is usually enough. You get a working URL immediately and can iterate on request shapes without provisioning anything.
• A wallet or dApp front end: you need a stable HTTPS endpoint plus a WebSocket endpoint if you show live balances, pending transactions, or event-driven UI. Browser clients cannot run a full node, so a managed RPC API is the normal choice.
• Backend services, bots, and indexers: request volume, log queries, and archive reads start to matter. This is where you compare shared endpoints against dedicated nodes, and where rate limits and eth_getLogs behavior become the deciding factors.
• High-throughput or latency-sensitive workloads: you generally want dedicated node infrastructure so your capacity is not shared with unrelated traffic.

If you are still weighing providers, the RPC provider selection guide covers the evaluation criteria in more depth. If you already know you want managed BSC endpoints, start from the BNB Smart Chain RPC page.

First request: confirm the endpoint is alive

Before you build anything, confirm the endpoint responds and reports the chain you expect. A chainId call is the cheapest sanity check.

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

A correct mainnet response returns 0x38, which is 56 in hexadecimal. If you get a different value, you are pointed at the wrong network. If you get an error object instead, move to the debugging section below.

Two more calls are worth running during setup:

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

# Client version string
curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":3,"method":"web3_clientVersion","params":[]}'

eth_blockNumber confirms the node is synced and advancing. web3_clientVersion tells you which client implementation is serving you, which is useful when you are comparing behavior across endpoints.

Adding BNB Smart Chain to a wallet or client

Most wallets accept a custom network. Use the settings from the table above. A typical configuration object looks like this:

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

For testnet, swap in chain ID 0x61 (97), the testnet endpoint, and the testnet explorer. Keep the symbol as tBNB so your UI does not imply real funds.

Calling BSC from JavaScript

If you prefer a library over raw curl, viem and ethers both work against BSC because it is EVM-compatible. A minimal viem read looks like this:

import { createPublicClient, http, formatEther } 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();
const balance = await client.getBalance({
  address: "0x0000000000000000000000000000000000000000",
});

console.log(blockNumber, formatEther(balance));

If you are using ethers, the pattern is the same idea: create a provider pointed at the endpoint, then call read methods. The important part is that the endpoint URL and chain ID agree.

Methods you will actually use on BSC

Because BSC is EVM-compatible, the standard Ethereum JSON-RPC method set applies. The table below groups the methods that come up most often and notes where BSC-specific behavior tends to surprise people.

Two of these deserve extra attention. First, eth_getLogs is the method most likely to hit a limit, because wide block ranges and broad topics are expensive to serve. If your indexer queries large ranges, expect to paginate and to need an endpoint that supports your query pattern. Second, eth_subscribe requires a WebSocket connection, so confirm your endpoint supports ws before you design around live events.

Debugging the errors you will actually hit

Most early BSC integration problems fall into a small number of categories. Match the symptom to the likely cause before you change code.

A few of these are worth expanding. Rate-limit responses are not a bug in your code, they are a capacity signal. If you see them under normal load, your request pattern has outgrown a shared endpoint. Nonce errors usually mean your local nonce tracking drifted from the chain, so re-read the pending nonce before broadcasting. And revert errors from eth_call are normal contract behavior, not an RPC failure, so decode them rather than retrying blindly.

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

A shared public endpoint is a good default for development, low-volume reads, and prototypes. It gets you to a working integration quickly and lets you validate request shapes before you commit to infrastructure.

The picture changes as soon as you have production traffic. Signals that you have outgrown a shared endpoint include:

• Frequent rate-limit responses during normal operation.
• eth_getLogs queries that need wide block ranges or long lookbacks.
• Archive reads against historical state.
• WebSocket subscriptions that must stay connected for long periods.
• A need to isolate your traffic so another tenant's load cannot affect your latency.

At that point the practical options are a managed RPC API with higher limits or dedicated node infrastructure that you control. OnFinality offers both for BNB Smart Chain, so you can start on a shared endpoint and move to dedicated capacity without changing your application code, only your configuration. See RPC pricing for how the tiers differ and supported RPC networks for the full list of chains.

Production readiness checklist

Before you point real users at your BSC integration, confirm the following:

1. Mainnet and testnet endpoints are separate in your config, with no shared secrets.
2. You have a fallback endpoint or retry strategy for transient failures.
3. eth_getLogs queries are paginated and bounded.
4. WebSocket clients reconnect with exponential backoff.
5. You monitor block height and error rates, not just HTTP status codes.
6. Your nonce handling re-reads from the node before resending.
7. You have decided whether you need archive access and dedicated capacity.

A simple monitoring probe can catch most issues early. Poll eth_blockNumber on a schedule and alert if it stops advancing or if error rates climb:

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

If the block number stalls or the endpoint starts returning errors, that is your signal to investigate before users notice.

Key Takeaways

• BNB Smart Chain mainnet uses chain ID 56 (0x38) and testnet uses 97 (0x61).
• BSC is EVM-compatible, so standard Ethereum JSON-RPC methods apply.
• Confirm the endpoint with eth_chainId and eth_blockNumber before building.
• eth_getLogs and eth_subscribe are the methods most likely to hit endpoint limits.
• Rate-limit responses are a capacity signal, not a code bug.
• Shared endpoints suit development; production workloads often need dedicated capacity.
• OnFinality provides BNB Smart Chain RPC API access and dedicated nodes if you want managed infrastructure.

Frequently Asked Questions

What is the BNB Smart Chain chain ID?

Mainnet is 56, which is 0x38 in hex. Testnet is 97, or 0x61.

Is BSC JSON-RPC the same as Ethereum JSON-RPC?

Largely yes, because BSC is EVM-compatible. The same method names apply, though individual endpoints may differ in which methods and block ranges they support.

Why does my eth_getLogs call fail on BSC?

Wide block ranges and broad topic filters are expensive to serve, so many endpoints cap the range. Reduce the range and paginate your queries.

Do I need a WebSocket endpoint for BSC?

Only if you want push-based updates such as new blocks or logs. Standard reads work over HTTP. Confirm your endpoint supports ws before designing around subscriptions.

When should I move off a public endpoint?

When you see rate limits under normal load, need archive data, run wide log queries, or want traffic isolation. At that point, compare managed RPC API tiers and dedicated nodes.