Summary
BNB Smart Chain (BSC) exposes JSON-RPC endpoints for reading blockchain data and sending transactions. The mainnet endpoint is https://bsc-dataseed.bnbchain.org with chain ID 56, and the testnet endpoint uses chain ID 97. Public endpoints are fine for prototyping but come with rate limits and feature restrictions.
This guide covers the chain settings, how to verify an endpoint with eth_chainId, and what to check when choosing a public or managed endpoint for production. It also explains when a dedicated BNB Smart Chain node is worth the investment.
BNB Smart Chain endpoint decision checklist
A BNB Smart Chain endpoint is the HTTP or WebSocket URL your app uses to send JSON-RPC requests to BSC nodes. Before you pick one, run through this checklist:
- Mainnet or testnet? Mainnet uses chain ID
56; testnet (Chapel) uses97. Switching endpoints without switching chain IDs is a common source of transaction failures. - Public or managed endpoint? Public endpoints like
https://bsc-dataseed.bnbchain.orgare fine for quick tests and local prototyping. Production apps usually need managed RPC with higher rate limits and better diagnostics. - Does your workload need logs or archives? Public endpoints often disable or restrict
eth_getLogsand may not serve archive data. If you build analytics, indexers, or block explorers, you need an endpoint that supports those methods and historical data. - Do you need real-time updates? Use a WebSocket endpoint for
eth_subscribeso you can stream new blocks and pending transactions instead of polling. - Test before you commit. Run
eth_chainIdandeth_blockNumberagainst any endpoint you plan to use. Confirm the response matches the network you expect. - Check the rate limit. The official public endpoints have published fair-use limits. For traffic spikes, a dedicated node or paid RPC plan will be more predictable.
- Plan for failure. If one endpoint stops answering, do you have a fallback? Consider using multiple providers or a failover setup.
- Review cost and support. Compare RPC pricing for paid tiers, archive access, and WebSocket support before you scale.
Chain settings for BNB Smart Chain
If you are configuring a wallet, SDK, or middleware, use these values:
| Network | Chain ID | Currency | RPC URL |
|---|---|---|---|
| BNB Smart Chain Mainnet | 56 (0x38) | BNB | https://bsc-dataseed.bnbchain.org |
| BNB Smart Chain Testnet (Chapel) | 97 (0x61) | tBNB | https://data-seed-prebsc-1-s1.bnbchain.org:8545 |
Other public endpoints are listed in the official BNB Chain documentation. The endpoint list changes over time as nodes are added or retired, so verify the URLs before relying on them in production.
Block explorer: https://bscscan.com
WebSocket endpoints are also available from some providers. For example, wss://bsc-rpc.publicnode.com is a community-maintained gateway. Later in this article, we cover the trade-offs between these options and managed offerings from OnFinality and other providers.
How to add the BNB Smart Chain endpoint to a wallet
Most EVM wallets let you add a custom network. The process is similar across MetaMask, Rabby, and others:
- Open the wallet's Settings or Networks menu.
- Choose Add network or Add custom network.
- Enter the following values:
- Network name:
BNB Smart Chain - RPC URL:
https://bsc-dataseed.bnbchain.org - Chain ID:
56 - Currency symbol:
BNB - Block explorer URL:
https://bscscan.com
- Network name:
- Save and switch to the network.
When you add an endpoint manually, double-check the chain ID. Many failed BSC transactions are caused by setting chain ID 1 (Ethereum mainnet) or 5 (Goerli) instead of 56. If you use a custom RPC URL from a provider, the chain ID must remain 56 even if the URL belongs to a third party.
For testnet, use chain ID 97, symbol tBNB, and the testnet explorer at https://testnet.bscscan.com. You can request test BNB from the official faucet if you need funds for development.
Verifying the endpoint with JSON-RPC
Once you have a URL, verify it works with a simple curl call:
curl -X POST https://bsc-dataseed.bnbchain.org \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
A successful response returns 0x38, which is the decimal chain ID 56 in hexadecimal:
{"jsonrpc":"2.0","id":1,"result":"0x38"}
You can also confirm the latest block:
curl -X POST https://bsc-dataseed.bnbchain.org \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
In a JavaScript application, use ethers.js or viem to connect:
const { ethers } = require("ethers");
const provider = new ethers.JsonRpcProvider("https://bsc-dataseed.bnbchain.org");
provider.getNetwork().then((network) => {
console.log("Chain ID:", Number(network.chainId)); // 56
});
If the chain ID is not 56, you are likely pointing at the wrong endpoint. If the request times out, check your network connection, firewall rules, and the endpoint's availability.
Public endpoints vs managed RPC services
The official BNB Smart Chain endpoints are shared infrastructure operated by the BNB Chain team and community participants. They are free and easy to use, but they come with constraints:
- Rate limits: Public endpoints are shared by every developer and dApp. The official docs note a rate limit of 10,000 requests per 5 minutes per endpoint, which is roughly 33 requests per second. That may sound like a lot until your dApp starts broadcasting transactions and syncing historical data.
- Feature limits: Some public mainnet endpoints disable
eth_getLogsto protect node performance. If you rely on log queries, you will need an endpoint that supports them. - Availability: Public endpoints can become unavailable during congested periods or when network upgrades change the server list. There is no service-level guarantee you can depend on.
Managed RPC services run their own BSC node clusters and expose endpoints with dedicated capacity. Providers such as OnFinality offer both shared RPC API access and dedicated nodes for BNB Smart Chain. The main advantages are:
- Stronger WebSocket support for real-time subscriptions.
- Access to archive data and methods that improve indexing and analytics workflows.
- Clear pricing and request accounting so you can plan for growth.
- Better isolation: your traffic does not compete with every other developer on the same public endpoint.
For a small test script, public endpoints are fine. For a production dApp, a managed endpoint is usually worth the cost.
Evaluating endpoints for production: what to check
If you are deciding between public and managed endpoints, or between multiple providers, use this table to structure your evaluation.
| Criterion | What to check | Why it matters |
|---|---|---|
| Rate limits | What is the documented request limit per second or per month? | A limit that seems generous on day one may throttle your app during a spike in users. |
| Data completeness | Does the endpoint serve archive state, eth_getLogs, and trace methods? | Analytics, indexers, and support tools depend on these methods. |
| WebSocket support | Can you subscribe to newHeads and logs over wss://? | Real-time dApps should not poll; they need push notifications. |
| Regional latency | Where is the node hosted? Is there load balancing across regions? | High latency makes every read and transaction confirmation slower. |
| Failover | Does the provider offer multiple URLs or automatic retry logic? | A single endpoint is a single point of failure. |
| Pricing model | How are requests billed? Are there free tiers and overage costs? | Unexpected billing surprises can break an app budget. |
| Support and ops | Is there a status page, SLA, or direct support channel? | You need to react quickly when the endpoint goes down. |
The "right" endpoint is the one that matches your workload. A DeFi frontend, a data indexer, and a trading bot all have different requirements for latency, history, and streaming.
Debugging common BNB Smart Chain endpoint failures
Even with a correct endpoint, developers run into issues. Here are the most common ones and how to fix them.
- Wrong chain ID. Your RPC URL points to BSC, but the wallet or SDK is configured for another chain. Always set
chainIdto56in your application code and wallet config. For testnet, use97. eth_chainIdreturns0x1or another unexpected value. You may be hitting an Ethereum endpoint or a proxy that rewrites requests. Switch to a known BSC endpoint and re-run the check.- 429 or "limit exceeded" errors. You have hit the rate limit of a public endpoint. Add backoff and caching, or move to a managed endpoint with higher limits.
eth_getLogsis not supported. Use a WebSocket connection to subscribe to logs, or choose a managed provider that supports the method.- Block not found after sending a transaction. BSC has 3-second block times, but your node may need a few seconds to sync the latest block. Poll again, and consider waiting for a few confirmation blocks before showing success to the user.
- WebSocket connection drops. Some community WebSocket endpoints are less reliable than HTTP. For production streaming, use a provider with dedicated WebSocket infrastructure.
When to use a dedicated BNB Smart Chain node
A dedicated node is a single-tenant BNB Smart Chain node provisioned for your project. It gives you:
- Isolated performance. Your requests do not compete with a shared pool of traffic.
- Flexible RPC configuration. You can enable or disable specific modules, set block storage to archive mode, and adjust sync settings.
- Higher request volume. You can tune
maxpeersand other node parameters to match your workload. - Privacy. Requests are not logged by a shared public service.
Dedicated nodes are useful when:
- Your dApp has a large audience or high-frequency read/write patterns.
- You run analytics pipelines that need archive data and repeated log queries.
- You want a private endpoint for your backend without exposing your usage pattern.
At OnFinality, you can launch a dedicated BNB Smart Chain node on mainnet or testnet, and you can also use the RPC API service if you prefer a shared but scalable endpoint. For an overview of all supported networks, see supported RPC networks.
Key Takeaways
- The mainnet endpoint for BNB Smart Chain is
https://bsc-dataseed.bnbchain.orgwith chain ID56. - The testnet endpoint uses chain ID
97and thetBNBtoken. - Public endpoints are fine for development but have rate limits and may disable
eth_getLogs. - Always verify an endpoint with
eth_chainIdbefore wiring it into an app. - Production apps should evaluate rate limits, archive data, WebSocket support, latency, and failover.
- A managed RPC API or a dedicated node is a more predictable choice when your dApp grows beyond prototype stage.
Frequently Asked Questions
What is the official BNB Smart Chain RPC endpoint?
The official mainnet endpoint is https://bsc-dataseed.bnbchain.org. The BNB Chain team also runs additional data seed URLs such as bsc-dataseed1.bnbchain.org and bsc-dataseed2.bnbchain.org. For the current official list, check the BNB Chain documentation.
What is the BNB Smart Chain testnet endpoint?
BNB Smart Chain testnet (Chapel) uses chain ID 97 and can be reached at URLs like https://data-seed-prebsc-1-s1.bnbchain.org:8545. Testnet faucets are available through BNB Chain's official developer tools.
Why is eth_getLogs disabled on some public BSC endpoints?
Log queries are expensive for node operators because they force extensive scanning. Public endpoints disable or severely limit eth_getLogs to keep the shared infrastructure stable. Managed providers can support it with appropriate indexing and caching.
What chain ID should I use for BNB Smart Chain?
Use 56 for mainnet and 97 for testnet. In code that takes a hex value, 56 is 0x38 and 97 is 0x61.
Can I use WebSockets with a BNB Smart Chain endpoint?
Yes. Several providers expose wss:// endpoints for real-time subscriptions. OnFinality and other managed RPC services support WebSocket connections on their BNB Smart Chain endpoints, which is useful for streaming new blocks and transaction logs.