BNB Chain RPC Guide: How to Connect and Build on BNB Chain (2026)

BNB Smart Chain (BSC) is one of the most active EVM chains in Web3. High transaction volume, a large retail user base, fast 3-second blocks, deep DeFi liquidity: all of it makes BSC a practical choice for protocols that need throughput without Ethereum-level gas fees.

To interact with BNB Chain programmatically, your application connects through a JSON-RPC endpoint. This guide covers the methods that matter, how to connect with ethers.js and Web3.py, BSC-specific production behavior, common issues, what to look for in a provider.

For MetaMask setup and the BoltRPC BNB Chain endpoint URL, see the BNB Chain RPC endpoint page.

---

What is a BNB Chain RPC Endpoint

A BNB Chain RPC endpoint is an HTTP or WebSocket URL that exposes the BSC JSON-RPC API. Your application sends method calls to this URL and receives on-chain data in return.

HTTP endpoints handle request-response interactions: reading balances, calling contracts, submitting transactions, querying event logs. Each call opens a connection, sends a request, receives a response, closes.

WebSocket endpoints maintain a persistent connection and support event subscriptions via eth_subscribe. Use WSS when your application needs to react to new blocks or contract events in real time without polling.

BNB Chain is EVM-compatible, so every standard Ethereum JSON-RPC method works on BSC with the same syntax. The only required change is pointing your provider at a BSC RPC URL and setting chain ID 56.

---

Example BNB Chain RPC Methods

Standard EVM Methods on BSC

These methods work identically on BNB Chain as they do on Ethereum:

import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider(
  'https://eu.endpoints.matrixed.link/rpc/bsc?auth=YOUR_KEY'
);

// Read BNB balance
const balance = await provider.getBalance('0xYourAddress');
console.log('Balance:', ethers.formatEther(balance), 'BNB');

// Call a BEP-20 or DeFi contract (read-only)
const contract = new ethers.Contract(contractAddress, abi, provider);
const result = await contract.someReadMethod();

// Get current block
const blockNumber = await provider.getBlockNumber();

// Fetch full block data
const block = await provider.getBlock(blockNumber, true);
console.log('Block txs:', block.transactions.length);

// Get transaction receipt
const receipt = await provider.getTransactionReceipt(txHash);
console.log('Status:', receipt.status); // 1 = success

// Estimate gas for a call
const estimate = await provider.estimateGas({
  to: contractAddress,
  data: encodedCallData
});

BNB Chain-Specific Considerations for Method Usage

eth_getLogs on BSC: BNB Chain’s high transaction volume means popular token contracts generate an enormous number of events. BEP-20 Transfer events for tokens like BUSD, CAKE, or BNB-wrapped assets touch millions of logs per day. Providers enforce block-range limits on eth_getLogs more strictly on BSC than on lower-throughput chains. Keep range sizes to 5,000 blocks or fewer for broad log queries.

eth_getBlockByNumber with full transactions: At 3-second block times, BSC produces around 28,800 blocks per day. Indexers fetching full block objects with transaction details should batch requests or use pagination rather than sequential single-block calls.

eth_sendRawTransaction: BSC’s mempool sees very high competition from bots and arbitrageurs. Gas price matters for transaction inclusion. Always call eth_gasPrice before building a transaction rather than using cached or static values.

eth_subscribe (WSS): Real-time subscriptions on BSC fire frequently. A newHeads subscription delivers a new block event roughly every 3 seconds. A logs subscription on a high-activity contract like PancakeSwap’s router can deliver thousands of events per minute during peak trading. Design your WebSocket handler to be non-blocking.

---

Public BNB Chain RPC Endpoints

Use these for development and testing. For production workloads, a dedicated provider avoids the congestion and rate limits that affect public endpoints.

Provider	HTTP Endpoint	Chain ID
BNB Chain (official)	https://bsc-dataseed.binance.org	56
BNB Chain (official)	https://bsc-dataseed1.defibit.io	56
BNB Chain (official)	https://bsc-dataseed1.ninicoin.io	56
Ankr	https://rpc.ankr.com/bsc	56
BoltRPC (free trial)	https://eu.endpoints.matrixed.link/rpc/bsc?auth=YOUR_KEY	56

The official Binance public endpoints are among the most congested in Web3. Under load they drop connections, return stale block data, time out without warning. Use them for local testing and prototyping, not production traffic.

---

Connecting Step by Step

ethers.js

import { ethers } from 'ethers';

