What is the BNBChain list and how do BNB Smart Chain and application sidechains fit together?

The BNBChain list is a common way developers refer to the set of networks, chain IDs, and RPC endpoints that make up the BNB Chain ecosystem. At the center is BNB Smart Chain (BSC), an EVM-compatible chain that runs the BNB Chain Native Token (BNB) and hosts most DeFi, NFT, and gaming activity. Around it sit application sidechains, Layer 2 networks, and testnets that share tooling, bridges, and sometimes validators with BSC.

If you searched for a BNBChain list, you probably need one of three things: the correct chain ID and RPC URL for a wallet or backend, a way to tell which sidechains are worth supporting, or a reliable endpoint for production traffic. This page gives you the practical reference first, then explains how to connect and when to move off public endpoints.

Decision guide: public endpoint, managed RPC, or dedicated node

Before you copy an endpoint into your config, decide what kind of workload you are running. The right choice depends on request volume, whether you need archive data or WebSocket subscriptions, and how much downtime your app can tolerate.

OnFinality provides both an RPC API service and dedicated node infrastructure for BNB Chain. You can start with a shared endpoint and move to a dedicated node when your request profile outgrows it. See RPC pricing for plan shapes and supported RPC networks for the full list of chains.

BNB Smart Chain settings at a glance

BNB Smart Chain mainnet is the chain most developers mean when they say "BSC". Use these values in wallets, Hardhat, Foundry, ethers, viem, or any JSON-RPC client.

The testnet uses chain ID 97, the tBNB currency symbol, and the explorer at https://testnet.bscscan.com. Its public endpoint is https://bnb-testnet.api.onfinality.io/public. Keep mainnet and testnet configs in separate files so you never ship a testnet chain ID to production.

Connecting a wallet or client to BNB Smart Chain

Most connection problems come from a mismatched chain ID or a stale RPC URL. A minimal wallet network configuration 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 the hexadecimal form of chain ID 56. Wallets expect hex, while most SDK configs expect decimal. Mixing the two is a frequent source of "wrong network" errors.

For a quick JSON-RPC check from the terminal, call eth_chainId and confirm it returns 0x38:

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

If you are building with viem, the same check happens at client creation:

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

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

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

What "application sidechain" means in the BNBChain list

The BNBChain list is not a single chain. It groups BNB Smart Chain with networks that extend or specialize it. In practice you will see a few categories:

• BNB Smart Chain mainnet and testnet. The base EVM chain and its test environment.
• Application sidechains. Purpose-built chains that may use BNB Chain tooling, bridges, or validators but run their own consensus and block production.
• Layer 2 and scaling networks. Rollups or side systems that settle to BSC or another chain and expose EVM-compatible RPC.
• Opcodes and compatibility notes. Details on which EVM versions, precompiles, and gas rules each network supports.

When you read a BNBChain list, check four fields before you add a network to your app: chain ID, RPC URL, explorer URL, and native currency. If any of those are missing or inconsistent across sources, treat the network as unverified and test it on a small transaction first.

Choosing an RPC endpoint for BSC and sidechains

Public endpoints are convenient, but they are shared. That means your request rate is affected by everyone else using the same URL, and you have no control over maintenance windows. For prototypes this is fine. For anything with users, plan for the following:

1. Keyed access. Move from a public URL to an API key so your traffic is identifiable and can be supported.
2. Method coverage. Confirm the endpoint supports the methods you rely on, especially eth_getLogs, eth_call with state overrides, and debug_traceTransaction if you need traces.
3. WebSocket support. Real-time features such as pending transaction feeds or event subscriptions need wss:// transport, not just HTTP.
4. Archive depth. Historical balances and event replays require an archive node. Check that the provider exposes archive data for the block range you need.
5. Failover. Configure a secondary endpoint so a single provider issue does not take down your app.

OnFinality exposes BNB Chain over both HTTP and WebSocket, and dedicated nodes are available when you need isolated capacity. You can review the network page at BNB Chain RPC and the testnet at BNB Chain Testnet RPC.

Monitoring and debugging BSC connections

Once you are live, a few signals tell you whether your endpoint is healthy. Track request latency, error rate by method, and the gap between your last processed block and the chain head. A growing block gap usually means your endpoint is throttled or your consumer is falling behind.

A simple health probe can run on a schedule and alert when the chain ID or block height stops advancing:

async function probe(url) {
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0', id: 1,
      method: 'eth_blockNumber', params: []
    })
  })
  const { result } = await res.json()
  return parseInt(result, 16)
}

const height = await probe('https://bnb.api.onfinality.io/public')
console.log('BNB Smart Chain head:', height)

Common failure modes on BSC include eth_getLogs queries that span too many blocks, rate-limit responses during traffic spikes, and WebSocket connections that drop silently. For log queries, narrow the block range and paginate. For rate limits, add backoff and consider a dedicated node. For WebSockets, implement reconnect logic with a resubscribe step.

When to rent infrastructure instead of running your own node

Running a BNB Smart Chain node yourself gives you full control, but it also means disk, bandwidth, upgrades, and monitoring are your responsibility. BSC state grows quickly, and archive nodes need substantial storage. If your team is small or your node is not your product, renting infrastructure is usually faster and cheaper than operating it.

A dedicated node from OnFinality gives you isolated capacity and a stable endpoint without the operational overhead. This is a good fit when you have predictable high volume, need archive or trace data, or want a private endpoint that is not shared with other users. See dedicated nodes for how that works, and how to choose an RPC provider for evaluation criteria.

Migration checkpoints

If you are moving from a public endpoint to a managed or dedicated one, work through these checkpoints:

• Inventory every place your app references an RPC URL, including frontend, backend, cron jobs, and CI.
• Confirm the new endpoint supports your method mix and transport (HTTP, WebSocket, or both).
• Test with a canary: route a small percentage of traffic to the new endpoint and compare error rates.
• Set up monitoring before you cut over, not after.
• Keep the old endpoint configured as a fallback until the new one has run through a full traffic cycle.

Key Takeaways

• The BNBChain list describes BNB Smart Chain plus application sidechains, Layer 2 networks, and testnets, each with its own chain ID and RPC URL.
• BNB Smart Chain mainnet uses chain ID 56, BNB as the native token, and the explorer at bscscan.com; the testnet uses chain ID 97 and tBNB.
• Public endpoints are fine for development but shared; production apps should use keyed access, confirm method and transport support, and plan failover.
• Archive data, eth_getLogs, and WebSocket subscriptions are the features most likely to force a move to dedicated infrastructure.
• OnFinality offers BNB Chain RPC and dedicated nodes; check RPC pricing and supported RPC networks before you commit.

Frequently Asked Questions

Is BNB Smart Chain the same as BSC? Yes. BSC is the common shorthand for BNB Smart Chain, the EVM-compatible mainnet with chain ID 56.

What chain ID should I use for BNB Chain testnet? The testnet uses chain ID 97 and the tBNB currency symbol. Keep it in a separate config from mainnet.

Do I need a dedicated node for a small dApp? Not necessarily. A managed RPC API with an API key is usually enough until you hit method limits, need archive data, or require isolated capacity.

How do I know if an endpoint supports WebSockets? Check the provider documentation for a wss:// URL. If only an https:// URL is listed, assume HTTP-only and design your real-time features accordingly.

Where can I find the full list of chains OnFinality supports? See supported RPC networks for the current list, including BNB Chain and its testnet.