OpenScan.AI turns raw blockchain data into a fast, searchable explorer through a small set of well-defined services.
The Big Picture
┌───────────┐ JSON-RPC ┌──────────┐ writes ┌────────────┐│ EVM Chain │ ───────────► │ Indexer │ ─────────► │ Database ││ Node │ │ │ │ (Postgres) │└───────────┘ └──────────┘ └────────────┘ ▲ reads │┌───────────┐ HTTP/REST ┌──────────┐ ││ Browser │ ◄──────────► │ API │ ────────────────┘│ (UI) │ │ Server │└───────────┘ └──────────┘Components
Chain Node
A full or archive EVM node (for example on XDC Network, EVS, Wanchain, or Velas) exposes JSON-RPC endpoints. It is the source of truth — the explorer never trusts anything it can’t verify against the node.
Indexer
The indexer continuously pulls new blocks, transactions, receipts, logs, and traces, then decodes and normalizes them — token transfers, contract metadata, internal transactions — into relational tables optimized for explorer queries. It detects chain reorganizations and rolls back affected rows.
Database
PostgreSQL stores indexed blocks, transactions, addresses, tokens, and contract data. It is sized for the full history of the chain and tuned for read-heavy workloads.
API Server
A REST API (v2) exposes everything the frontend and external developers need: blocks, transactions, addresses, tokens, logs, and stats. The production instance is documented at xdcscan.io/api-docs.
Frontend
The explorer UI that users interact with — server-rendered pages backed by the API, with search across blocks, transactions, addresses, and tokens.
Data Freshness
The indexer trails the chain head by a small, configurable number of confirmations. Under normal conditions new blocks appear in the explorer within seconds of being produced.
Failure Modes
- Node lag — if the chain node falls behind, the explorer shows stale data. Monitor node sync status.
- Reorgs — the indexer detects them and repairs the affected range automatically.
- Database growth — history grows linearly; plan storage accordingly (see Hardware Requirements).