BNB Smart Chain Testnet RPC: Chain Settings, Faucet, and Debugging

BNB Smart Chain Testnet is the rehearsal environment for anything you plan to ship on BNB Chain. It runs the same EVM tooling as mainnet, but with chain ID 97, a separate state, and tBNB instead of BNB. If you are here, you probably need one of three things: a working RPC URL, the exact wallet network settings, or a way to debug why a request that works on mainnet is failing on testnet.

This page answers those directly, then covers the operational questions that come up once your testnet deployment starts looking like a real workload.

Chain settings at a glance

Copy these into your wallet, Hardhat config, Foundry config, or backend environment. They match the BNB Chain Testnet network definition used by OnFinality.

A quick sanity check before you wire anything up:

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

You should get back "0x61", which is 97 in hex. If you get a different chain ID, you are pointed at the wrong network — a very common cause of "my contract deployed but I cannot find it" confusion.

Is the public testnet endpoint enough for your workload?

Most developers can start on a shared public endpoint and stay there longer than they expect. Testnet traffic is usually bursty: a deploy here, a script run there, a CI job overnight. The decision is less about raw throughput and more about what happens when something goes wrong.

Use this as a quick filter:

If you are unsure, start public and measure. The moment you find yourself retrying failed requests or wondering whether a timeout was your code or the endpoint, that is the signal to look at RPC pricing and compare shared versus dedicated options.

Adding BNB Smart Chain Testnet to a wallet

In MetaMask, open the network selector, choose Add network → Add a network manually, and enter the values from the table above. The two fields people get wrong are chain ID (must be 97, not 56) and the currency symbol (tBNB).

If you prefer to add it programmatically, this is the standard wallet_addEthereumChain call:

await window.ethereum.request({
  method: 'wallet_addEthereumChain',
  params: [{
    chainId: '0x61', // 97
    chainName: 'BNB Smart Chain Testnet',
    nativeCurrency: { name: 'tBNB', symbol: 'tBNB', decimals: 18 },
    rpcUrls: ['https://bnb-testnet.api.onfinality.io/public'],
    blockExplorerUrls: ['https://testnet.bscscan.com'],
  }],
});

Note that chainId is hex here while most config files use decimal. Mixing the two is a frequent source of silent misconfiguration.

Getting tBNB from the faucet

The faucet is the first real blocker for most people. Testnet BNB is free, but faucets usually gate it behind a captcha, a minimum mainnet balance, or a daily cap per address.

A few practical notes:

• Faucet availability changes over time. If one is dry or rate-limited, try another rather than assuming testnet is down.
• Fund the address you will actually deploy from. Moving tBNB between accounts afterwards costs gas you may not have yet.
• Keep a small buffer. Contract deployment plus a few verification and interaction transactions adds up faster than a single transfer.
• If a faucet asks for a mainnet balance, that is an anti-abuse measure, not a bug.

Once you have tBNB, confirm the balance with eth_getBalance before you start debugging anything else. It removes an entire category of false alarms.

Wiring the endpoint into your tooling

Hardhat and Foundry both read a plain RPC URL, so the same endpoint works across your stack.

// hardhat.config.js
module.exports = {
  networks: {
    bscTestnet: {
      url: 'https://bnb-testnet.api.onfinality.io/public',
      chainId: 97,
      accounts: [process.env.DEPLOYER_KEY],
    },
  },
};

For viem or ethers, define the chain once and reuse it:

import { createPublicClient, http } from 'viem';

const bscTestnet = {
  id: 97,
  name: 'BNB Smart Chain Testnet',
  nativeCurrency: { name: 'tBNB', symbol: 'tBNB', decimals: 18 },
  rpcUrls: {
    default: { http: ['https://bnb-testnet.api.onfinality.io/public'] },
  },
};

const client = createPublicClient({
  chain: bscTestnet,
  transport: http(),
});

Keep the URL in an environment variable rather than hardcoding it. When you later move to a dedicated endpoint or add a fallback, you change one value instead of hunting through the codebase.

Debugging the failures you will actually hit

Testnet problems are rarely exotic. They cluster around a handful of causes, and most of them are configuration rather than infrastructure.

Two habits prevent most of these. First, log the chain ID your client actually connects to at startup — it catches misconfiguration immediately. Second, when a request fails, retry once against a different endpoint before you change your code. That single step tells you whether the problem is your application or the connection.

Testnet versus mainnet: what carries over

Testnet is close to mainnet, but not identical, and the differences matter for planning.

• State is disposable. Testnet can be reset or reorganised in ways mainnet cannot. Do not treat testnet data as durable.
• Gas behaviour differs. Fees are usually lower and more volatile. A gas strategy tuned on testnet will need review before mainnet.
• Archive and trace availability varies. If your tooling depends on historical state or trace methods, confirm support on the endpoint you plan to use rather than assuming parity with mainnet.
• Congestion patterns differ. Testnet is quieter, so a shared endpoint may feel fine there and struggle under real mainnet load.

That last point is the one that catches teams out. A testnet setup that works perfectly can still need rework when mainnet traffic arrives. If you are planning for that transition, the BNB Chain mainnet RPC page covers the production-side settings, and how to choose an RPC provider walks through the evaluation criteria.

When to move off the shared endpoint

Shared public endpoints are genuinely useful, and OnFinality runs one for BNB Chain Testnet so you can get started without an account. They are not the right long-term home for every workload, though.

Consider a dedicated node when:

• Your CI or staging environment generates steady, parallel traffic.
• You rely on log queries, trace methods, or archive data that shared endpoints may limit.
• You need consistent behaviour for a demo, an audit, or a partner integration.
• You want isolation from other users' traffic patterns.

OnFinality provides both RPC API access and dedicated node infrastructure, so you can start on the shared endpoint and move to a dedicated node without changing your application code — only the URL. You can review the full set of supported RPC networks to see where BNB Chain Testnet fits alongside the other chains you run.

Key Takeaways

• BNB Smart Chain Testnet uses chain ID 97 and the native token tBNB.
• A working public endpoint is https://bnb-testnet.api.onfinality.io/public; verify it with eth_chainId returning 0x61.
• Most testnet failures are configuration issues — wrong chain ID, no faucet funds, or a stale nonce — not infrastructure outages.
• Keep your RPC URL in an environment variable and configure a fallback before you need one.
• Shared endpoints suit manual testing and light CI; dedicated nodes suit sustained, parallel, or log-heavy workloads.
• Testnet behaviour does not fully predict mainnet behaviour, especially around gas and congestion.

Frequently Asked Questions

What is the chain ID for BNB Smart Chain Testnet?

97, which is 0x61 in hex. If your client reports 56, you are connected to BNB Chain mainnet.

What is the BNB Smart Chain Testnet RPC URL?

OnFinality's public endpoint is https://bnb-testnet.api.onfinality.io/public. You can also use a dedicated endpoint if you need isolation or higher sustained throughput.

How do I get testnet BNB?

Use a BNB Chain testnet faucet. Availability and rate limits change, so if one faucet is unavailable, try another. Fund the address you will deploy from and keep a small buffer for gas.

Why does my transaction keep failing on testnet?

Check three things in order: the chain ID your client is connected to, your tBNB balance, and your nonce. These account for the large majority of testnet transaction failures.

Can I use the same code on mainnet and testnet?

Yes, if you keep the RPC URL and chain ID in configuration rather than hardcoded. Review gas assumptions and any archive or trace dependencies before switching to mainnet.

Does OnFinality support BNB Chain Testnet?

Yes. See the BNB Chain Testnet network page for endpoint details, and RPC pricing for plan options.