Alchemy BNB Smart Chain RPC: How to Evaluate and Configure a BSC Endpoint

If you are searching for an Alchemy BNB Smart Chain RPC endpoint, you most likely need two things at once: the exact BSC network parameters so your wallet or app connects, and a way to decide whether a managed RPC API or a dedicated node is the right long-term home for your traffic. This page covers both. It gives you the BNB Smart Chain mainnet and testnet settings, a working request example, and the evaluation criteria that matter when you move from a quick test to production.

BNB Smart Chain (BSC) is an EVM-compatible chain, so any endpoint that speaks standard JSON-RPC over HTTP or WebSocket will work with the tools you already use: ethers, viem, web3.js, Hardhat, Foundry, and most wallet network dialogs. The provider name matters less than the endpoint's behavior under your real workload, which is what the rest of this page helps you assess.

Chain settings at a glance

Use these values when you add BNB Smart Chain to a wallet, a Hardhat config, or a backend client. The chain ID is the field that most often causes a failed connection, so confirm it first.

OnFinality exposes a public endpoint for both networks, and you can review the full network details on the BNB Smart Chain RPC page and the BNB Chain Testnet RPC page. Public endpoints are useful for prototyping and low-volume reads. For sustained traffic, archive queries, or WebSocket subscriptions, a managed plan or a dedicated node is usually the better fit.

When a shared endpoint is enough, and when it is not

Before you commit to a provider, match the endpoint type to the workload. The same BSC endpoint that is perfect for a hackathon demo can become a bottleneck for an indexer that scans years of logs.

• Prototyping and wallet testing: a public or shared endpoint is fine. You need fast setup and correct chain settings, not capacity guarantees.
• Production dApp reads and writes: a managed RPC API with a defined request budget and failover is the practical default. You get predictable access without operating a node.
• Heavy eth_getLogs, archive reads, or trace calls: these are the workloads that stress shared infrastructure. Plan for archive support and higher limits, or move to a dedicated node.
• Latency-sensitive trading or bots: shared endpoints introduce variable latency. A dedicated node gives you isolated resources and a stable connection.

If you are unsure which category you fall into, start with a managed endpoint and instrument it. Measure error rates and latency under real load before deciding whether to upgrade. The provider selection guide walks through that decision in more depth.

Connecting to BNB Smart Chain

A quick way to confirm your endpoint and chain ID is a single JSON-RPC call. The example below uses the OnFinality public BSC endpoint.

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

A correct response returns the chain ID in hex:

{"jsonrpc":"2.0","id":1,"result":"0x38"}

0x38 is 56 in decimal, which confirms you are on BNB Smart Chain mainnet. If you get a different value, you are pointed at the wrong network.

In JavaScript, the same check with viem looks like this:

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

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

const chainId = await client.getChainId()
const block = await client.getBlockNumber()
console.log({ chainId, block })

For wallets, add a custom network with chain ID 56, symbol BNB, and the RPC URL above. For testnet work, use chain ID 97, symbol tBNB, and the testnet endpoint. Testnet BNB is available from public faucets; the testnet endpoint does not provide funds.

What to compare across BSC RPC providers

Provider choice is a tradeoff between control, cost, and operational effort. The table below frames the comparison by workload rather than by marketing claims. OnFinality appears first because it is the option this site documents in detail, but the columns apply to any provider you evaluate.

Two questions separate serious providers from thin ones. First, does the provider support the methods you actually call — eth_getLogs with wide block ranges, debug_traceTransaction, or archive state at historical blocks? Second, what happens when a node fails: is there automatic failover, or does your app see errors until you intervene? Ask both before you migrate.

Migration checkpoints

If you are moving from another BSC endpoint to a new provider, treat it as a controlled change rather than a URL swap.

1. Inventory your methods. List every JSON-RPC method your app calls, including any debug or trace methods. Confirm each is supported on the target plan.
2. Check archive needs. If you query historical state or wide log ranges, confirm archive availability before cutover.
3. Test in staging. Point a staging environment at the new endpoint and run your integration tests, including error paths.
4. Add failover. Configure a secondary endpoint so a single provider outage does not take down your app.
5. Monitor after cutover. Track error rate, latency percentiles, and rate-limit responses for at least a full traffic cycle.

Keep the old endpoint configured until the new one has proven stable under your real load. Rollback should be a config change, not a redeploy.

Common failure modes and how to debug them

Most BSC RPC problems fall into a small set of categories. The table below maps symptoms to likely causes.

A simple monitoring probe helps you catch these early. Poll eth_blockNumber on a schedule and alert if it stops advancing or if error rates spike.

# Minimal health probe: confirm the node is advancing
curl -s -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Run this from the same region as your application so the latency you measure reflects what your users experience.

Build versus buy for BSC

Running your own BNB Smart Chain node gives you full control, but it also means provisioning hardware that can keep up with BSC's throughput, managing disk growth, applying client upgrades, and handling sync and reorg events. For many teams, that operational load is not the product they want to build.

A managed RPC API removes most of that burden: you get an endpoint, and the provider handles node operations, upgrades, and availability. A dedicated node sits in between — you get isolated resources and predictable performance without managing the underlying infrastructure yourself. OnFinality offers both, and you can compare plans on the RPC pricing page or read about dedicated nodes.

If your workload is bursty or early-stage, start managed and scale up. If you have steady high throughput or strict isolation requirements, a dedicated node is usually the more economical and predictable choice.

Key Takeaways

• BNB Smart Chain mainnet uses chain ID 56; the testnet uses chain ID 97. Confirm the chain ID first when connections fail.
• Public endpoints are fine for prototyping; production traffic benefits from a managed RPC API with failover.
• Archive support, eth_getLogs limits, and WebSocket behavior are the fields that most often decide whether a provider fits.
• Treat a provider migration as a controlled change: inventory methods, test in staging, add failover, and monitor after cutover.
• OnFinality provides managed BSC endpoints and dedicated nodes; review supported RPC networks and RPC pricing to match a plan to your workload.

Frequently Asked Questions

Is Alchemy's BNB Smart Chain RPC the same as any other BSC endpoint? Any endpoint that speaks standard JSON-RPC for chain ID 56 will work with EVM tooling. The differences between providers show up in method support, archive access, rate limits, and failover behavior, not in the basic request format.

What chain ID do I use for BNB Smart Chain? Mainnet is 56 (0x38). The testnet is 97 (0x61). Using the wrong chain ID is the most common cause of a failed wallet connection.

Do I need an archive node for BSC? Only if you query historical state or wide log ranges. Standard recent-block reads and writes work on a regular full node. Confirm archive availability before you rely on it.

Can I use WebSockets on BNB Smart Chain? Yes. BSC supports WebSocket subscriptions for events and new blocks. If you use them in production, add reconnect logic with backoff, since idle connections can be dropped.

How do I move my app from one BSC RPC provider to another? Change the endpoint URL in your configuration, keep a secondary endpoint for failover, and run your integration tests in staging first. No contract or wallet changes are required because the chain ID stays the same.

Where can I see which networks OnFinality supports? The supported RPC networks page lists current networks, and the BNB Smart Chain RPC page has the specific endpoint and chain details.