As BNB Chain is based on the EVM, a BNB Chain RPC endpoint uses the Ethereum JSON-RPC API protocol. To connect you need its URL, chain ID 56 for mainnet or 97 for testnet, and the BNB currency symbol. On OrbitFlare the endpoint is https://bsc.rpc.orbitflare.com?api_key=YOUR_LICENSE_KEY, with plans from $0/mo at a rate of 25 RPS. However, running your own BSC node is feasible although harder than expected by most teams.
BSC network details
| Field | Mainnet | Testnet |
|---|---|---|
| Network name | BNB Smart Chain | BNB Smart Chain Testnet |
| Chain ID | 56 (0x38) |
97 (0x61) |
| Currency symbol | BNB | tBNB |
| Explorer | https://bscscan.com | https://testnet.bscscan.com |
We took the chain IDs from BNB Chain’s JSON-RPC documentation on 9 November 2026. To configure a custom network in an EVM wallet, use these numbers along with your RPC URL. A wrong chain ID is behind most rejected signatures after adding a network.
Getting a BNB Chain RPC endpoint
BNB Chain and community operators run free public endpoints. They don’t require any registration; however, they are shared, IP rate-limited, and they slow down during peak times first. Use one to check your configuration, not to operate a service on.
A provider endpoint is tied to your account and comes with a set limit. Each OrbitFlare BNB plan bundles JSON-RPC, WebSockets and archival data, and none has a monthly credit cap:
| Plan | Price | Requests per second |
|---|---|---|
| Free | $0/mo | 25 RPS |
| Starter | $49/mo | 100 RPS |
| Growth | $149/mo | 300 RPS |
| Pro | $299/mo | 600 RPS |
| Performance | $499/mo | 1,000 RPS |
The shared BNB plans operate in Amsterdam. Your license key is in the Licenses tab of the dashboard (the authentication docs show how to send it). This key will be the same key used for Solana, Polygon and Robinhood Chain too. Keep the keyed URL in your server's environment variables alone, because anyone who holds it can spend your limit.
Using the BNB Chain RPC endpoint in code
Ethers, viem, web3.js, web3.py, alloy and go-ethereum all work without changes.
Construct the client via HTTPS URL, use wss://bsc.rpc.orbitflare.com?api_key=YOUR_LICENSE_KEY for eth_subscribe, and use chain ID 56 everywhere where signing by your library takes place:
curl -X POST "https://bsc.rpc.orbitflare.com?api_key=$ORBITFLARE_LICENSE_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'A mainnet endpoint answers 0x38, which translates into 56 in hexadecimal notation.
Following are the three habits on BSC:
- Subscribe, don't poll. Documentation on BNB Chain suggests use of WebSockets for new logs. Use
eth_subscribetonewHeadsandlogsfor request-budget savings. - Bound your log calls. Large
eth_getLogsranges cause most time-outs and other errors, so page them by block range. - Read fees from the chain. Use
eth_gasPriceoreth_feeHistoryinstead of setting hard values.
Free and paid limits
| Control | Free | Paid |
|---|---|---|
| Batch size | 1 item | 100 items |
eth_getLogs block range |
150 blocks | 10,000 blocks |
debug_* and trace_* methods |
Blocked | Allowed |
| WebSocket connections | 1 | From 10 |
| Subscriptions per connection | 5 | 25 |
HTTP and WebSocket traffic share a single rate limit and in-flight budget. When you see a -32005 error on a single operation, it generally indicates that some other client is currently operating under that same key or batch is exceeding the limits. If a -32602 block-range error occurs, the eth_getLogs range is too large; divide it. -32429 means you are over your requests per second.
Archive access and trace methods
A full node stores recent state only. The reading of balances or storage in contracts through any old block, or querying against old states via eth_call, requires an archival node. An archival node is required for indexers or analysis. Applications which only query recent data do not need one. The archival dataset is included in every OrbitFlare BNB plan. Debug and trace methods are blocked on Free and allowed on paid plans.
Running your own BSC node
It can be done and is an actual ops task:
- Storage: The chain is big and grows continuously, and needs fast NVMe. When a node runs on slower disks, it lags and cannot sync.
- Sync: Operators begin with snapshots that were published and not with genesis, pruning regularly.
- Upgrades: The client has planned updates and hard forks, and a missing update results in a node falling off the chain.
- Monitoring: Someone has to watch it for lag, disk growth and peer count, and be on call for when a snapshot or an update doesn’t work as intended.
Self-hosting of a BNB Chain node becomes useful when special client configurations, complete isolation, or a huge, sustained traffic level is needed. If you decide to do it, bare metal servers at OrbitServers, our sister brand, are built for that kind of load. In all other cases, a shared plan suits almost all applications, while for others, a dedicated BNB Chain node on isolated hardware, priced per deployment, covers the rest without the operations work.
Choosing a BSC RPC provider
- Pricing model: requests per second against credits. Expensive heavy operations like
eth_getLogsor archive requests cost much more with credits; our explainer on RPC pricing models applies here too. - Location: an endpoint close to the servers that call it. Shared OrbitFlare BNB plans operate from Amsterdam.
- Streaming: WebSocket subscriptions included on every plan.
- Archive: Included in the plan or not? And for how far?
- Behavior when overloaded: test at peak hour, look for outdated blocks from a lagging node.
See the plans on the BNB Chain RPC page, or sample code in the BNB Chain docs.
