Onchain Data and Indexing
Historical onchain data comes from an indexer, never from a scan at request time. Public RPCs cap each eth_getLogs call by block span and by matched-log count, so a full-history scan is thousands of paginated calls that grow with every block and fail on rate limits, timeouts or credits. Back a feed, streak, ranking or dashboard with a one-time backfill into a persistent indexed store that then tails new events — a subgraph, Ponder, a provider data API, or your own indexer. Rebuilding past state from archive-node reads is the same mistake in another shape.
Design contracts event-first: every state change emits an event carrying what the read side needs, because a change with no event is invisible to every indexer, frontend and explorer. Keep aggregation, ranking and pagination offchain; if a result must be committed onchain, store a hash.
Current state is not indexing work. Balances, allowances, ownership and other "as of now" reads are direct contract calls, batched into one request with Multicall3 (0xcA11bde05977b3631167028862bE2a173976CA11, same address on most chains) or a provider balances endpoint. Do not build or operate a subgraph to track a number the chain returns on request.
The read side is not designed until its production home is named. Decide where the indexer runs in production and by which command or service, and write that down next to the architecture — this is the decision that silently stays open, leaving a read side that only ever ran on a laptop.
On The Graph, deploying is not publishing, and the free hosted service is gone (sunset June 2024), so there is no free public endpoint to deploy to:
bashgraph init <slug> # then codegen/build graph auth <deploy-key> graph deploy <slug> # -> Subgraph Studio: testing only
Publish the subgraph from Studio to the network to get the production endpoint, and query it with a Studio API key. Production queries are metered: about 100K free per month, then about $2 per 100K (checked 2026-08-18 — re-read the live pricing page before quoting a budget). Self-hosting a Graph Node or a Ponder process is a fine alternative, but then the host, the persistent store and the process supervision are yours to name.


