# Blockchain Indexers & Subgraphs Subgraph and blockchain indexer development: turn on-chain events into fast, queryable application data. Built the indexing layer for Assetize. Canonical: https://www.metaborong.com/services/web3/blockchain-indexers-subgraphs Service: web3/blockchain-indexers-subgraphs ## Overview 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. ## What is it? 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 - Subgraph or custom indexer mapping on-chain events to a queryable schema. - Event handlers with reorg handling and chain-head sync. - GraphQL and REST query layer over the indexed entities. - Backfill pipeline that replays historical blocks from genesis. - Monitoring for indexing lag, failed handlers, and head drift. ## Key concepts **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 1. **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. 2. **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. 3. **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. 4. **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 The Graph (Subgraphs), AssemblyScript (Mappings), GraphQL (Query), Ponder (Indexer), PostgreSQL (Store), viem (RPC), TypeScript (Handlers), Docker (Deploy) ## When this fits ### Fits when - Your dApp front end is slow or brittle because it reads on-chain state directly through RPC calls. - You need historical on-chain data, aggregations, or relationships that a single contract call cannot return. - You want a GraphQL or REST API over your contract events that survives chain reorgs. ### Does not fit when - You only need a single current value that one direct contract read already returns cheaply. - The primary work is writing or auditing the smart contracts themselves, not reading their data. - You want an off-chain analytics warehouse with no connection to live on-chain events. ## FAQ ### What is the difference between a subgraph and a custom indexer? 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. ### Why not just read on-chain state directly from the contract? 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. ### How do you handle chain reorganizations? 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. ### How fresh is the data, and what happens to history? 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. ### Have you built an indexing layer for a production product? 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.