BSC Testnet: Chain Settings, Faucet, and RPC Endpoint Setup

BSC Testnet chain settings at a glance

These are the values you need to add BSC Testnet to a wallet or point a client at it. Chain ID 97 is the field that actually distinguishes this network from BNB Smart Chain mainnet (chain ID 56), so verify it in every config file and wallet screen.

If a tool asks for a network name, "BNB Smart Chain Testnet" and "BSC Testnet" are both accepted in practice; the name is cosmetic, the chain ID is not.

Add BSC Testnet to MetaMask without breaking mainnet

The most common wallet mistake is editing the existing BNB Smart Chain mainnet entry instead of adding a new network. Add BSC Testnet as a separate network so mainnet stays intact and your wallet clearly shows which chain you are on.

In MetaMask, open the network selector, choose Add network, then Add a network manually, and fill in the chain settings from the table above. Save, switch to the new network, and confirm the chain ID reads 97 in the network details. If you use a different wallet, the field names vary but the values are the same.

• Do not overwrite the mainnet BNB Smart Chain entry — add a new network instead.
• After saving, switch networks and re-check the chain ID; some wallets cache the previous chain.
• If the wallet shows a balance of 0 tBNB, that is expected until you claim from the faucet.
• Keep a separate account for testnet work so test transactions never mix with mainnet history.

Get tBNB from the faucet

BSC Testnet gas is paid in tBNB, which you get from the official BNB Chain testnet faucet. The faucet is rate-limited and may require a small mainnet BNB balance or a wallet connection to deter abuse, so plan faucet claims before a CI run rather than during it.

tBNB has no real value. Do not buy it, do not bridge real assets to testnet expecting to recover them, and do not treat testnet balances as production data. If you need larger amounts for load testing, request through the faucet's documented channels rather than scripting repeated claims.

• Claim tBNB to the same address your deployment scripts use.
• Fund the deployer account first; contract calls fail without gas.
• Faucet limits reset on a schedule — check the faucet page for current rules.
• Keep a small buffer of tBNB for failed-transaction gas and nonce retries.

Point Hardhat, Foundry, viem, or ethers at a BSC Testnet RPC

Once the wallet is set up, the next step is wiring your tooling to a JSON-RPC endpoint. The pattern is the same across frameworks: store the RPC URL in an environment variable, set chain ID 97 explicitly, and keep a separate mainnet config so a copy-paste mistake fails loudly instead of silently deploying to mainnet.

The snippets below use placeholders for the RPC URL. Replace them with the endpoint from your provider — for OnFinality, the current BSC Testnet endpoint is listed on the BNB Testnet network page.

• Hardhat: add a bscTestnet network entry with url and chainId: 97.
• Foundry: set [rpc_endpoints] bsc_testnet = "${BSC_TESTNET_RPC_URL}" in foundry.toml.
• viem: create a chain object with id: 97 and pass the transport URL.
• ethers: use new JsonRpcProvider(url, 97) so the chain ID is asserted on connect.

Debug path: when a BSC Testnet request fails

Testnet failures usually fall into a small set of causes. Work through them in order — most resolve at the first or second step, and the order saves you from chasing endpoint issues when the real problem is an empty wallet.

Start by confirming the chain ID the endpoint reports, then confirm the sender has tBNB, then look at the transaction itself. If everything on-chain looks correct but calls still fail, the endpoint is the next suspect.

When a public endpoint is not enough

Public BSC Testnet endpoints are fine for a single developer clicking through a dApp. They become a problem when several CI jobs, a staging frontend, and an indexer all share the same throttled URL. Symptoms look like flaky tests and intermittent timeouts rather than a clean error, which makes them expensive to debug.

A managed RPC endpoint gives you a URL with predictable limits and a support path when something breaks. A dedicated node goes further: isolated capacity for archive queries, log-heavy debugging, and WebSocket subscriptions that a shared endpoint may not support reliably. OnFinality offers both — start from the BNB Testnet network page for endpoint details, and see supported RPC networks for the full list.

• Single developer, occasional deploys: a public endpoint is usually enough.
• Team CI with parallel jobs: a managed endpoint avoids shared throttling.
• Archive reads, trace calls, or heavy eth_getLogs: check method support before committing.
• Long-lived WebSocket subscriptions: confirm transport support on your chosen plan.

Testnet-to-mainnet readiness checklist

BSC Testnet mirrors mainnet closely, but a passing testnet run is not proof of mainnet readiness. Before you promote a contract or service, check the items below — each one catches a class of bug that testnet alone will not surface.

The goal is not to re-test everything, but to confirm the differences between chain ID 97 and chain ID 56 are handled explicitly in your config, your gas assumptions, and your monitoring.

• Chain ID is read from config, not hardcoded in a single place that is easy to miss.
• Gas estimates and priority fees are re-measured on mainnet; testnet conditions differ.
• Contract addresses are environment-specific and not shared between testnet and mainnet.
• Explorer links and monitoring dashboards point at the correct network.
• Faucet-dependent scripts are removed or gated before production deployment.
• RPC endpoint and plan are sized for expected mainnet traffic, not testnet traffic.

Frequently Asked Questions