What does BNB Chain RPC cost, and how do you pick the right plan?

Quick recommendation: match the plan to your request shape

"BNB RPC price" usually means one of three things: you want a free endpoint to test with, you want to know what a managed RPC plan costs at your traffic level, or you are comparing a per-request plan against renting a dedicated BNB node. The answer depends less on the headline price and more on your request mix.

• Prototyping or low-volume dApp: a shared public endpoint is enough. Start with the OnFinality public BNB Smart Chain endpoint and move on when you hit rate limits.
• Production app with steady, moderate traffic: a managed RPC plan billed by request volume or compute units is usually the simplest fit. You pay for what you use and avoid running infrastructure.
• High-throughput, archive, or trace-heavy workloads: a dedicated BNB node gives you predictable capacity and avoids per-call billing surprises when eth_getLogs or archive queries dominate your traffic.

If you already know your monthly request count and whether you need archive data, you can skip to the cost model below. If not, the next section shows how to estimate it.

What actually drives BNB Chain RPC cost

RPC pricing is not a single number. Providers price on a mix of the following, and the mix matters more than the sticker price:

BNB Smart Chain is an EVM chain, so the method surface looks familiar: eth_call, eth_getLogs, eth_getBalance, eth_sendRawTransaction, and so on. The cost difference between providers usually shows up in how they meter the heavy read methods and whether archive and trace are bundled or extra.

Estimating your monthly BNB Chain request volume

Before comparing prices, get a rough number. You do not need exact figures to make a decision; you need the right order of magnitude.

1. Count your read paths. A wallet refresh, a balance display, a token list, and a price feed each fire one or more eth_call or eth_getBalance requests.
2. Multiply by active sessions. If 1,000 daily users each trigger 20 reads, that is 20,000 requests per day from reads alone.
3. Add background jobs. Indexers, bots, and monitoring probes often generate more traffic than user-facing reads. A single eth_getLogs poll every few seconds adds up quickly.
4. Add retries and failover. If your client retries on timeout, your real volume is higher than your logical volume.

A quick sanity check with a public endpoint:

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

If you are benchmarking a read-heavy path, time a batch of calls rather than a single one:

time for i in $(seq 1 50); do
  curl -s https://bnb.api.onfinality.io/public \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"]}' > /dev/null
done

Public endpoints are shared, so treat these numbers as a floor, not a guarantee. They are useful for confirming your client works and for rough sizing.

Shared, managed, or dedicated: which BNB RPC plan fits

The three delivery models map to different cost profiles. Pick the row that matches your workload, then confirm details on the RPC pricing page.

OnFinality offers BNB Chain RPC through both a managed RPC API service and dedicated nodes, so you can start on a shared plan and move to dedicated capacity when your traffic justifies it. The supported RPC networks list shows which chains and transports are available.

Connecting to BNB Smart Chain mainnet and testnet

BNB Smart Chain mainnet uses chain ID 56 and the native token BNB. The testnet uses chain ID 97 and tBNB. Keep these straight when you configure a wallet or a client, because mixing mainnet and testnet settings is a common source of confusing errors.

Wallet network configuration for mainnet:

