---
name: avax-indexing
description: Build Avalanche analytics with explicit chain coverage, checkpoints and freshness instead of unbounded RPC scans.
---

# Indexing & data quality

Source review: 2026-09-06. Recheck network-dependent facts before use.

1. Identify the product's existing indexed data plane and its coverage. Use it when it is the application's designated source; do not silently replace missing indexed data with a different upstream. For a new project compare indexed APIs with bounded RPC/event ingestion according to the needed history.
2. Record network, deployment start block, event ABI versions, cursor semantics and archive requirements. Distinguish event history from historical state; an RPC provider may expose one without the other.
3. For direct log ingestion, use bounded ranges with persisted checkpoints and adaptive backoff. Deduplicate with chain ID, transaction hash and log index; preserve block hash and raw provenance. Handle removed/replaced data and replay without double counting.
4. For Avalanche Data API integration, inspect supported chains and endpoint schemas. Its authenticated plans use an API key and rate limits; honor 429 retry guidance. Keep keys on the server or in a supported secret store.
5. Expose observed-through block/time, freshness and missing coverage in the product. Keep unknown prices, unavailable pools and incomplete history distinct from zero. Reconcile a sample against receipts and source events before declaring a metric reliable.

**Evidence to return:** coverage contract, resumable cursor, deduplication proof, freshness semantics and sample reconciliation. A fast-finality chain still does not make an incomplete index complete.

## Primary sources

- [Avalanche Data API usage](https://build.avax.network/docs/api-reference/data-api/usage)
- [C-Chain RPC reference](https://build.avax.network/docs/rpcs/c-chain)

## Execute resumable canonical ingestion

Inspect `examples/core/indexer.mjs` from the complete bundle root. Bind each checkpoint to chainId, contract and deploymentBlock. Identify events by blockHash, transactionHash and logIndex. Bound chunkSize and maxChunks per run; report nextBlock/indexedThrough and complete/partial. Persist validated chunks atomically with a single serialized writer.

Check stored anchors and range-end hashes before commit. Validate each log's address/range/hash; reject removed or drifting logs. Deduplicate overlaps/retries. Never advance on failed reads or clamp inconsistent negative derived balances to zero.

On a reorg, find a retained canonical ancestor, discard orphaned events and replay. If retained anchors cannot establish one, restart from deploymentBlock. Persist the rewind even if replacement blocks have not arrived. A chosen confirmation lag is not a universal finality guarantee.

Run `node --test examples/core/indexer.test.mjs` and `node examples/core/verify.mjs`. The latter creates actual events and a local reorg, then reconciles canonical ledger and browser receipt state. The file-based custody index is educational: production scale requires deliberate transactional storage, retention and writer ownership.

Reuse the application's designated authoritative data plane. Do not silently replace unavailable indexed data with a different upstream. Show observed-through time/block, completeness and missing prices; event coverage does not guarantee archive-state access.