Indexing Layer

The indexing layer is where raw chain data becomes explorer data — decoded, normalized, and queryable in milliseconds.


What the Indexer Does

Reading a blockchain directly is slow: data is stored for consensus, not for queries like “all token transfers to this address.” The indexer rebuilds the chain’s history into a relational model designed for exactly those questions.

For every block it processes, the indexer:

  1. Fetches the block, its transactions, receipts, and traces from the chain node.
  2. Decodes logs and input data against known ABIs and token standards (ERC-20, ERC-721, ERC-1155).
  3. Derives higher-level facts: token transfers, internal transactions, address activity, contract creations.
  4. Writes everything to PostgreSQL in a single consistent transaction per block range.

Catching Up vs. Following the Head

  • Initial sync — the indexer backfills history in parallel ranges. A full archive backfill can take hours to days depending on chain size and hardware.
  • Realtime mode — once caught up, it follows the chain head block by block, trailing by a configurable confirmation depth.

Reorg Handling

EVM chains can reorganize recent blocks. The indexer tracks block hashes; when a parent hash doesn’t match what it stored, it rolls back the affected range and re-indexes from the canonical chain. This is why the explorer trails the head by a few confirmations.

The Database

PostgreSQL holds the indexed data. Key workload traits:

  • Read-heavy after initial sync; write-heavy during backfill.
  • Large and growing — plan disk for full history plus indexes.
  • Backup-friendly — standard pg_dump / volume snapshots work; see Persistent Storage & Backups.

AI Insights

The AI features described in AI Insights run on top of the indexed data — summaries and explanations are generated from the same normalized records the API serves, never from guesses about the chain.

Tuning

  • Match the indexer’s concurrency to your node’s capacity; tracing-heavy chains need fewer parallel ranges.
  • Keep the indexer and database on the same host or low-latency network segment.
  • Watch the “blocks behind head” metric — it’s the single best health signal (see Monitoring).

Next Steps