{
  "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 work, use the BNB Chain Testnet endpoint and chain ID 97. Testnet traffic is usually free or cheaper, which makes it a good place to validate your request volume before you size a mainnet plan.

A minimal viem client for mainnet reads:

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

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

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

If you need real-time data, BNB Chain supports WebSocket transport on managed endpoints. Subscriptions keep a connection open, so confirm how your provider meters them before you scale up.

When a dedicated BNB node is the cheaper choice

Per-request pricing is efficient when traffic is spiky or low. It becomes less efficient when your traffic is high and steady, or when your request mix is dominated by expensive methods.

A dedicated node tends to make sense when:

• Your monthly request volume is high enough that usage-based billing exceeds a fixed node cost.
• You rely on archive queries or trace methods that are metered heavily on shared plans.
• You need consistent capacity during predictable peaks, such as a token launch or a scheduled airdrop claim window.
• You want isolation from other tenants' traffic for latency-sensitive reads.

A dedicated node is usually the wrong first purchase for a prototype. Start shared, measure, then move when the numbers justify it. The build-versus-buy tradeoffs are worth reading if you are deciding between running your own BNB node and renting one.

Reducing BNB RPC cost without hurting reliability

Most teams can cut spend before they change plans. These are the levers that matter most:

• Batch requests. JSON-RPC batching sends multiple calls in one HTTP request, which reduces overhead and often reduces billed units.
• Cache aggressively. Balances and token metadata change slowly; cache them client-side or at an edge layer.
• Tune eth_getLogs ranges. Wide block ranges are expensive. Narrow them and paginate.
• Use WebSocket for subscriptions instead of polling. Polling eth_blockNumber in a loop is one of the most common sources of wasted requests.
• Separate read and write paths. Sending transactions through a dedicated path keeps latency-sensitive writes away from bulk reads.
• Add failover, not duplication. A second endpoint for failover is fine; running two full traffic paths doubles cost for no benefit.

A simple monitoring probe helps you catch runaway request volume early:

#!/usr/bin/env bash
# Log head height and response time every minute
START=$(date +%s%3N)
HEAD=$(curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | grep -o '"result":"[^"]*"')
END=$(date +%s%3N)
echo "$(date -u +%FT%TZ) head=$HEAD latency_ms=$((END-START))"

Common pricing and billing pitfalls

• Sizing on averages. Peak requests per second drives capacity and cost more than the monthly average. Size for peaks.
• Forgetting background jobs. Indexers and bots often outspend user-facing reads.
• Assuming archive is included. Historical state queries need archive nodes; confirm before you build a feature that depends on them.
• Ignoring retry storms. A client that retries aggressively on timeout can multiply your billed volume during an incident.
• Mixing mainnet and testnet. Wrong chain ID or wrong endpoint produces errors that look like provider problems but are configuration mistakes.
• Over-provisioning failover. One standby endpoint is usually enough; two active paths double cost.

Key Takeaways

• BNB Chain RPC price is driven by request volume, method weight, archive and trace access, WebSocket subscriptions, and whether you rent dedicated capacity.
• Shared public endpoints are fine for prototypes; managed plans fit variable production traffic; dedicated nodes fit high-throughput, archive, or trace-heavy workloads.
• Estimate your monthly request volume and peak requests per second before comparing plans.
• BNB Smart Chain mainnet is chain ID 56; testnet is chain ID 97. Keep the settings separate.
• Batching, caching, narrower eth_getLogs ranges, and WebSocket subscriptions are the fastest ways to cut cost without hurting reliability.
• OnFinality provides BNB Chain RPC through a managed RPC API service and dedicated nodes; see RPC pricing and supported RPC networks for current options.

Frequently Asked Questions

Is there a free BNB Chain RPC endpoint?

Yes. OnFinality publishes a shared public endpoint for BNB Smart Chain mainnet and testnet. It is rate-limited and shared, so it suits prototyping and low-volume use rather than production traffic.

How is BNB Chain RPC priced?

Managed plans are typically billed by request volume or compute units, with heavier methods and archive or trace access metered differently. Dedicated nodes are billed per node with fixed capacity. Check RPC pricing for current details.

When should I move from a shared endpoint to a dedicated BNB node?

When your steady request volume makes usage-based billing more expensive than a fixed node, or when you depend on archive or trace methods that are metered heavily on shared plans.

Does BNB Chain RPC support WebSocket?

BNB Smart Chain supports HTTP and WebSocket transport on managed endpoints. Subscriptions keep a connection open, so confirm how your provider meters them.

What chain ID does BNB Smart Chain use?

Mainnet uses chain ID 56 with the BNB native token. Testnet uses chain ID 97 with tBNB. See BNB Chain and BNB Chain Testnet for endpoint details.

Can I reduce my BNB RPC bill without changing providers?

Often yes. Batching requests, caching slow-changing data, narrowing eth_getLogs ranges, and replacing polling with WebSocket subscriptions typically cut billed volume significantly.