BNB Smart Chain Testnet RPC and Chain Settings: How Do I Connect?

Chain settings at a glance

If you only need the values to paste into a wallet or a config file, here they are. BNB Smart Chain Testnet is the BSC test environment that mirrors mainnet behavior closely enough to validate contracts, wallets, indexers, and bots before you deploy to production.

A quick sanity check before you go further: mainnet BSC uses chain ID 56 and the BNB symbol, while testnet uses chain ID 97 and tBNB. Mixing those two up is the most common cause of "wrong network" errors, empty balances, and transactions that appear to succeed but never show up where you expect.

When a public testnet endpoint is enough, and when it is not

The public endpoint above is fine for learning, quick scripts, and low-volume CI runs. It is not the right long-term answer for every workload. Use this to decide what to do next.

• Local development and one-off scripts: a public endpoint is usually sufficient. You are sending a handful of requests per minute and you do not care about shared throughput.
• CI pipelines that run on every pull request: shared endpoints can be rate-limited or slow under load, which makes flaky tests. Consider a dedicated endpoint so test runs are isolated from other traffic.
• Indexers, subgraphs, and backfill jobs: these issue large eth_getLogs ranges and archive-style queries. Public endpoints often cap range size or block history. A dedicated node with archive access is the safer fit.
• Trading bots and load tests: if you are simulating production traffic against testnet, you want predictable throughput and your own connection budget. Shared public endpoints are not designed for that.
• Wallet and dApp QA: a public endpoint is fine for manual testing, but if your QA team runs parallel sessions, a dedicated endpoint avoids one tester starving another.

If any of the last four apply, look at dedicated nodes and RPC pricing before you build around a shared endpoint. For a broader comparison of endpoint types, see how to choose an RPC provider.

Adding BNB Smart Chain Testnet to a wallet

Most EVM wallets accept the same fields. In MetaMask, open the network selector, choose "Add network" or "Add a network manually", and enter the values from the table above. The wallet will call eth_chainId against the RPC URL to confirm it returns 0x61 (97 in decimal) before saving.

If you are configuring a wallet programmatically, the standard wallet_addEthereumChain payload looks like this:

{
  "method": "wallet_addEthereumChain",
  "params": [
    {
      "chainId": "0x61",
      "chainName": "BNB Smart Chain Testnet",
      "nativeCurrency": {
        "name": "BNB Chain Native Token",
        "symbol": "tBNB",
        "decimals": 18
      },
      "rpcUrls": ["https://bnb-testnet.api.onfinality.io/public"],
      "blockExplorerUrls": ["https://testnet.bscscan.com"]
    }
  ]
}

Note that chainId is hex-encoded here (0x61), while most config files and dashboards expect the decimal 97. Both refer to the same network; the mismatch only matters when a tool silently expects one format.

Wiring the endpoint into your code

For JavaScript and TypeScript projects, point your client at the testnet endpoint and pass chain ID 97. With viem:

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

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

const blockNumber = await client.getBlockNumber()
console.log('BSC testnet head:', blockNumber)

With ethers v6:

import { JsonRpcProvider } from 'ethers'

const provider = new JsonRpcProvider(
  'https://bnb-testnet.api.onfinality.io/public',
  { chainId: 97, name: 'bnb-testnet' }
)

const network = await provider.getNetwork()
console.log('chainId:', network.chainId.toString())

For a raw check without any library, a single curl request is enough to confirm the endpoint is responding and on the right chain:

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

The response should be {"jsonrpc":"2.0","id":1,"result":"0x61"}. If you get a different chain ID, you are pointed at the wrong network. If you get a transport error, the endpoint is unreachable from your environment — check firewall rules, VPNs, and outbound HTTPS before debugging your contract code.

Getting tBNB and testing real flows

Testnet BNB (tBNB) has no monetary value and is distributed through faucets. Faucet policies change, so treat any specific faucet as a starting point rather than a permanent dependency: search for the current BSC testnet faucet, connect a wallet, and request a small amount. Some faucets require a minimum mainnet balance or a social login to reduce abuse.

