BNB API: BSC JSON-RPC Methods and Endpoint Setup

Chain settings at a glance

Before you write any code, get the network parameters right. BSC is EVM-equivalent, so your existing Ethereum tooling works once the chain ID and endpoint are correct.

If you only need one thing from this page, it is that table. Add it to your wallet config, your Hardhat/Foundry network file, or your backend environment variables, and most "wrong network" errors disappear.

Quick recommendation: shared endpoint or dedicated node?

Most teams should start on a shared RPC API endpoint and move to a dedicated node when a specific signal appears. Use this to decide where you are today.

The decision is rarely permanent. Start shared, measure, and upgrade the workloads that actually hurt. OnFinality offers both RPC API access and dedicated nodes, so you can move between them without changing your application logic.

The BSC methods you will actually call

BSC implements the standard Ethereum JSON-RPC surface. In practice, a small subset covers almost all production traffic.

Reading state

• eth_blockNumber — current block height, useful for health checks and lag detection.
• eth_getBalance — native BNB balance for an address.
• eth_getTransactionCount — nonce, needed before signing.
• eth_call — execute a read-only contract call without a transaction.
• eth_getCode and eth_getStorageAt — contract bytecode and raw storage slots.
• eth_getBlockByNumber — block header and, optionally, full transactions.

Reading logs and receipts

• eth_getLogs — the workhorse for indexers, but also the most common source of timeouts and range errors.
• eth_getTransactionReceipt — confirm inclusion and read emitted events.

Writing

• eth_sendRawTransaction — submit a signed transaction. Note that BSC does not support eth_sendTransaction on most hosted endpoints, so sign client-side.
• eth_gasPrice and eth_estimateGas — fee and gas estimation before signing.

Chain metadata

• eth_chainId — confirm you are on 56 or 97.
• net_version — legacy network identifier, still used by some tooling.

BSC-specific behavior worth knowing: block times are short, gas is cheap, and the mempool sees a high volume of transactions. That combination means nonce management and gas pricing matter more than on quieter chains.

Endpoint setup with curl

Test connectivity before you integrate anything. A single eth_chainId call confirms the endpoint, the chain, and your network path.

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

A correct response returns 0x38, which is 56 in hex. If you get a different value, you are pointed at the wrong network. If you get a connection error, check egress rules and DNS first.

Now read a balance and the latest block:

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

For a batch of calls, send a JSON array of request objects in one HTTP request. Batching reduces round trips, but keep batches modest — very large batches are a common cause of timeouts and are often rate-limited by shared endpoints.

Wiring it into JavaScript

With ethers, the provider is a one-liner. Keep the endpoint in configuration rather than hardcoding it, so you can swap providers or add failover later.

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider(process.env.BSC_RPC_URL);

const network = await provider.getNetwork();
console.log("chainId", network.chainId.toString()); // expect 56

const block = await provider.getBlockNumber();
const balance = await provider.getBalance("0xYourAddress");
console.log({ block, balance: balance.toString() });

For viem, the equivalent uses createPublicClient with http() or web3() transport. If you need push updates — new blocks, pending transactions, or contract events — use the WebSocket transport against a wss:// endpoint. BSC mainnet supports both HTTP and WebSocket on OnFinality; testnet is HTTP-only, so plan your testnet tooling accordingly.

Wallet and dApp network configuration

If you are adding BSC to a wallet or dApp, use the wallet_addEthereumChain parameters. These are the values users will see when they switch networks.

await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    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"]
  }]
});

For testnet, switch to chain ID 0x61 (97), symbol tBNB, and the testnet explorer. Get testnet funds from a BSC faucet before you try to send transactions — a zero balance is the most common reason a testnet write silently fails.

Failure modes and how to debug them

Most BSC RPC problems fall into a handful of categories. Match the symptom, then work the fix.

Two habits prevent most of these. First, always confirm chain ID at startup and fail fast if it is wrong. Second, treat every RPC call as fallible: wrap it with a timeout, retry with backoff, and keep a second endpoint in configuration for failover.

Production readiness checklist

Before you point real traffic at an endpoint, confirm these items.

• Chain ID verified at startup, not assumed.
• Endpoint stored in configuration, with at least one fallback URL.
• Timeouts and retries configured for every call path.
• eth_getLogs ranges bounded and paginated.
• Nonce handling centralized so concurrent writers do not collide.
• Monitoring on block height lag, error rate, and p95 latency.
• A documented path to a dedicated node if shared throughput becomes the bottleneck.

If several of these are already causing incidents, that is the signal to evaluate dedicated infrastructure. OnFinality's BNB Chain network page lists the endpoint and transport details, and RPC pricing covers the plan shapes. For a broader framework, see how to choose an RPC provider.

Key Takeaways

• BSC mainnet is chain ID 56 with BNB as the native token; testnet is chain ID 97 with tBNB.
• The OnFinality public endpoints are https://bnb.api.onfinality.io/public for mainnet and https://bnb-testnet.api.onfinality.io/public for testnet.
• A small set of methods — eth_chainId, eth_getBalance, eth_call, eth_getLogs, eth_sendRawTransaction — covers most production traffic.
• Sign transactions client-side; do not rely on eth_sendTransaction on hosted endpoints.
• eth_getLogs range limits and nonce handling are the two most common sources of production incidents.
• Start on a shared RPC API endpoint, then move heavy or latency-sensitive workloads to a dedicated node.
• Always configure a fallback endpoint and monitor block height lag.

Frequently Asked Questions

What is the BSC chain ID? BNB Smart Chain mainnet uses chain ID 56 (0x38). The testnet uses chain ID 97 (0x61).

Does BSC support WebSocket? Yes. BSC mainnet supports both HTTP and WebSocket transports. Testnet access is HTTP-only, so plan subscriptions accordingly.

Why does my eth_getLogs call fail? Usually because the block range is too wide for the endpoint to serve in one request. Narrow the range, paginate, or use an endpoint suited to indexing workloads.

Can I use my Ethereum tooling on BSC? Yes. BSC is EVM-equivalent, so ethers, viem, Hardhat, and Foundry work once you set the correct chain ID and endpoint.

How do I get testnet BNB? Use a BSC testnet faucet to fund your address with tBNB before sending transactions.

When should I move to a dedicated node? When shared throughput, log queries, or latency become recurring problems — for example, sustained eth_getLogs backfills or latency-sensitive trading writes.

Where can I see which networks OnFinality supports? The supported RPC networks page lists current network coverage and endpoints.