How to get a BNB Chain RPC endpoint for AI agents (2026 guide)

TL;DR

Point an autonomous agent at BNB Smart Chain’s public endpoint and it dies two deaths: the first eth_getLogs call it reasons its way into returns nothing because the method is disabled on the public mainnet, and the request loop it runs to watch the chain trips the 10,000-requests-per-5-minute throttle within seconds of going parallel. Agents generate burst, deeply-parallel, unpredictable traffic that shared endpoints were never built to absorb — and BNB’s sub-second blocks make every poll-based agent loop hungrier than it would be on Ethereum. This guide shows what BNB RPC actually exposes to an agent and how to get a BNB Chain RPC endpoint for AI agents that survives a long-running loop.

What is a BNB Chain RPC endpoint

A BNB Chain RPC endpoint is the JSON-RPC interface your agent’s tool layer calls to read chain state and broadcast transactions. BNB Smart Chain runs the full Ethereum JSON-RPC surface — eth_call, eth_getBalance, eth_getLogs, eth_sendRawTransaction, eth_subscribe, debug_traceTransaction — over a Proof-of-Staked-Authority validator set, with blocks landing roughly every 0.75 seconds after the 2025 Maxwell upgrade. For an agent, the endpoint is the ground truth: it is the difference between the model reasoning over what is actually on-chain and the model hallucinating a balance, a method, or a result that was never there.

For agentic workloads specifically, the endpoint is what powers:

• Reading wallet and contract balances with eth_call so the agent’s decision is grounded in real state
• Watching Transfer, Swap, and custom events with eth_getLogs to detect the conditions an agent acts on
• Simulating a transaction with eth_call or tracing it with debug_traceTransaction before the agent commits funds
• Broadcasting the agent’s chosen action through eth_sendRawTransaction
• Streaming new blocks and pending state over WebSocket eth_subscribe so a long-running loop reacts the instant the chain moves

You can review the full list of supported methods in the BNB Chain developer documentation. The practical point for agent builders: almost everything an agent does beyond a single balance read — detecting a condition, simulating an action, verifying a result — depends on log access and trace methods, and those are exactly what BNB restricts hardest on its public endpoint.

For an AI agent, endpoint quality is not a latency nicety — a silent log failure or a throttled call doesn’t surface as a crash, it surfaces as a wrong decision the model makes confidently and acts on with real money.

How BNB Chain RPC differs from Ethereum RPC

BNB Smart Chain is EVM-compatible, so the method names match Ethereum’s exactly. What changes is the operational envelope underneath them — and for an agent running an unattended loop, that envelope decides whether the loop survives.

Property	Ethereum	BNB Smart Chain
Block time	~12s	~0.75s (post-Maxwell)
Consensus	Proof-of-Stake	Proof-of-Staked-Authority
Gas token	ETH	BNB
eth_getLogs on public endpoint	Generally available	Disabled on public mainnet
Public rate limit	Provider-dependent	10,000 requests / 5 minutes (~33 rps)
Finality	~13 min (2 epochs)	Fast finality (~1.5–2s)

The last three rows are what reshape provider selection for an agent. Sub-second blocks mean a polling agent generates roughly 16x the per-block request volume it would on Ethereum to stay current — and the public endpoint caps it at ~33 requests per second while removing eth_getLogs, the method an agent leans on to detect the events it reasons about. On Ethereum a read-light agent can sometimes limp along on a public node; on BNB a parallel agent loop is throttled and partially blinded by design.

BNB Chain RPC endpoint options

Public vs private BNB Chain RPC endpoints

For an agent, the public-vs-private decision isn’t about shaving milliseconds — it’s about whether the loop can see what it needs to see and run as fast as it needs to run. An agent doesn’t issue requests on a human’s cadence; it fans out parallel calls and bursts whenever its reasoning step fires, which is the exact traffic shape the public BNB endpoint penalizes first.

Official public endpoints:

