BNB RPC List: Which Endpoints Should Your App Connect To?

A BNB RPC list is a starting point, not a decision. The endpoint you pick determines your rate limits, whether you can query historical state, whether WebSocket subscriptions stay open, and how much of your engineering time goes into retries instead of product work.

This page gives you the concrete connection details for BNB Smart Chain mainnet and testnet, then walks through how to choose between a public endpoint, a managed RPC API, and a dedicated node. If you already know you want a managed or dedicated BNB endpoint, start at BNB Chain RPC.

Pick your endpoint type before you copy a URL

Most developers searching for a BNB RPC list are trying to unblock one of four situations. Match your situation to the row below and go straight to that section.

If you are in the first row, the public endpoint below is enough. If you are in rows two through four, the rest of this page explains what to verify before you commit.

BNB Smart Chain connection settings

These are the values your wallet, SDK, or infrastructure config needs. Chain ID mismatches are the single most common cause of "transaction failed" reports that turn out to be a network configuration problem rather than a contract problem.

Mainnet supports both HTTP and WebSocket transport through OnFinality. Testnet is HTTP-only, which matters if you are building a subscription-based feature and testing against testnet first.

A wallet network config entry looks like this:

{
  "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 reject the connection if the hex and decimal values disagree with the endpoint you point at.

Public endpoints, managed RPC, and dedicated nodes

A BNB RPC list usually mixes three very different products under one heading. They are not interchangeable, and the tradeoffs are operational rather than purely technical.

Public endpoints are shared, unauthenticated, and convenient. They are appropriate for development, wallet setup, and low-volume reads. They are not appropriate as the only endpoint behind a production app, because you have no control over how much of the shared capacity you get at any moment.

Managed RPC APIs give you an authenticated endpoint with defined method support, archive access options, and a support path. This is the common production choice for dApps, bots, and backend services that need predictable behavior without running infrastructure. OnFinality's RPC API service falls into this category, with BNB Chain available alongside other supported RPC networks.

Dedicated nodes give you capacity that is not shared with other customers. This matters when your workload is bursty in a way that shared limits cannot absorb, when you need consistent WebSocket behavior, or when you want a private path for transaction submission. See dedicated nodes for how that is provisioned.

What to verify before you commit to an endpoint

Copying a URL takes seconds. Verifying it takes a few minutes and saves days. Run through this list against any BNB endpoint you are considering, including ours.

• Method coverage. Confirm the endpoint supports the methods you actually call. eth_call, eth_getLogs, eth_getTransactionReceipt, and eth_blockNumber are table stakes. Trace and debug methods are not universally available.
• Archive depth. If you query state at an old block, you need archive access. Non-archive nodes return errors or empty results for historical queries.
• eth_getLogs range limits. Log queries over large block ranges are the most common source of timeouts on BNB Chain. Ask what range is supported per request.
• WebSocket behavior. If you subscribe to newHeads or logs, confirm the endpoint keeps connections open and how it handles idle timeouts.
• Failover story. A single endpoint is a single point of failure. Know what happens when it degrades.
• Rate limits and burst behavior. Understand both the sustained limit and whether short bursts are absorbed.

Request examples you can run now

Start with a basic health check. This confirms the endpoint is reachable and returns the current block height.

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

A successful response returns a hex block number. If you get a JSON-RPC error object instead, the endpoint is reachable but rejecting the request, which usually points to a method or parameter issue rather than connectivity.

For application code, viem is a common choice:

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('BNB Chain head:', block);

For log subscriptions over WebSocket on mainnet:

import WebSocket from 'ws';

const ws = new WebSocket('wss://bnb.api.onfinality.io/public/ws');

ws.on('open', () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_subscribe',
    params: ['newHeads']
  }));
});

ws.on('message', (data) => console.log(JSON.parse(data.toString())));

If your WebSocket connection drops repeatedly, that is a signal to look at dedicated capacity rather than retry logic.

Failure modes and what they usually mean

Most BNB RPC problems fall into a small number of categories. The symptom tells you where to look.

Nonce-related errors are common enough on BNB Chain that they deserve their own treatment. If you are seeing repeated nonce too low or nonce is already consumed errors, the issue is usually transaction management rather than the endpoint itself.

Running BNB Chain in production

Once you move past a single endpoint, the operational questions change. You are no longer asking "which URL works" but "what happens when this URL does not work."

A practical setup uses a primary managed endpoint with a secondary endpoint for failover, plus monitoring that alerts on error rate rather than just availability. A simple probe that checks block height progression catches more real incidents than a ping check:

#!/usr/bin/env bash
HEAD=$(curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | grep -o '"result":"[^"]*"')
echo "BNB head: $HEAD"

If the head stops advancing, the endpoint is degraded even if it still returns HTTP 200. Track that over time and you will catch issues before your users do.

For teams that would rather not own this, OnFinality provides managed RPC and dedicated node options for BNB Chain. Capacity and plan details are on the RPC pricing page, and the network-specific details are on BNB Chain RPC.

Key Takeaways

• BNB Smart Chain mainnet uses chain ID 56 and testnet uses chain ID 97. Getting this wrong breaks wallet connections before any contract call runs.
• A BNB RPC list mixes public, managed, and dedicated endpoints. They solve different problems and are not interchangeable.
• Public endpoints are fine for development and wallet setup. Production apps need defined method support, archive access where relevant, and a failover plan.
• eth_getLogs range limits and WebSocket idle timeouts are the two most common operational surprises on BNB Chain.
• Monitor block height progression, not just HTTP status. A reachable endpoint that has stopped syncing is still an outage.
• If your workload is bursty or latency-sensitive, evaluate dedicated nodes rather than trying to absorb limits with retries.

Frequently Asked Questions

What is the BNB Smart Chain RPC endpoint? OnFinality's public mainnet endpoint is https://bnb.api.onfinality.io/public, with WebSocket support on mainnet. Testnet uses https://bnb-testnet.api.onfinality.io/public. For production workloads, a managed or dedicated endpoint is usually the better fit.

What is the BNB Chain chain ID? Mainnet is 56 (0x38) and testnet is 97 (0x61). Wallets and SDKs need the correct value for the network you are connecting to.

Can I use a public BNB RPC endpoint in production? You can, but shared capacity means your throughput depends on other users at any given moment. Most production teams move to a managed RPC API or dedicated node once traffic becomes predictable.

Why does eth_getLogs time out on BNB Chain? BNB Chain produces blocks quickly, so a wide block range can contain a large number of logs. Splitting queries into smaller ranges, and using an endpoint with appropriate limits, resolves most of these timeouts.

Do I need an archive node for BNB Chain? Only if you query historical state or logs at old blocks. Standard nodes serve recent state; archive access is a separate capability you should confirm before relying on it.

How do I fail over between BNB RPC endpoints? Configure a primary and secondary endpoint in your client, and trigger failover on repeated errors or stalled block height rather than on a single failed request. Monitoring block progression is more reliable than checking HTTP status alone.