// HTTP provider
const provider = new ethers.JsonRpcProvider(
  'https://eu.endpoints.matrixed.link/rpc/bsc?auth=YOUR_KEY'
);

// Verify chain
const network = await provider.getNetwork();
console.log('Chain ID:', network.chainId); // 56n

// WebSocket provider for real-time subscriptions
const wsProvider = new ethers.WebSocketProvider(
  'wss://eu.endpoints.matrixed.link/ws/bsc?auth=YOUR_KEY'
);

// Subscribe to new blocks
wsProvider.on('block', (blockNumber) => {
  console.log('New BSC block:', blockNumber);
});

// Subscribe to BEP-20 Transfer events
const erc20Abi = ['event Transfer(address indexed from, address indexed to, uint256 value)'];
const token = new ethers.Contract(tokenAddress, erc20Abi, wsProvider);

token.on('Transfer', (from, to, value) => {
  console.log(`Transfer: ${from} to ${to}, amount: ${ethers.formatEther(value)}`);
});

// Clean up
process.on('SIGINT', async () => {
  await wsProvider.destroy();
});

Web3.py

from web3 import Web3

# Connect via HTTP
w3 = Web3(Web3.HTTPProvider(
    'https://eu.endpoints.matrixed.link/rpc/bsc?auth=YOUR_KEY'
))

print('Connected:', w3.is_connected())
print('Chain ID:', w3.eth.chain_id)  # 56

# Read BNB balance
balance = w3.eth.get_balance('0xYourAddress')
print('Balance:', w3.from_wei(balance, 'ether'), 'BNB')

# Interact with a BEP-20 contract
bep20_abi = [...]  # Standard ERC-20/BEP-20 ABI
token = w3.eth.contract(address=token_address, abi=bep20_abi)
total_supply = token.functions.totalSupply().call()
print('Total supply:', total_supply)

# Send a transaction
account = w3.eth.account.from_key('YOUR_PRIVATE_KEY')
tx = token.functions.transfer(recipient, amount).build_transaction({
    'chainId': 56,
    'from': account.address,
    'gas': 100000,
    'gasPrice': w3.eth.gas_price,
    'nonce': w3.eth.get_transaction_count(account.address),
})
signed = account.sign_transaction(tx)
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
receipt = w3.eth.wait_for_transaction_receipt(tx_hash)
print('Status:', receipt['status'])

curl

# Get current block number
curl -X POST https://eu.endpoints.matrixed.link/rpc/bsc?auth=YOUR_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# Get BNB balance
curl -X POST https://eu.endpoints.matrixed.link/rpc/bsc?auth=YOUR_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xYourAddress","latest"],"id":1}'

# Get latest block with transactions
curl -X POST https://eu.endpoints.matrixed.link/rpc/bsc?auth=YOUR_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",true],"id":1}'

---

BNB Chain-Specific Considerations

Proof of Staked Authority (PoSA)

BNB Chain uses Proof of Staked Authority, a hybrid consensus model. A set of 21 active validators is elected by BNB holders to produce blocks in rotation. Each validator takes turns proposing and confirming blocks. This is fundamentally different from Ethereum’s Proof of Stake, where the validator set is large and randomly selected per slot.

PoSA produces fast 3-second blocks but with a smaller validator set than Ethereum. Finality on BSC is probabilistic: a transaction is considered final after approximately 15 blocks, or around 45 seconds. For high-value operations, wait for this confirmation depth before treating a transaction as irreversible.

Validator Rotation and Brief Forks

Because only 21 validators produce blocks in round-robin, occasional short-lived forks occur when validators produce competing blocks. These resolve quickly, but they mean BSC sees more frequent chain reorganizations than Ethereum. A reorg of 1-2 blocks is normal on BSC. Applications should not treat a single confirmation as final for anything involving real economic value.

Fast Blocks and Block Number Arithmetic

At 3-second block times, BSC produces roughly 28,800 blocks per day. If your application uses block-number arithmetic for timing, adjust your assumptions. One day on BSC is approximately 28,800 blocks, not the 7,200 blocks you would expect on Ethereum.

---

Common Issues in Production

eth_getLogs Range Limits

BSC’s high block frequency makes large log queries expensive. Providers cap the block range for eth_getLogs calls. A query spanning 100,000 blocks on BSC covers only about 3.5 days, but still returns an enormous number of log entries for active contracts.

Use chunked queries to stay within limits:

