What RPC URL should you use for BNB Smart Chain?

If you are wiring a wallet, a script, or a backend service to BNB Smart Chain, the first thing you need is a working RPC URL. This page gives you the exact endpoint, the chain settings that must match it, and a practical way to decide whether a public endpoint is enough or whether your workload needs dedicated node infrastructure.

The endpoint and chain settings at a glance

The most common reason this lookup fails is a mismatch between the RPC URL and the chain ID. BNB Smart Chain mainnet and testnet are different networks with different IDs, different native tokens, and different explorers. Mixing them produces confusing errors such as transactions that never confirm or balances that look empty.

Use the mainnet row for real funds and production traffic. Use the testnet row while you are developing, and remember that testnet tokens have no value and must come from a faucet.

Which endpoint fits your workload

Before you copy a URL into a config file, decide what kind of traffic you are sending. The right choice depends less on the chain and more on your access pattern.

• One-off scripts and local development. A public endpoint is usually fine. You are sending a handful of requests and you do not need guarantees about throughput.
• Wallets and small dApps. A shared public endpoint can work for light read traffic, but you should plan for the moment your user count grows and requests start competing for capacity.
• Indexers, bots, and backends that poll blocks or logs. These workloads send steady, high-volume requests and often need archive data. This is where a managed RPC API or a dedicated node becomes the sensible default.
• Trading and latency-sensitive services. If your application reacts to new blocks or pending transactions, you want predictable access and WebSocket support rather than a best-effort public URL.

If you are unsure, start on a public endpoint to validate your integration, then move to a managed or dedicated plan before you ship to real users. You can compare options on the RPC pricing page and review the full list of supported RPC networks.

Adding BNB Smart Chain to a wallet

Most wallets accept a custom network. The fields map directly to the settings table above. In MetaMask-style wallets, open the network selector, choose "Add network" or "Add a network manually," and fill in:

• Network name: BNB Smart Chain
• New RPC URL: https://bnb.api.onfinality.io/public
• Chain ID: 56
• Currency symbol: BNB
• Block explorer URL: https://bscscan.com

If the wallet rejects the network, the usual cause is a chain ID that does not match the RPC URL, or a trailing space pasted into the URL field. Re-copy the endpoint and try again.

Calling BNB Smart Chain over JSON-RPC

BNB Smart Chain is EVM-compatible, so the JSON-RPC surface matches what you already know from Ethereum. A quick way to confirm your endpoint is live is to ask for the chain ID and the latest block number.

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 the chain ID in hex, so mainnet returns 0x38 (56 in decimal). To check that you are following the chain head, request the latest block:

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

In JavaScript, the same check looks like this with a plain fetch call, which is useful when you want to verify an endpoint before adding a library:

const RPC_URL = "https://bnb.api.onfinality.io/public";

async function checkEndpoint() {
  const res = await fetch(RPC_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "eth_getBalance",
      params: ["0x0000000000000000000000000000000000000000", "latest"]
    })
  });
  const data = await res.json();
  console.log("balance:", data.result);
}

checkEndpoint();

For libraries such as ethers or viem, you pass the same URL as the transport. The endpoint does not change between raw JSON-RPC and a library; only the calling convention does.

Reading logs and history without surprises

Two request types cause most BNB Smart Chain integration problems: log queries and historical state reads.

eth_getLogs lets you pull events for a contract over a block range. Public endpoints commonly cap how wide that range can be, because a very large range is expensive to serve. If your query returns an error about the range being too large, narrow it and paginate. If you need wide ranges regularly, that is a signal that your workload belongs on a managed or dedicated plan rather than a shared public URL.

Historical reads, such as asking for a balance at an old block, require archive data. A standard node keeps recent state and prunes older state, so a request for a block far in the past may fail even though the endpoint is healthy. If your application needs deep history, confirm archive support before you commit to a provider.

When a public endpoint stops being enough

A public RPC URL is a shared resource. It is excellent for getting started and for low-volume reads, but it is not designed to absorb your production traffic. The symptoms of outgrowing it are consistent and easy to recognize:

• Requests intermittently time out during busy periods.
• You hit rate limits exactly when your users are most active.
• Log queries fail because the block range is too wide.
• You need WebSocket subscriptions for real-time updates.
• You need archive or trace data that a shared endpoint does not expose.

When you see these, the fix is not a different public URL. It is dedicated capacity. OnFinality provides RPC API access and dedicated node infrastructure, so you can move from a shared endpoint to a plan that matches your request volume and data needs. Dedicated nodes give your traffic its own resources, which removes the contention you feel on a shared endpoint. You can read more about that option on the dedicated node page.

A short migration checklist

Moving from a public URL to managed or dedicated access is mostly a configuration change, but a few steps prevent downtime:

1. Stand up the new endpoint alongside the old one and run both in parallel.
2. Point a small percentage of traffic at the new endpoint and compare responses.
3. Confirm the methods you rely on are supported, including any archive or WebSocket needs.
4. Add a fallback endpoint so a single provider issue does not take you offline.
5. Monitor error rates and latency before and after the switch.
6. Retire the public URL once the new endpoint is stable.

Keeping a fallback is worth the small extra effort. Even a well-run endpoint benefits from a second path, and failover logic is far easier to add before an incident than during one.

Common failure modes and how to read them

Most of these are configuration issues rather than chain problems. Reading the error message carefully usually points straight at the fix.

Key Takeaways

• The BNB Smart Chain mainnet RPC URL is https://bnb.api.onfinality.io/public, with chain ID 56 and BNB as the native token.
• The testnet RPC URL is https://bnb-testnet.api.onfinality.io/public, with chain ID 97 and tBNB.
• Always match the RPC URL to the correct chain ID; mismatches cause the most common integration errors.
• Public endpoints suit development and light reads; high-volume, archive, or WebSocket workloads belong on managed or dedicated infrastructure.
• Keep a fallback endpoint and monitor error rates before and after any migration.

Frequently Asked Questions

What is the RPC URL for BNB Smart Chain? The mainnet endpoint is https://bnb.api.onfinality.io/public. It supports HTTP and WebSocket transport and uses chain ID 56.

What is the BNB Smart Chain chain ID? Mainnet uses chain ID 56. The testnet uses chain ID 97. The chain ID must match the RPC URL you configure.

What is the BNB testnet RPC URL? Use https://bnb-testnet.api.onfinality.io/public with chain ID 97 and the tBNB token. Testnet tokens come from a faucet and have no value.

Can I use a public RPC URL in production? You can, but shared public endpoints are not built for sustained high-volume traffic. If you see timeouts, rate limits, or log-range errors, move to a managed or dedicated plan.

Does BNB Smart Chain support WebSocket? Yes. The mainnet endpoint supports WebSocket transport, which is useful for subscriptions and real-time updates. Confirm transport support for any endpoint you adopt.

Why does my balance show as zero? The most common reasons are pointing at the testnet instead of mainnet, or using an address with the wrong checksum. Verify the endpoint and the address format.

Next steps

Start by validating your integration against the public endpoint, then decide whether your traffic profile needs more. If you are sending steady block or log queries, running a bot, or serving real users, look at RPC pricing to compare plans and review the BNB Smart Chain network page for endpoint details. If you need your own resources, dedicated nodes remove the contention of a shared URL. For everything else OnFinality supports, browse the full list of supported RPC networks.