BNB Smart Chain RPC: Endpoint Settings, Chain ID, and Debugging

BNB Smart Chain (BSC) speaks the same JSON-RPC dialect as Ethereum, which is why most developers can connect existing EVM tooling to it with a single URL change. The friction usually shows up later: a wallet that silently points at the wrong chain, a eth_getLogs call that times out, or a WebSocket subscription that drops under load. This page gives you the endpoint settings first, then the debugging path and the decision points for production.

Chain settings at a glance

Use these values when you add BSC to a wallet, a library, or a backend config. They match the network's canonical EVM parameters.

If you are building on testnet, keep the two configs separate in your codebase. A surprising number of "transaction failed" reports come from a testnet private key being used against a mainnet endpoint, or the reverse.

Pick the right connection type before you write code

Before copying an endpoint, decide what kind of connection your app actually needs. This is the choice that determines cost and reliability more than any provider logo.

• Public shared endpoint — fine for scripts, prototypes, wallet testing, and low-volume reads. Not designed for sustained production traffic or large log queries.
• Managed RPC API — a keyed endpoint with higher limits, monitoring, and support. The right default for most dApps, bots, and backends. See RPC pricing for plan shapes.
• Dedicated node — your own BSC node behind a private endpoint. Choose this when you need consistent throughput, archive history, trace/debug methods, or isolation from other tenants. See dedicated nodes.

A quick rule: if your app can tolerate occasional retries and you are not running heavy eth_getLogs or WebSocket workloads, a managed RPC API is usually enough. If you are indexing, running a trading bot, or need historical state, plan for dedicated infrastructure.

Configure BSC in wallets and libraries

Wallet network config

Most EVM wallets accept a custom network object. The fields below are the ones that matter:

{
  "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 chainId is hex (0x38 = 56). Wallets that reject the network usually do so because the chain ID is decimal or the RPC URL is unreachable.

viem / ethers

Both libraries work with BSC once you supply the chain ID and transport:

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

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

const block = await client.getBlockNumber();
console.log('BSC head:', block);

For ethers v6, pass the same URL to JsonRpcProvider and confirm the reported network.chainId is 56n before sending transactions.

Raw JSON-RPC check

When something is wrong, test the endpoint directly before blaming your app:

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

A healthy response returns "result":"0x38". If you get a timeout or an HTML error page, the problem is the endpoint or the network path, not your contract call.

Methods that behave differently on BSC

BSC is EVM-compatible, but a few methods deserve attention because they are common sources of production issues.

If your workload depends on the bottom three rows, confirm support before you commit to a provider. OnFinality's BNB Smart Chain page lists the transport and endpoint details for the network.

Debug path for common BSC RPC failures

Work through these symptoms in order. Most issues resolve at the first two steps.

A useful habit: log the endpoint URL and chain ID alongside every failed request. It makes the difference between a five-minute fix and an afternoon of guessing.

When to move from a public endpoint to managed or dedicated

Public endpoints are a good starting point, but they are shared. As soon as your traffic becomes unpredictable, you start competing for capacity with everyone else on the same URL. The signals to watch:

• Increasing rate-limit responses during peak hours.
• eth_getLogs or archive queries failing intermittently.
• WebSocket subscriptions dropping without a clear network cause.
• A need for trace/debug methods that public endpoints do not expose.

At that point, a managed RPC API gives you a keyed endpoint with clearer limits and monitoring, while a dedicated node gives you isolated capacity and control over which methods and history are available. OnFinality offers both as part of its RPC API service, and you can compare plan shapes on the pricing page.

Operational checklist before you ship

• Pin the chain ID and endpoint in config, not in scattered constants.
• Add a fallback endpoint so a single provider outage does not take down the app.
• Chunk eth_getLogs calls and cap the block range per request.
• Implement reconnect logic for WebSocket subscriptions.
• Monitor error rates and latency per method, not just overall uptime.
• Keep testnet and mainnet configs strictly separate.
• Confirm archive and trace requirements early if you plan to index history.

Key Takeaways

• BNB Smart Chain uses chain ID 56 (mainnet) and 97 (testnet), with BNB as the native currency.
• The public OnFinality endpoint https://bnb.api.onfinality.io/public is fine for testing; production workloads usually need a managed or dedicated endpoint.
• eth_getLogs, archive reads, and WebSocket subscriptions are the methods most likely to force an infrastructure upgrade.
• Most "RPC errors" are actually chain ID, nonce, or gas issues — check those before changing providers.
• Use the BNB Smart Chain network page and supported networks list to confirm endpoint and transport details.

Frequently Asked Questions

What is the RPC URL for BNB Smart Chain?

The public OnFinality endpoint is https://bnb.api.onfinality.io/public. For production, use a keyed managed endpoint or a dedicated node URL from your provider dashboard.

What is the BNB Smart Chain chain ID?

Mainnet is 56 (0x38). Testnet is 97 (0x61).

Does BSC support WebSocket RPC?

Yes, BSC supports WebSocket transport, which you need for eth_subscribe. Confirm that your chosen endpoint exposes WS before relying on it.

Why does my eth_getLogs call time out on BSC?

BSC produces blocks quickly, so wide block ranges generate large result sets. Chunk the range and paginate. If it still fails, you may need a dedicated endpoint with higher limits.

Can I use Ethereum tooling with BSC?

Yes. BSC is EVM-compatible, so viem, ethers, Hardhat, and Foundry work once you set the chain ID and RPC URL.

Do I need an archive node for BSC?

Only if you query historical state or balances at old blocks. Standard nodes prune that data, so archive access requires a provider that offers it.

Next steps

If you are still prototyping, start with the public endpoint and the config snippets above. If you are preparing for production, review how to choose an RPC provider, then compare RPC pricing and dedicated node options for BSC. For testnet work, the BNB Chain Testnet page has the matching settings.