Chain Node Layer

The chain node is the foundation of every explorer deployment — it is the only component that talks to the blockchain itself.

Role in the Stack

The indexer never connects to the peer-to-peer network directly. Instead it queries an EVM node over JSON-RPC for everything it needs:

• eth_getBlockByNumber — block headers and transaction lists
• eth_getTransactionReceipt — status, gas used, and logs
• debug_traceTransaction / trace_block — internal transactions and call traces
• eth_getLogs — event logs for token and contract indexing
• eth_chainId / net_version — sanity checks that the node is on the right network

Full vs. Archive Nodes

For a production explorer, run an archive node — features like “balance at block N” and full internal-transaction tracing depend on it.

Requirements for the Node

• Archive mode enabled with tracing APIs available.
• Stable and synced — an unsynced node means a stale explorer. Track sync status in your monitoring.
• Dedicated — don’t share the node between the indexer and unrelated production traffic; tracing calls are heavy.
• Local or low-latency — the indexer issues thousands of RPC calls per block range; keep latency minimal.

Supported Networks

OpenScan.AI works with EVM-compatible chains. It runs in production on XDC Network (xdcscan.io) and supports EVS, Wanchain, and Velas. Any EVM chain with standard JSON-RPC plus tracing support can be indexed.

Operating the Node

• Follow your chain’s official documentation for binary, snapshot, and configuration details.
• Enable the eth, net, web3, debug, and trace (or equivalent) RPC namespaces for the indexer’s exclusive use.
• Restrict RPC access to the indexer host — never expose tracing endpoints publicly.
• Plan for chain upgrades: see Network Upgrades.

Next Steps

• Indexing Layer — what consumes the node’s data.
• Running an Archive Node — a practical setup walkthrough.