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

Quick decision guide: which BNB Smart Chain RPC endpoint should you use?

Before you copy an endpoint into your wallet or dApp, decide which type of RPC access matches your workload. The choice affects reliability, cost, and how much debugging you will do later.

• Prototyping or light usage: A public endpoint such as https://bnb.api.onfinality.io/public is enough for wallet setup, small scripts, and test transactions. Public endpoints are shared and may throttle bursts, so they are not a stable base for production apps.
• Production dApp or indexer: A managed RPC service with dedicated throughput and support is safer. You get consistent performance, access to archive data, and a team that handles node maintenance. See RPC pricing for options.
• High-throughput or data-heavy workloads: If you poll eth_getLogs, run an indexer, or serve many users, evaluate dedicated nodes. They isolate your traffic from other tenants and reduce the risk of rate limiting.

If you are still evaluating providers, read how to choose an RPC provider for a broader framework. For BNB Chain specifics, the rest of this article gives you the chain settings, request examples, and failure modes you will encounter.

BNB Smart Chain at a glance

BNB Smart Chain (BSC) is an Ethereum Virtual Machine (EVM) compatible blockchain that runs in parallel with BNB Chain's staking chain. Because it is EVM compatible, you can use standard Ethereum JSON-RPC methods, tools like ethers.js and viem, and wallet configuration patterns you already know.

Key facts for RPC integration:

• Chain ID: 56 (mainnet), 97 (testnet)
• Native token: BNB (18 decimals)
• Explorer: BscScan
• Consensus: Proof of Staked Authority (PoSA), which produces fast blocks (~3 seconds)

The fast block time means your application will send more transactions per minute than on Ethereum, so your RPC endpoint needs to handle a higher request rate for the same user activity.

Chain settings for wallets and dApps

When you add BNB Smart Chain to MetaMask or configure a dApp, you need the correct network parameters. The table below shows the values for mainnet and testnet.

Use the testnet for development and staging. The testnet uses the same RPC interface, so code that works there should work on mainnet with only the endpoint and chain ID changed.

Wallet configuration example

If you are adding BNB Smart Chain to a wallet manually, the JSON below shows the typical structure used by wallet providers.

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

Note that chainId is in hexadecimal: 0x38 equals 56. Many wallet errors come from using the decimal chain ID in a field that expects hex.

Sending your first JSON-RPC request

The quickest way to verify an endpoint is to send a eth_chainId request with curl. This confirms that the endpoint is reachable and returns the expected chain.

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

A successful response looks like this:

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

The result 0x38 is hexadecimal for 56, confirming you are on BNB Smart Chain mainnet.

To get the latest block number, use eth_blockNumber:

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

Using ethers.js and viem

Most developers interact with BNB Smart Chain through a library. Here is a minimal example using ethers.js v6 to read the latest block.

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider('https://bnb.api.onfinality.io/public');
const blockNumber = await provider.getBlockNumber();
console.log('Latest block:', blockNumber);
```n
And the same with viem:

```javascript
import { createPublicClient, http } from 'viem';

const client = createPublicClient({
  chain: {
    id: 56,
    name: 'BNB Smart Chain',
    nativeCurrency: { name: 'BNB', symbol: 'BNB', decimals: 18 },
    rpcUrls: { default: { http: ['https://bnb.api.onfinality.io/public'] } }
  },
  transport: http()
});

const blockNumber = await client.getBlockNumber();
console.log('Latest block:', blockNumber);

Both libraries handle JSON-RPC formatting and error parsing for you, but you still need to configure the correct chain ID and endpoint.

WebSocket support for real-time data

If your application needs real-time updates, such as pending transactions or new blocks, use a WebSocket endpoint. BNB Smart Chain supports WebSocket connections, and OnFinality provides a WebSocket URL for the network.

A WebSocket subscription example using ethers.js:

import { WebSocketProvider } from 'ethers';

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

provider.on('block', (blockNumber) => {
  console.log('New block:', blockNumber);
});