• Mainnet: https://bsc-dataseed.bnbchain.org
• Testnet: https://bsc-testnet.bnbchain.org

⚠️ BNB Chain’s own documentation disables eth_getLogs on the public mainnet dataseed endpoints and explicitly directs developers to third-party endpoints, while capping public traffic at 10,000 requests per 5 minutes — the BNB Chain docs themselves recommend using professional RPC providers. For an agent that reasons over events, that means its core perception loop simply cannot run against the public node.

Capability	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
eth_getLogs (event perception)	Disabled	Full support
Burst / parallel tolerance	10,000 req / 5 min (~33 rps)	No aggressive throttling
WebSocket eth_subscribe	Not available	Available

An agent’s load profile — bursty, parallel, and timed by model reasoning rather than human clicks — is precisely what a shared 33-rps endpoint was never designed to absorb, which is why agentic workloads on BNB belong on a private endpoint from the first integration test.

📖 For a detailed comparison of BNB Chain RPC providers, see Best BNB Smart Chain RPC providers in 2026.

Full node vs archive BNB node

For an agent, historical access is the difference between reacting to the present and reasoning about a trend. A full node answers “what is true now”; an archive node lets the agent ask “how did we get here” — replaying past state to backtest a strategy, audit its own prior actions, or build the context window it reasons over.

Full node access	Archive node access
Current balances and live event detection	Backtesting an agent strategy over historical blocks
Real-time transaction simulation before acting	Replaying past Transfer/Swap logs to build training context
Streaming new blocks for the live decision loop	eth_getStorageAt at past blocks for point-in-time state reconstruction

Chainstack supports BNB Smart Chain archive nodes, which is what lets an agent backtest against real historical chain state, reconstruct the exact conditions behind a past decision for post-mortem analysis, and assemble deep on-chain context — none of which a full node can answer once the data ages out of recent state. Archive calls bill at 2 RU each rather than 1, so an agent doing heavy historical replay should model that cost up front.

HTTPS vs WebSockets

A long-running agent is the textbook case for persistent connections. An agent that polls over HTTPS to know when the chain moved burns request budget on every empty poll and still reacts a beat late; on a chain producing a block every 0.75 seconds, that waste compounds fast. A WebSocket subscription flips the model — the chain pushes the agent the moment something changes, so the loop reacts on the event, not on the next poll.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	One-shot reads, simulation, broadcasting the agent’s action	The live perception loop: streaming new blocks, watching events, reacting in real time
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

WebSocket eth_subscribe is not available on the public BNB dataseed endpoints — an agent that needs to react to chain events in real time requires a private endpoint that exposes a WebSocket URL, plus reconnect-and-backfill logic so a dropped connection never silently blinds the loop.

How to get a private BNB Chain RPC endpoint with Chainstack

1. Log in to the Chainstack console (or create an account).
2. Create a new project
3. Select BNB Smart Chain as your blockchain protocol
4. Choose network: Mainnet or Testnet
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into your agent’s tool layer

You can deploy a private BNB Smart Chain RPC node on Chainstack in a few minutes, then give your agent a grounded tool call that confirms log access works — the read every agent loop depends on:

const { ethers } = require("ethers");

// Chainstack private endpoint — eth_getLogs is enabled here, unlike the public node
const provider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ENDPOINT");

// PancakeSwap V2 router — a high-traffic contract an agent might watch
const pair = "0x0eD7e52944161450477ee417DE9Cd3a859b14fD0";
const swapTopic = ethers.id("Swap(address,uint256,uint256,uint256,uint256,address)");

async function recentSwaps() {
  const latest = await provider.getBlockNumber();
  // Keep ranges small — BNB caps eth_getLogs at ~5,000 blocks per query
  const logs = await provider.getLogs({
    address: pair,
    topics: [swapTopic],
    fromBlock: latest - 4999,
    toBlock: latest,
  });
  console.log(`Agent perceived ${logs.length} swaps in the last 5,000 blocks`);
}