Once you have tBNB, the useful test flows are:

1. Deploy a contract and read it back through the same RPC endpoint you will use in production.
2. Send a transfer and watch it confirm on testnet.bscscan.com.
3. Trigger the event-heavy paths in your app and confirm your indexer or listener picks them up.
4. Run your error paths — reverts, out-of-gas, nonce conflicts — against testnet before they ever happen on mainnet.

If your app relies on WebSocket subscriptions, confirm whether your endpoint supports them. The public HTTP endpoint above is HTTP JSON-RPC; for subscription-style workloads, check the BNB Chain Testnet network page and BNB Chain mainnet page for current transport details, and consider a dedicated node if you need persistent WebSocket connections.

Debugging the errors you will actually hit

A useful habit: when something fails, first run eth_chainId and eth_blockNumber against your endpoint. That tells you whether the problem is connectivity/network selection or your application logic, and it takes seconds.

Moving from testnet to mainnet without surprises

Testnet and mainnet share the same EVM semantics, but not the same state, addresses, or economics. Before you switch, work through this checklist:

• Replace chain ID 97 with 56 and tBNB with BNB everywhere in config.
• Swap testnet contract addresses for mainnet deployments; do not assume the same addresses exist.
• Re-check gas assumptions — mainnet gas markets behave differently from testnet.
• Confirm your RPC endpoint and transport for mainnet; see the BNB Chain network page.
• Re-run your monitoring and alerting against the mainnet endpoint before real traffic arrives.

If you want the same provider and tooling across both environments, OnFinality offers BNB Chain testnet and mainnet endpoints through the same RPC API service, so you can keep your integration code identical and only change the URL and chain ID. A full list of environments is on the supported RPC networks page.

Key Takeaways

• BNB Smart Chain Testnet uses chain ID 97, symbol tBNB, and explorer testnet.bscscan.com.
• The public endpoint https://bnb-testnet.api.onfinality.io/public is enough for learning and light scripts, but shared endpoints are not built for heavy or parallel workloads.
• Always verify chain ID with eth_chainId before debugging application code.
• Faucet availability changes; treat any faucet as a starting point and confirm balances on the testnet explorer.
• For indexers, bots, CI, and load tests, evaluate dedicated nodes and RPC pricing rather than stretching a public endpoint.
• Keep testnet and mainnet configs separate, and re-verify addresses, gas, and endpoints when you promote to mainnet.

Frequently Asked Questions

What is the chain ID for BNB Smart Chain Testnet?

BNB Smart Chain Testnet uses chain ID 97 (hex 0x61). Mainnet BSC uses chain ID 56. Using the wrong one is the most common cause of "wrong network" and empty-balance confusion.

What is the RPC URL for BNB Smart Chain Testnet?

A public HTTP JSON-RPC endpoint is https://bnb-testnet.api.onfinality.io/public. You can also run your own node or use a dedicated endpoint if you need isolated throughput or archive access.

What is the native token on BSC testnet?

The native currency is tBNB, with 18 decimals. It has no monetary value and is obtained from testnet faucets.

Does the public endpoint support WebSocket subscriptions?

The public endpoint shown here is HTTP JSON-RPC. If your application relies on WebSocket subscriptions, check the BNB Chain Testnet network page for current transport support and consider a dedicated node for persistent connections.

Why does eth_getLogs fail on testnet?

Large block ranges are often rejected by shared endpoints. Reduce the range, paginate your queries, or move to a dedicated or archive node that can handle wider ranges.

Can I use the same code for testnet and mainnet?

Yes, if you keep the chain ID, RPC URL, and contract addresses in configuration. The EVM behavior is the same; the state, addresses, and economics are not. OnFinality provides both BNB Chain Testnet and BNB Chain endpoints so the integration pattern stays consistent.