async function getBscLogsInChunks(provider, filter, chunkSize = 5000) {
  const logs = [];
  let fromBlock = filter.fromBlock;
  const toBlock = filter.toBlock === 'latest'
    ? await provider.getBlockNumber()
    : filter.toBlock;

  while (fromBlock <= toBlock) {
    const chunkEnd = Math.min(fromBlock + chunkSize - 1, toBlock);
    const chunk = await provider.getLogs({
      ...filter,
      fromBlock,
      toBlock: chunkEnd
    });
    logs.push(...chunk);
    fromBlock = chunkEnd + 1;
  }

  return logs;
}

Reorg Handling

BSC’s 1-2 block reorgs mean a transaction receipt you received could be invalidated if the block it was in gets reorganized away. Do not treat receipt.status === 1 at one confirmation as permanent.

Safe pattern: wait for at least 5-10 block confirmations before marking a transaction as finalized in your system.

async function waitForSafeConfirmation(provider, txHash, confirmations = 10) {
  const receipt = await provider.getTransactionReceipt(txHash);
  if (!receipt) throw new Error('Transaction not found');

  const currentBlock = await provider.getBlockNumber();
  const depth = currentBlock - receipt.blockNumber;

  if (depth < confirmations) {
    // Wait for more blocks
    await provider.waitForTransaction(txHash, confirmations);
  }
  return receipt;
}

High-Throughput Mempool

BSC’s busy mempool means gas price competition is real. Transactions submitted with low gas prices can sit unconfirmed for extended periods during high activity. Always fetch a fresh eth_gasPrice before building a transaction. Add a buffer for time-sensitive submissions.

Provider Rate Limits

Public BSC endpoints enforce strict rate limits. Under heavy use, responses slow down or requests get dropped entirely. During peak network activity (major token launches, DEX volume spikes, Binance-driven user traffic surges), public endpoint reliability degrades further. Production applications need dedicated infrastructure.

---

Choosing a Provider

When evaluating a BNB Chain RPC provider, consider:

Infrastructure isolation. Shared public endpoints on BSC are the most congested in Web3. Dedicated or semi-dedicated infrastructure keeps your response times consistent regardless of what other applications are doing on the same endpoint.

WebSocket support. At 3-second block times, WebSocket subscriptions are more efficient than polling for event-driven applications. Not all providers offer stable WSS endpoints for BSC.

Pricing model clarity. Heavy BSC workloads involve high volumes of eth_getLogs and eth_call. On compute-weighted billing, these methods multiply costs quickly at scale. Understand the per-method cost structure before committing to a provider.

Security posture. For production financial applications, the provider operating your RPC infrastructure should hold recognized security certifications. ISO/IEC 27001:2022 is the standard benchmark.

BoltRPC provides BNB Chain RPC on infrastructure operated by Matrixed.Link, which is ISO/IEC 27001:2022 certified. Pricing is flat monthly, not per-method, so high-volume BSC workloads have predictable costs. Trusted by Chainlink, Tiingo, Gains Network, Enjin.

Start your free 2-week trial: trial.boltrpc.io

For endpoint URL, chain ID, MetaMask setup, see the BNB Chain RPC endpoint page.

---

FAQ

What is the BNB Chain RPC endpoint URL?

The BoltRPC BNB Chain endpoint is https://eu.endpoints.matrixed.link/rpc/bsc?auth=YOUR_KEY for HTTP and wss://eu.endpoints.matrixed.link/ws/bsc?auth=YOUR_KEY for WebSocket. Replace YOUR_KEY with your key from trial.boltrpc.io. Chain ID is 56.

Is BNB Chain RPC compatible with Ethereum libraries?

Yes. BNB Chain is fully EVM-compatible. ethers.js, viem, web3.py, web3.js all work with BSC RPC endpoints without modification. Set the provider URL to a BSC endpoint and ensure your chain ID is 56. No other code changes are required.

Why does eth_getLogs fail on BNB Chain?

Most failures are caused by querying too large a block range. BSC’s high transaction volume means a wide block range returns too many results for a provider to serve in a single response. Reduce your fromBlock to toBlock range. Start with chunks of 2,000-5,000 blocks and adjust based on the error response.

How many block confirmations are safe on BNB Chain?

BNB Chain’s PoSA consensus with 21 validators means short reorgs of 1-2 blocks occur occasionally. For most dApp interactions, 5 confirmations is sufficient. For high-value transfers or bridge operations, wait for 15 confirmations, approximately 45 seconds, before treating a transaction as final.

---