recentSwaps();

📖 For the full integration guide, see the Chainstack BNB Smart Chain tooling documentation.

You can also access Chainstack BNB Chain RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP — which is increasingly how agents reach the chain, since the Model Context Protocol lets the agent read Chainstack’s RPC reference first and write real methods instead of hallucinated ones. Learn more about Chainstack MCP.

Using Chainlist

BNB Smart Chain is listed on Chainlist (chain ID 56), which makes it easy to add the network to MetaMask in one click. Chainlist is a network registry, not an infrastructure provider — the public RPC URLs it surfaces carry the same disabled eth_getLogs and 10K/5min throttle as any other public endpoint, so an agent wired to a Chainlist URL inherits both walls. Use it to configure a wallet, then swap in a managed endpoint before the agent touches production.

Chainstack pricing for BNB Chain RPC

Chainstack bills by request unit rather than per-method compute multipliers, which matters more for an agent than for a dApp: an agent’s method mix is unpredictable, so a flat 1 RU per call (2 on archive) makes its cost forecastable even when its behavior isn’t. See the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3M	25	$20
Growth	$49	20M	250	$15
Pro	$199	80M	400	$12.50
Business	$499	200M	600	$10
Enterprise	$990+	400M+	Unlimited	$5

Advanced options relevant to agentic workloads:

• Archive Node add-on for backtesting and historical replay — point your agent’s deep-context reads at a dedicated archive node (billed at 2 RU per call)
• Unlimited Node add-on — flat-fee RPS tiers that give a bursty agent loop predictable headroom
• Global Nodes — geo-balanced RPC so a distributed fleet of agents hits low-latency endpoints wherever they run
• Dedicated Nodes: from $0.50/hour (plus storage) for isolated, single-tenant infrastructure when one agent fleet shouldn’t share resources with anything else

How to estimate monthly cost

1. Count your steady-state read volume — balance checks, state reads, and event polls per minute across the agent’s perception loop
2. Add your event-detection load — eth_getLogs calls across every contract the agent watches
3. Add simulation and write volume — eth_call/debug_traceTransaction dry-runs plus the transactions the agent actually broadcasts
4. Multiply by your peak-to-average ratio to size RPS, not just monthly RU
5. On BNB, size for the agent’s burst, not its average: a single reasoning step can fan out into dozens of parallel calls in one second, and a fleet of agents reacting to the same on-chain event will spike together — a Growth plan’s RPS ceiling disappears faster than its monthly RU does

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• eth_getLogs access confirmed on your provider before launch — the public BNB endpoint will silently fail every event-detection query your agent depends on
• Client-side rate limiter in front of the agent’s tool layer so a runaway reasoning loop can’t self-throttle into a 429 storm
• WebSocket reconnect + missed-event backfill logic so a dropped subscription never silently blinds the agent’s perception loop mid-run

Benchmark candidate endpoints before you commit — the Chainstack performance dashboard shows real BNB endpoint latency under load, which is the number that determines how tight an agent’s react-and-act loop can run.

Troubleshooting common BNB Chain RPC issues

Issue	Cause	How to fix
eth_getLogs returns empty or errors	Method disabled on public BNB mainnet	Move to a managed endpoint where logs are enabled; never run an agent’s event perception against the public node
-32005 limit exceeded on log queries	Block range too wide for BNB’s log cap	Split the agent’s queries into ≤5,000-block ranges and paginate historical scans
429 Too Many Requests mid-loop	Agent burst exceeded 10K/5min public limit	Move to a managed endpoint and put a client-side rate limiter in front of the agent’s tool calls
Agent acts on stale state	Polling over HTTPS lags sub-second blocks	Switch the perception loop to a WebSocket eth_subscribe stream so the chain pushes updates
WebSocket disconnects, loop goes silent	No reconnect logic on a long-running agent	Use a private WebSocket endpoint with reconnect + backfill of events missed during the gap
Agent calls a non-existent method	Model hallucinated an RPC method name	Ground the agent in the real RPC reference via Chainstack MCP so it writes verified methods, not invented ones

