Claude/ChatGPT Prompt to Build a Blockchain Event Indexer

What this prompt does

This prompt designs a blockchain event indexer — the underestimated data layer behind on-chain dashboards. You set the [contract_type], [target_chain], [event_list], and [consumer_applications], and it builds a listener using [web3_library] against [rpc_provider] that handles reorgs by waiting [confirmation_depth] confirmations, plus historical backfill, data transformation, a database layer, an API, reliability handling, and performance targets.

The structure works because naive indexers break exactly where this prompt forces design effort. Backfill from [start_block] uses [batch_size] ranges with a resumable checkpoint, transformation maps raw events to [database_schema] and computes [derived_fields], storage uses [database] with indexes on [indexed_columns], the API ([api_type]) serves [api_queries] with real-time updates via [realtime_method], and reliability covers [failure_scenarios] including failover to [backup_rpc] — the gaps that silently corrupt indexed data. The [consumer_applications] and [target_throughput] inputs shape the schema and caching, so the design fits the analytics dashboards and trading interfaces that will actually query it.

When to use it

• You are building the data layer behind an on-chain dashboard or analytics tool
• You need reorg handling so finalized data is not built on orphaned blocks
• You need resumable backfill from [start_block] that survives interruption
• You want a queryable [api_type] over indexed events with pagination and filtering
• You need RPC failover to [backup_rpc] and retry handling for reliability
• You want aggregation views like 24h volume precomputed for fast queries
• You want real-time updates pushed via [realtime_method]

Example output

Expect a service design: a listener using [web3_library] subscribing to [event_list] with [confirmation_depth] reorg handling, a backfill routine iterating [batch_size] block ranges with a saved checkpoint, a transformation layer mapping events to [database_schema] and computing [derived_fields], a [database] schema with tables [table_list], indexes on [indexed_columns], and materialized views for [aggregation_queries], an [api_type] exposing [api_queries] with filtering by [filter_params] and [realtime_method] subscriptions, plus reliability handling for [failure_scenarios] with [backup_rpc] failover and a health endpoint. A caching layer using [caching_strategy] is described for the queries that get hit most often.

Pro tips

• Set [confirmation_depth] to your chain's reorg reality; too shallow indexes orphaned blocks, too deep adds latency to finalized data
• Always make backfill resumable from a checkpoint — indexing from [start_block] can take hours, and a crash without checkpointing means starting over
• Tune [batch_size] to avoid RPC timeouts; large ranges fail on busy contracts, so smaller eth_getLogs windows are safer
• Plan [indexed_columns] around your real [api_queries], since the database indexes are what keep queries fast at volume
• Precompute [aggregation_queries] into materialized views rather than calculating them on every request under load
• Configure [backup_rpc] failover from the start; single-provider indexers stall the moment that provider has an incident
• Validate [derived_fields] like USD-at-time-of-swap carefully, because a wrong price source quietly corrupts every downstream aggregation