TL;DR
BNB Smart Chain RPC endpoints must handle burst traffic, event-heavy workloads, and reliable eth_getLogs access—this guide explains how they work and how to deploy one for production.
BNB Smart Chain is one of the highest-throughput EVM networks, producing blocks roughly every 3 seconds and capable of processing up to ~2,000 transactions per second. That performance places unique demands on RPC infrastructure.
What is a BNB Smart Chain RPC endpoint
A BNB Smart Chain RPC endpoint is your app’s gateway to BNB Chain. It uses the same JSON-RPC interface as Ethereum (eth_call, eth_getBalance, eth_sendRawTransaction) but connects to BNB Chain’s validator network and reflects BNB Chain’s network conditions.
Every user-facing blockchain action in your product depends on it:
- Reading wallet balances
- Fetching contract state
- Estimating gas costs
- Broadcasting signed transactions
- Monitoring contract events via
eth_getLogs
That is why endpoint quality directly affects user experience. If your endpoint is slow, your app feels slow. If your endpoint is unstable, transaction flows fail at the worst possible time.
How BNB Smart Chain RPC differs from Ethereum RPC
| What | BNB Smart Chain | Ethereum |
|---|---|---|
| Block time | ~3 seconds | ~12 seconds |
| Throughput | Up to ~2,000 TPS | ~15-30 TPS (L1) |
| Gas token | BNB | ETH |
| Consensus | Proof of Staked Authority (PoSA) | Proof of Stake |
| Validator set | 45 active validators | Thousands of validators |
| Log queries | Often restricted on public RPC endpoints | Generally available |
| Traffic patterns | High burst activity during market volatility | More distributed |
This is exactly why provider selection for BNB Chain should include log access guarantees and burst traffic handling, not just raw RPS limits.
BNB Smart Chain RPC endpoint options
Choosing the right endpoint is primarily a reliability decision. You’re balancing convenience, cost, and operational risk.
Public vs Private BNB Chain RPC endpoints
Official public BNB Chain endpoints:
- Mainnet:
https://bsc-dataseed.bnbchain.org - Testnet:
https://bsc-testnet.bnbchain.org
Rate limits: 10,000 requests per 5 minutes (per BNB Chain docs)
Critical limitation: eth_getLogs is disabled on public Mainnet endpoints
⚠️ Full public endpoint list is available in the official BNB Chain documentation here.
| Feature | Public RPC | Private RPC (Chainstack) |
|---|---|---|
| Access | Free and open | Restricted access |
| Resources | Shared infrastructure | Dedicated resources |
| Performance | Variable, rate-limited | Stable, high throughput |
| Log queries | Disabled on public Mainnet | Full eth_getLogs support |
| WebSocket stability | Limited guarantees | Reliable long-lived connections |
| Best use case | Development & testing | Production workloads |
Public RPC endpoints are useful for testing and experimentation, but treat them as shared community resources.
For production workloads—especially DeFi apps, bots, or analytics systems—use an infrastructure RPC provider with eth_getLogs support and clearer performance guarantees.
Full node vs Archive BNB Smart Chain node
Your data requirements should drive this decision.
| Full node access | Archive node access |
|---|---|
| Current state queries | Historical analytics |
| Standard wallet/dApp interactions | Explorer-like products |
| Transaction submission | Deep event backfills (via eth_getLogs with wide block ranges) |
| Real-time event monitoring | Compliance and reporting |
| Long-range debugging |
If your product depends on historical state queries or event backfills beyond recent blocks, validate archive availability before launch.
HTTPS vs WebSockets
Transport choice impacts system behavior, especially at scale.
| Feature | HTTPS | WebSocket |
|---|---|---|
| Model | Request/response | Persistent connection |
| Complexity | Simple operationally | Requires reconnect/heartbeat logic |
| Best for | Standard reads/writes | Event streams, real-time subscriptions |
| Latency | Standard | Lower for frequent updates |
| Connection overhead | Per request | One-time handshake |
In practice, many teams use HTTPS broadly and add WebSocket subscriptions only where real-time behavior is required (event monitors, bots, live dashboards).
If your system depends on live data, test WebSocket stability under load early—don’t assume HTTPS reliability translates to WebSocket reliability.
📖 For a detailed comparison of BNB Smart Chain RPC providers, including performance benchmarks and feature analysis, see Best BNB Chain RPC providers for production use in 2026.
How to get a private BNB Smart Chain RPC endpoint with Chainstack
- Log in to the Chainstack console (or create an account)
- Create a new project
- Select BNB Smart Chain as your blockchain protocol
- Choose network: BNB Smart Chain Mainnet or BNB Smart Chain Testnet
- Deploy the node
- Open Access/Credentials and copy your HTTPS and WebSocket endpoints
- Run a quick connectivity check before wiring it into production code
Quick endpoint test
curl -X POST "$BNB_RPC_URL" \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
Expected response:
- Mainnet:
{"result":"0x38"} - Testnet:
{"result":"0x61"}
Connect from your application (ethers.js)
import { JsonRpcProvider } from "ethers";
const provider = new JsonRpcProvider(process.env.BNB_RPC_URL);
const blockNumber = await provider.getBlockNumber();
console.log(`Current BNB block: ${blockNumber}`);
This confirms your app can connect and read live chain data before you integrate more complex logic.
Using Chainlist
Chainlist can help add BNB Smart Chain to wallets like MetaMask or Rabby, but it is not an infrastructure provider.
For BNB Smart Chain, use your provider dashboard and official SDK tooling instead. If you used Chainlist during development, replace any public/community RPC URL with your managed endpoint before launch.
Chainstack pricing for BNB Smart Chain RPC
Chainstack pricing is request-unit-based and easier to forecast than compute-unit models.
| Plan | Cost | Requests/Month | RPS | Overage (per 1M extra) |
|---|---|---|---|---|
| Developer | $0 | 3M (~25 RPS) | ~25 | $20 |
| Growth | $49 | 20M | ~250 | $15 |
| Pro | $199 | 80M | ~400 | $12.5 |
| Business | $349 | 140M | ~600 | $10 |
| Enterprise | From $990 | 400M+ | Custom | From $5 |
Advanced options:
- Unlimited Node add-on: Flat monthly pricing for unmetered usage within RPS tier
- Dedicated Nodes: From $0.50/hour (+ storage) for isolated high-performance workloads
How to estimate monthly cost
- Forecast average and peak requests/day
- Convert to monthly request units
- Add 20–30% buffer for spikes
- Check if RPS limits match your peak traffic profile
- Compare shared tier vs dedicated economics at projected scale
For BNB Chain specifically: If your app is event-heavy (bots, analytics, DeFi monitors), throughput limits and overage policy matter more than base plan price.
Production readiness checklist
Before launch, validate these basics:
- Primary + fallback RPC provider configured
- Request timeout policy set
- Retry logic with exponential backoff implemented
- Chain ID validated at startup (
eth_chainId) - Credentials stored in env/secret manager (never hardcoded)
- Monitoring for latency, error rate, and throttling
- Alerts for sustained degradation
eth_getLogsaccess confirmed (if needed)
These controls prevent most avoidable RPC incidents in production.
Troubleshooting common BNB Chain RPC issues
| Issue | Likely Cause | How to Fix |
|---|---|---|
429 Too Many Requests | Shared endpoint saturation or aggressive polling | Move to managed endpoint, reduce polling frequency, batch requests |
| Wrong chain ID returned | App pointed to Mainnet instead of Testnet (or vice versa) | Validate eth_chainId at startup and fail fast on mismatch |
eth_getLogs fails | Public Mainnet endpoints restrict log access | Use managed endpoint with confirmed log support or switch to WebSocket event streams |
| WebSocket disconnects | Unstable long-lived connection or provider limits | Add reconnect logic, heartbeat handling, and missed-event backfill |
| High latency spikes | Region mismatch or overloaded shared infrastructure | Route to closer region and enable fallback endpoint |
Conclusion
BNB Smart Chain’s high throughput and EVM compatibility make RPC selection critical. Your provider needs to support burst traffic, reliable eth_getLogs access, and stable WebSocket connections—not just provide basic JSON-RPC uptime.
Use public endpoints for prototyping, then move to managed infrastructure with proven BNB Chain support, confirmed log access, and SLA-backed reliability before production launch.
Start with Chainstack’s free tier (3M requests/month), validate your query patterns in staging, then scale to dedicated infrastructure as traffic grows.
FAQ
Yes. BNB Chain is EVM-compatible, so ethers.js, Web3.js, Hardhat, and MetaMask work with BNB Chain. Just point them to a BNB Chain RPC endpoint instead of Ethereum.
The JSON-RPC interface is the same, but BNB Chain has faster block times (~3s vs ~12s), different gas pricing, and public endpoints often restrict eth_getLogs access.
Most teams use ethers.js or web3.js. Any SDK supporting Ethereum JSON-RPC works with BNB Chain.
Yes. MetaMask supports BNB Chain as a custom network. Chainlist can help add it quickly.
Usually no. Public endpoints have rate limits, no log access on Mainnet, and no uptime guarantees. Production apps need managed infrastructure.
Track p95/p99 latency, failure rate, 429 responses, WebSocket reconnect frequency, and block lag. For event-heavy apps, monitor log delivery and backfill success.