WebSocket connections are stateful and consume more resources on the server. For production, ensure your provider supports WebSocket with adequate connection limits. See the BNB Chain network page for details on transport support.

Common failure modes and how to debug them

Even with a correct endpoint, you will run into issues. Here are the most common failure modes when working with BNB Smart Chain RPC and how to diagnose them.

Debugging a transaction that fails

When a transaction fails, the first step is to get the transaction receipt and look at the status field. A status of 0x0 means the transaction reverted.

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

If the receipt shows a revert, use eth_call to simulate the transaction and capture the revert reason. Many libraries provide a call method that returns the reason string.

Public vs managed endpoints: what changes for production

Public endpoints are convenient for development, but they come with tradeoffs that affect production apps.

• Shared resources: Public endpoints are used by many developers. Heavy usage by others can slow your requests or cause rate limiting.
• No SLA: Public endpoints typically do not offer uptime guarantees or support. If the endpoint goes down, you have no recourse.
• Limited data: Some public endpoints do not support archive requests or WebSocket subscriptions reliably.

Managed RPC services, such as OnFinality's API service, provide dedicated or shared infrastructure with defined limits, monitoring, and support. For production workloads, you should evaluate whether a managed service meets your needs.

When comparing providers, consider:

• Throughput and rate limits: What is the maximum requests per second? Are there burst limits?
• Data availability: Do you need archive data or trace methods?
• WebSocket support: Are WebSocket connections allowed and what is the limit?
• Failover: Does the provider route around node failures automatically?
• Support: Can you reach a human when something breaks?

OnFinality offers both shared and dedicated nodes for BNB Chain. Dedicated nodes give you isolated resources, which is important for high-throughput or latency-sensitive applications.

Monitoring your RPC health

Once your application is live, monitor the health of your RPC connection. A simple health check is to send a lightweight request periodically and measure the response time.

while true; do
  start=$(date +%s%N)
  response=$(curl -s -X POST https://bnb.api.onfinality.io/public \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}')
  end=$(date +%s%N)
  echo "Response: $response"
  echo "Latency: $(( (end - start) / 1000000 )) ms"
  sleep 10
done

Set up alerts for latency spikes, error rates, and nonce errors. If you see repeated nonce too low errors, your transaction management logic may need to handle pending transactions more carefully.

Key Takeaways

• BNB Smart Chain is EVM-compatible, so standard Ethereum JSON-RPC methods and tools work.
• Use the correct chain ID (56 for mainnet, 97 for testnet) and endpoint to avoid configuration errors.
• Public endpoints are fine for development, but production apps should consider managed or dedicated infrastructure for reliability and support.
• Debug common issues by checking chain ID, nonce, balance, and using eth_call to simulate transactions.
• Monitor your RPC health with simple scripts and set up alerts for anomalies.

Frequently Asked Questions

What is the RPC URL for BNB Smart Chain?

The public RPC URL for BNB Smart Chain mainnet is https://bnb.api.onfinality.io/public. For testnet, use https://bnb-testnet.api.onfinality.io/public.

What is the chain ID for BNB Smart Chain?

The chain ID is 56 for mainnet and 97 for testnet. In hexadecimal, 56 is 0x38.

Can I use Ethereum tools with BNB Smart Chain?

Yes, because BNB Smart Chain is EVM-compatible. Libraries like ethers.js and viem work with minimal configuration changes.

How do I get test BNB for the testnet?

You can request test BNB from a testnet faucet. Check the BNB Chain Testnet page for guidance.

What should I do if I get rate limited on a public endpoint?

Reduce your request rate, implement caching, or upgrade to a managed RPC service with higher limits. See RPC pricing for options.

Does OnFinality support WebSocket for BNB Smart Chain?

Yes, OnFinality supports WebSocket transport for BNB Smart Chain. Use the WebSocket URL wss://bnb.api.onfinality.io/public for real-time subscriptions.

For a full list of supported networks, visit supported RPC networks.