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 smallereth_getLogswindows 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
