What is a Binance Smart Chain archive node and when do you need one?

If you searched for a Binance Smart Chain archive node, you probably hit one of two walls: a historical query returned an error, or a provider told you archive access costs more. This page explains what an archive node actually stores, how to tell whether you need one, and how to connect to archive-capable BNB Chain infrastructure without over-provisioning.

Do you actually need an archive node?

Most applications do not. A standard full node keeps recent state and the full chain of blocks, which is enough for sending transactions, reading current balances, and subscribing to new events. Archive nodes are for queries that reach back into older state.

Use this quick test before you provision anything:

• If you only read the latest block or the last few thousand blocks, a full node is fine.
• If you need a balance, storage slot, or contract call result at a specific block from months or years ago, you need archive state.
• If you run an indexer that replays history from genesis, you need archive state plus a plan for sustained historical reads.
• If you build tax, accounting, or audit tooling, archive state is usually a hard requirement because you must reconstruct holdings at arbitrary timestamps.

A useful rule: the moment you pass an explicit historical block number into a query and expect a correct answer, you are in archive territory.

What an archive node stores that a full node does not

BNB Smart Chain is EVM-compatible, so the archive concept matches Ethereum. A node maintains two things: the chain of blocks and transactions, and the state trie that maps accounts and contracts to their current values.

A full node prunes old state to save disk. It can still tell you what happened in block 20,000,000 if you ask for the transactions in that block, because blocks are retained. What it cannot reliably do is answer "what was this account's balance at block 20,000,000" or "what value did this storage slot hold then," because the state at that height has been discarded.

An archive node keeps every historical state root, so state queries at any past block resolve correctly. That is the entire difference, and it is why archive nodes are much larger and more expensive to operate.

Chain settings at a glance

When you configure a client or wallet for BNB Chain, use the correct network parameters. The table below reflects the mainnet and testnet settings you will need.

For a managed endpoint, OnFinality exposes BNB Smart Chain through its BNB Chain RPC service. Testnet work should point at the BNB Chain Testnet endpoint so you do not accidentally query production state.

How to query historical state over JSON-RPC

The methods that require archive state are the ones that accept a block parameter. If you pass a block number instead of latest, the node must be able to resolve state at that height.

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getBalance",
    "params": ["0x0000000000000000000000000000000000000000", "0x1B4AF0"]
  }'

The second parameter is the block number in hex. Replace it with the historical block you care about. The same pattern applies to eth_getStorageAt, eth_getCode, eth_getTransactionCount, and eth_call when you pass a block tag.

In JavaScript with a standard EVM library, the block tag is the last argument:

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://bnb.api.onfinality.io/public");

// Read a balance at a specific historical block
const balance = await provider.getBalance(
  "0x0000000000000000000000000000000000000000",
  28_000_000
);

console.log(balance.toString());

If the endpoint is not archive-capable, these calls typically fail with a message about missing trie node or state not available, rather than returning a wrong number. That error is your signal that you are pointed at a pruned node.

Archive access options for BNB Chain

There are three practical ways to get archive state, and they differ mainly in how much operational work you take on.

OnFinality provides both a managed RPC API service and dedicated node options for BNB Chain. The right choice depends on how predictable your historical query volume is. Spiky, occasional archive reads usually fit a managed endpoint; continuous replay or heavy eth_getLogs and state reads often justify a dedicated node.

Production readiness checklist

Before you route production traffic at archive state, confirm the following:

• Your client passes explicit block numbers only where archive state is required, so you do not pay archive cost for latest-state reads.
• You have a fallback endpoint or a second provider path for when a single endpoint is degraded.
• You understand your historical read volume, especially for eth_getLogs ranges, which can be the heaviest archive workload.
• You have tested the same query on testnet before pointing it at mainnet.
• You know which block range your application actually needs, so you do not request more history than necessary.

If you are still deciding between shared and dedicated capacity, the RPC provider selection guide covers the evaluation criteria in more depth.

Common failure modes and how to read them

Archive problems usually show up as specific errors rather than silent wrong answers. Knowing the symptom saves debugging time.

A frequent mistake is assuming every RPC endpoint is archive-capable. Many public and shared endpoints are not, and they will fail historical state calls. Always verify archive support before you build a dependency on it.

Sizing and cost considerations

Archive nodes are large because they retain all historical state. Disk, sync time, and I/O are the dominant costs, and they grow with chain age. That is why archive access is usually priced differently from standard RPC.

When you compare options, look at how archive reads are billed or limited, whether WebSocket archive subscriptions are supported, and whether the provider keeps archive state for the full chain history or only a recent window. For current plan details, see RPC pricing and the supported RPC networks list to confirm BNB Chain coverage.

If your workload is steady and high-volume, a dedicated node can be more predictable than metered archive calls. If it is occasional, a managed endpoint avoids the overhead of running and syncing your own archive node.

Key Takeaways

• An archive node keeps historical state, so you can query balances, storage, and contract state at any past block.
• Full nodes retain blocks but prune old state, which is why historical state queries fail against them.
• You need archive state when you pass explicit historical block numbers, replay history, or build audit and accounting tools.
• BNB Smart Chain mainnet uses chain ID 56; testnet uses chain ID 97.
• OnFinality offers managed RPC and dedicated node options for BNB Chain, so you can choose based on workload rather than hardware.
• Verify archive support before depending on it, and split wide log queries to avoid timeouts.

Frequently Asked Questions

Is a BNB Chain archive node the same as an Ethereum archive node?

Conceptually yes. BNB Smart Chain is EVM-compatible, so the archive model, the JSON-RPC methods that need historical state, and the failure symptoms are the same. The chain settings differ, so use chain ID 56 for mainnet and 97 for testnet.

Can I use a public RPC endpoint for archive queries?

Sometimes, but not reliably. Many public and shared endpoints run pruned full nodes and will return a missing trie node error for historical state. Confirm archive support before building on an endpoint.

How far back does archive state go?

It depends on the provider or your own node configuration. Some keep full history; others keep a recent window. If your application needs deep history, confirm the archive depth explicitly.

Do I need a dedicated node for archive access?

Not always. Occasional historical reads usually fit a managed endpoint. Continuous replay, heavy log queries, or isolation requirements are better served by a dedicated node.

Why does my historical query return an error instead of a wrong value?

Because the node cannot resolve state at that height. A pruned node does not have the historical state root, so it fails the request rather than guessing. Point the query at an archive-capable endpoint to fix it.