BNB Smart Chain public RPC URL: how do you connect and when should you switch?

Chain settings at a glance

If you only need one thing from this page, it is the connection detail. BNB Smart Chain mainnet uses chain ID 56, the native token BNB (18 decimals), and the block explorer at https://bscscan.com. OnFinality publishes a public HTTPS endpoint you can drop into a wallet or a script:

That single URL is enough to read balances, call eth_call, estimate gas, and broadcast signed transactions. What it is not is a capacity guarantee. A public endpoint is shared, so treat it as a starting point rather than the backbone of a production system.

When a public endpoint is the right fit

Before you copy the URL into a config file, decide which of these three situations you are in.

Prototyping and local development. You are wiring up a dApp, testing a contract, or checking a balance. A public endpoint removes the need to sync a node, which on BNB Smart Chain is a large download and ongoing operational cost. Use it, move fast, and do not over-engineer.

Wallet and manual network setup. You are adding BNB Smart Chain to a wallet or a tool that only needs occasional reads. Public RPC is a reasonable default here, and the chain ID plus explorer URL above are what most wallets ask for.

Production traffic, indexing, or trading. You are running a backend that polls blocks, an indexer that backfills history, a bot that needs low-latency writes, or a service with a support commitment. At this point shared public capacity becomes a liability: you cannot see your own usage, you cannot raise your own limits, and a noisy neighbour affects you. This is where a managed RPC API or a dedicated node starts to pay for itself. If you are weighing that step, the RPC provider selection guide walks through the criteria, and RPC pricing shows how the tiers are structured.

A useful rule: if you would be embarrassed to explain to a user why a request failed, you have outgrown the public endpoint.

Adding BNB Smart Chain to a wallet

Most wallets accept a custom network. The fields map directly to the table above. In MetaMask-style JSON, a network config looks like this:

{
  "chainId": "0x38",
  "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"]
}

Note that 0x38 is 56 in hexadecimal. Wallets expect the hex form; JSON-RPC and most SDKs expect the decimal form. Mixing the two is one of the most common setup mistakes.

For testnet work, the same pattern applies with chain ID 97, the tBNB token, the explorer at https://testnet.bscscan.com, and the testnet endpoint. See the BNB Chain Testnet RPC page for the current testnet URL.

Calling the endpoint from code

The fastest sanity check is a raw JSON-RPC call. This asks for the current block number:

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

A response with a hex result means the endpoint is reachable and serving. If you get an error object instead, check the method name and params before assuming the endpoint is down.

In a JavaScript app, you rarely call JSON-RPC by hand. With viem:

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 Smart Chain head:', block)

The same endpoint works with ethers, web3.js, and most EVM tooling, because BNB Smart Chain is EVM-compatible. That compatibility is also why the chain is attractive: existing Ethereum contracts and libraries usually port with minimal changes.

Reading logs, archive data, and subscriptions

Three workload types behave differently on a public endpoint, and they are worth understanding before you commit to one.

eth_getLogs and event indexing. Log queries are the heaviest common request. A wide block range with many matching events can be slow or rejected on a shared endpoint. If you are indexing, narrow your ranges, paginate, and expect to need a provider tier or dedicated node that tolerates sustained log queries.

Archive and historical state. Reading state at an old block requires an archive node. Not every endpoint keeps full history. If your app needs historical balances or a backfill, confirm archive support before you build on an endpoint. OnFinality's BNB Smart Chain page is the place to check current capabilities.

WebSocket subscriptions. Public HTTP endpoints are request/response. If you need eth_subscribe for new heads or pending transactions, you need a WebSocket transport. OnFinality supports HTTP and WebSocket for BNB Smart Chain, but subscription volume is exactly the kind of workload that benefits from a managed or dedicated setup rather than a shared public URL.

Failure modes and how to read them

When a request fails, the error usually points at the cause. This table maps the symptom to the likely fix.

Most of these are configuration or workload-shape problems, not endpoint outages. Diagnose the request before you blame the URL.

From public URL to production RPC

The transition is less about a single moment and more about a pattern. You start on a public endpoint, you notice that reads are cached and writes are retried, and eventually you want visibility and headroom. At that point you have two main options.

A managed RPC API gives you a keyed endpoint with your own usage, typically across many chains, and is the usual next step for apps that need reliability without running servers. A dedicated node gives you isolated capacity for workloads that are sensitive to contention, such as high-frequency trading, heavy indexing, or strict data-residency needs. Both are covered under OnFinality's API service and dedicated node offerings, and the full list of chains is on the supported RPC networks page.

A practical migration path:

1. Keep the public endpoint for local dev and CI.
2. Move staging and production reads to a keyed managed endpoint.
3. Add a fallback provider or a second region so a single endpoint is not a single point of failure.
4. Move the heaviest workload, usually indexing or trading, to a dedicated node.
5. Add monitoring on error rate and latency so you notice degradation before users do.

Key Takeaways

• BNB Smart Chain mainnet uses chain ID 56, token BNB, explorer https://bscscan.com.
• The OnFinality public endpoint is https://bnb.api.onfinality.io/public, supporting HTTP and WebSocket.
• Public endpoints are ideal for prototyping, wallet setup, and light reads, but they are shared capacity.
• Heavy eth_getLogs, archive reads, and subscriptions are the workloads that push teams toward managed or dedicated RPC.
• Testnet uses chain ID 97 and tBNB; keep mainnet and testnet configs separate.
• Most failures are configuration or workload shape, not endpoint downtime.

Frequently Asked Questions

Is the BNB Smart Chain public RPC URL free to use? It is a shared public endpoint intended for development and light use. For production traffic, a managed or dedicated plan gives you your own capacity and visibility.

What is the chain ID for BNB Smart Chain? Mainnet is 56 (0x38 in hex). Testnet is 97.

Can I use the public endpoint for WebSocket subscriptions? OnFinality supports HTTP and WebSocket for BNB Smart Chain, but sustained subscription workloads are better served by a managed or dedicated setup.

Why does my eth_getLogs call time out? The block range is usually too wide for a shared endpoint. Paginate the range and retry, or move indexing to a provider tier that handles sustained log queries.

Do I need an archive node? Only if you read historical state at old blocks. Confirm archive support on the BNB Smart Chain page before building a backfill on an endpoint.

How do I move from public RPC to production? Start with a keyed managed endpoint for staging and production, add a fallback, then move your heaviest workload to a dedicated node. See RPC pricing for the tiers.