Conclusion

The failure mode here is the one agents are uniquely good at hiding. A BNB agent wired to the public endpoint will read a balance fine, look healthy in every smoke test, and then quietly reason over an empty eth_getLogs result as if no events occurred — or burst past the 33-rps ceiling mid-loop and start dropping the very calls its next decision depends on. There’s no crash. The model just makes a confident, wrong decision and acts on it with real funds, and you find out when the position is already wrong.

The pattern that works is not subtle: run every agent on a private endpoint with eth_getLogs enabled from day one, drive the perception loop over a WebSocket subscription with reconnect-and-backfill so the agent is never silently blinded, and put a rate limiter between the model and the wire so a runaway reasoning step can’t throttle itself. Treat the public endpoint as a wallet-config convenience, never as the substrate an autonomous loop runs on.

Start free, then scale into dedicated capacity as your agent fleet grows.

FAQ

Why can’t I run an AI agent on the public BNB Chain endpoint? Two reasons, and either one is disqualifying. First, BNB disables eth_getLogs on its public mainnet dataseed endpoints, and event detection is how most agents perceive the conditions they act on — without it the agent reasons over blind spots. Second, the public endpoint caps traffic at 10,000 requests per 5 minutes, and an agent’s bursty, parallel call pattern blows through that far faster than a human-paced app would. BNB’s own documentation tells developers to use third-party endpoints for exactly this reason.

How do I handle rate limits when my agent loop fans out parallel calls? Put a client-side rate limiter in front of the agent’s tool layer so the model’s reasoning step can’t translate directly into an uncontrolled request burst, and run on a managed endpoint with real RPS headroom rather than the public 33-rps ceiling. Size the plan to your peak burst, not your average throughput — a fleet of agents reacting to the same on-chain event spikes together, and RPS limits are reached before monthly RU limits are.

How does Chainstack MCP help an AI agent use BNB RPC? The Model Context Protocol lets an agent read Chainstack’s RPC reference and docs before it writes a call, so it uses real, supported BNB methods and parameters instead of hallucinating ones — and it can test the call live against the endpoint. It also lets the agent provision and manage nodes directly, turning “give me a BNB mainnet endpoint” into a one-step tool call rather than a manual deployment.

Do I need an archive node for an agent on BNB? Only if the agent reasons over history. A live agent that reacts to current state runs fine on a full node. But an agent that backtests a strategy, replays past events to build context, or reconstructs the exact conditions behind a prior decision needs archive access — and on Chainstack those calls bill at 2 RU each, so model the cost if your agent does heavy historical replay.

Which SDKs work for building a BNB agent? Because BNB is EVM-compatible, ethers.js and web3.js work without modification — the same provider code that talks to Ethereum talks to BNB. Point the provider at your Chainstack BNB endpoint, and frameworks like LangChain can wrap those calls as agent tools directly.

What should I monitor on a BNB RPC endpoint running an agent? Track 429 throttling rate and -32005 log-range errors as early signals the agent is outgrowing its plan, end-to-end latency on eth_getLogs and eth_call (it sets how tight the react-and-act loop can run), and WebSocket connection health with a count of any missed-event backfills — a silent subscription drop is how an agent goes blind without crashing.

Additional resources

• BNB Smart Chain: BEP-1155 with Truffle & OpenZeppelin — deploy and interact with a token contract on BNB
• Chainstack BNB Smart Chain tooling documentation
• BNB Chain developer documentation
• Blockchain RPC for AI agents: infrastructure guide — Chainstack Blog
• How AI agents talk to blockchains with MCP and RPC — Chainstack Blog
• More BNB Chain tutorials and articles on the Chainstack Blog