Web3 · Engineering
Blockchain Indexers & Subgraphs
Your contracts emit events, but a dApp cannot scan the chain log by log every time a user opens a page. Subgraph and blockchain indexer development is the data-layer practice that turns raw on-chain events and logs into a fast, queryable application API. We write event handlers, handle reorgs, build GraphQL and REST query layers, run backfills, and keep the index in sync with the chain head.
- Assetizelive RWA product we indexon-chain data layer
- GraphQLand REST query layershow apps read the index
- Reorg-safehandlers that survive reorgschain-head sync
In short
What is Blockchain Indexers & Subgraphs?
Subgraph and blockchain indexer development is a data-layer service for dApp teams that turns raw on-chain events into a fast, queryable GraphQL or REST API. The index handles chain reorgs and stays in sync with the chain head. We built the on-chain indexing layer behind Assetize, a live RWA tokenization product.
What we deliver
Concrete artefacts, not capabilities
- 01
Subgraph or custom indexer mapping on-chain events to a queryable schema.
- 02
Event handlers with reorg handling and chain-head sync.
- 03
GraphQL and REST query layer over the indexed entities.
- 04
Backfill pipeline that replays historical blocks from genesis.
- 05
Monitoring for indexing lag, failed handlers, and head drift.
Key concepts
Key terms, defined
- Subgraph
- A subgraph is an open specification, popularized by The Graph, that defines how on-chain events are indexed into a GraphQL API. It pairs an entity schema with handler code that runs on each matching event, producing a queryable dataset that front ends read instead of scanning the chain directly.
- Reorg handling
- Reorg handling is the logic that keeps an index consistent when a blockchain rolls back recently mined blocks and replaces them. Without it, an indexer serves data from orphaned blocks. Correct handling rolls back the affected entities and re-applies events from the canonical chain so queries never reflect a discarded fork.
- Backfill
- A backfill is the initial pass where an indexer replays historical blocks from a chosen start block to the current head, building complete state before serving live traffic. It lets an application launch with full history rather than only data from the moment the index started, and it is re-run when the schema changes.
- Chain-head sync
- Chain-head sync is the steady-state process of ingesting each new block as it is mined so the index trails the latest on-chain state by seconds, not minutes. Indexing lag is the measured gap between the head block and the last block the index has processed, and it is a core reliability metric.
How we work
Engagement phases
Schema & event mapping
We read your contracts and decide which events, logs, and call traces the application actually needs to read. From that we design the entity schema the front end will query, then map each on-chain event to a handler that writes those entities. The schema is the contract between chain and app, so we shape it around real query paths, not a raw mirror of every log.
Handlers & reorg safety
We write the handlers that transform events into entities, then make them survive reorgs. When the chain rolls back blocks, the index must roll back with it rather than serve stale or doubled data. We test handlers against forked mainnet state and replayed reorg scenarios so the index stays consistent with the canonical chain head under load.
Backfill & sync
We backfill the index from a chosen start block, replaying historical events so the application has complete data on day one. Then we connect the index to the live chain head and watch the lag. A correct index is useless if it trails the chain by minutes, so we tune ingestion until queries reflect on-chain state within seconds.
Query layer & operate
We expose the indexed entities through a GraphQL and REST query layer the front end consumes, with pagination, filtering, and the resolvers your screens need. After launch we monitor indexing lag, failed handlers, and head drift on a defined SLA, ship schema migrations as the contracts evolve, and hand over runbooks so an in-house team can operate the index.
Tech stack
What we build on
- The GraphSubgraphs
- AssemblyScriptMappings
- GraphQLQuery
- PonderIndexer
- PostgreSQLStore
- viemRPC
- TypeScriptHandlers
- DockerDeploy
- The GraphSubgraphs
- AssemblyScriptMappings
- GraphQLQuery
- PonderIndexer
- PostgreSQLStore
- viemRPC
- TypeScriptHandlers
- DockerDeploy
Scope
When this fits and when it doesn't
| This fits when | This doesn't fit when |
|---|---|
| Your dApp front end is slow or brittle because it reads on-chain state directly through RPC calls. | You only need a single current value that one direct contract read already returns cheaply. |
| You need historical on-chain data, aggregations, or relationships that a single contract call cannot return. | The primary work is writing or auditing the smart contracts themselves, not reading their data. |
| You want a GraphQL or REST API over your contract events that survives chain reorgs. | You want an off-chain analytics warehouse with no connection to live on-chain events. |
Related services
Adjacent engagements
- Web3
Smart Contract Development
Solidity, Vyper, and Move contracts engineered for third-party audit, with tests and monitoring.
- Web3
DeFi Protocol Development
Lending, perpetuals, yield, and vault infrastructure spec'd for third-party audit.
- AI
RAG & Retrieval Pipelines
Retrieval pipelines that ground LLMs in your data: embeddings, vector stores, reranking, evaluations.
Frequently asked questions
A subgraph follows The Graph specification: an entity schema plus event handlers that produce a hosted GraphQL API, which is the fastest path for most EVM dApps. A custom indexer is purpose-built code, often on Ponder or a dedicated service over PostgreSQL, used when you need control over the database, non-standard sources, or query shapes the subgraph model does not express. We pick based on your query paths and operational constraints.
Direct contract reads work for a single current value, but they cannot return history, aggregations, or relationships across many events without scanning the chain. That gets slow and expensive fast, and it ties your front end to RPC reliability. An index pre-computes those entities into a database, so a dApp queries an API in milliseconds instead of replaying logs on every page load.
When the chain rolls back recent blocks, the index must roll back with it. Our handlers track which entities each block produced, so a reorg reverts those entities and re-applies events from the canonical chain. We test this against replayed reorg scenarios on forked state. Without reorg handling, an index quietly serves data from orphaned blocks, which is one of the most common indexing bugs.
We backfill from a chosen start block so the application launches with complete history, then sync to the chain head and tune ingestion until queries reflect on-chain state within seconds. We monitor indexing lag as a core reliability metric. If the index falls behind the head, alerts fire before users see stale data, and the handlers catch up without losing or doubling events.
Yes. We built the on-chain data and indexer layer behind Assetize, a live real-world-asset tokenization product. That work covered mapping its contract events into a queryable schema, exposing the entities the application reads, and keeping the index in sync with the chain. The same engineering discipline behind our audited contract work backs how we build and operate an index.
Last reviewed · Reviewed by Metaborong engineering team
Tell us what you are building.
We build what large agencies under-deliver and freelancers can't architect, across Web3 protocols, AI agents, and SaaS products. Tell us what you are building. We will tell you how we would approach it, no pitch deck, no fluff, no commitment required.