What this prompt does
This prompt casts the AI as a senior web3 engineer and asks it to design a production indexer for on-chain events, specified tightly enough to build — a real subgraph manifest or Ponder config, not pseudocode. The deliverables target the parts most setups get wrong: a schema for your events, reorg handling so chain reorganisations don't leave stale or duplicated data, historical backfill from the deploy block, a clean frontend API shape, indexing-lag monitoring, and handling for proxied contracts at multiple addresses.
The placeholders pin it to your project. [contract] is the contract being indexed, [chain] sets the network whose reorg behaviour the design must handle, [indexer] chooses the tool (The Graph or Ponder, defaulting to Ponder), and [events] lists the events to track so the schema entities, relationships, and derived fields match what your frontend actually queries. Raw RPC calls per render don't scale, which is the whole reason this layer exists.
When to use it
- Your dApp has outgrown reading directly from RPC and needs a queryable indexed backend.
- You need reorg handling so block reorganisations don't leave stale or duplicated data.
- You're backfilling history from a contract's deploy block and want progress tracking.
- You need a defined API shape with queries, filters, and pagination for the frontend.
- You want indexing-lag monitoring so a falling-behind indexer doesn't look like a frontend bug.
- Your contract is proxied across multiple addresses and the indexer must handle that.
Example output
Expect the [indexer] manifest or config plus schema and handler skeletons. For Ponder that's a config file and TypeScript handler stubs; for The Graph it's a subgraph manifest, GraphQL schema, and mapping skeletons. The schema models [events] as entities with relationships and derived fields the frontend needs. You'll also get a reorg-handling approach, a backfill strategy from the deploy block with progress tracking, the queryable API shape, a "how far behind head" health signal for lag, and a plan for proxied contracts spanning multiple addresses.
Pro tips
- List
[events]exactly as they're emitted — "Listed, Sold, OfferMade, OfferAccepted" lets the model design matching entities and derived fields; a vague list produces a vague schema. - Choose
[indexer]deliberately: Ponder is code-first TypeScript, The Graph is manifest-plus-mappings. Name the one your team will maintain. - Wire the lag monitoring from deliverable 5 early; an indexer silently falling behind head looks exactly like a frontend bug and wastes hours of debugging.
- Set
[chain]accurately — reorg depth and finality differ by network, and the reorg-handling design depends on it. - If
[contract]is proxied, say so; deliverable 6 only handles multiple addresses correctly when you flag the proxy upfront. - Confirm the backfill starts from the actual deploy block; starting too late silently drops early events that your frontend may still query.
