Blockchain Data Indexing
Blockchain data indexing turns raw on-chain events into structured data your app can query instantly. Subgraphs on The Graph cover most cases; real-time, cross-chain, or high-volume products need Substreams, Ponder, Subsquid, or a custom indexer, and we build and operate all of them.
Reviewed by Arsenii Petrovich, Infrastructure & DevOps Lead at ProtofireLast reviewed: August 2026
Blockchain data indexing is the work of turning raw on-chain activity, blocks, transactions, events, and contract state, into structured data an application can query in milliseconds. A node can return the current value of a variable, but it cannot answer "every trade this wallet made last month" or "the top 20 pools by volume today" without replaying years of history block by block, which no frontend can do at request time.
An indexer closes that gap: it reads the chain as it is produced, transforms each event into the shape your product needs, and serves it over a fast API. Protofire has built subgraphs with The Graph since 2019 and operated an indexer on The Graph Network from its December 2020 mainnet launch; on The Graph's original Ethereum network it ranked third of 638 indexers by cumulative indexing rewards (December 2020 to January 2024).
We also maintain the open-source subgraph-toolkit, and our public subgraphs cover major protocols, including a Lens Protocol subgraph.
The default tool is a subgraph on The Graph, and for most dapps it is the right one. But indexing is not a single product. Real-time trading data, cross-chain aggregation, heavy analytical queries, and very high-throughput chains often call for Substreams, a Ponder or Subsquid indexer, or a purpose-built indexer in Rust or TypeScript.
We work across all of them, and because we run indexers in production rather than only writing them, we pick the approach that still holds up when your data grows, not the one that is quickest to demo.
Indexing is a pipeline, not a single query
We build and operate each stage, from raw chain data to the API your app reads.
Source
Transform
Store
Serve
Operate
What is blockchain data indexing?
A blockchain node is built to reach consensus, not to answer product questions. It can give you the state of a contract right now, but historical and aggregated queries, a wallet's full trade history, volume per pool, holders over time, would mean scanning every block since the contract was deployed.
That is far too slow to run when a user loads a page, and public RPC endpoints rate-limit exactly this kind of request. Indexing moves that work off the critical path: the data is computed once as the chain advances and stored ready to read.
An indexer subscribes to the chain, decodes the raw logs and calls emitted by your contracts, and maps them into entities with the relationships your application cares about, positions, markets, users, transfers. The result is a schema your team queries with a single request instead of stitching together hundreds of RPC calls.
Getting that mapping right, and versioning it as the contracts evolve, is most of the work, and it is where an indexer built by people who have shipped many of them pays off.
The difficulty in indexing is staying correct as the chain changes underneath you. Chains reorganize, so an indexer has to unwind and reapply blocks without serving wrong data in between. Contracts get upgraded, new events appear, and the schema has to migrate without downtime. High-volume chains push indexing latency until the API falls behind the head of the chain.
We design for these cases up front, with reorg handling, backfill strategy, and monitoring, so the data your product shows matches the chain.
The Graph, Substreams, Ponder, or a custom indexer?
For most dapps, a subgraph on The Graph is the right default: it is well understood, decentralized, and quick to ship, and the ecosystem tooling is mature. We have built subgraphs since 2019, ran a top-3 Graph indexer by indexing rewards from 2020 to 2024, and maintain subgraph-toolkit, the open-source helper library many teams use to write cleaner subgraph mappings, so this is our deepest capability. If a subgraph fits, we build it, deploy it, and keep it healthy, and we do not push you toward something more complex than you need.
Subgraphs have limits. Latency-sensitive products such as order books and perps need data closer to real time than a subgraph comfortably provides. Analytical queries with heavy joins and aggregations are awkward in GraphQL and slow at scale. Very high-throughput chains can outrun subgraph indexing speed.
When you hit one of these walls, the answer is a different engine: Substreams and Firehose for parallelized, high-speed extraction, or a Ponder or Subsquid indexer that gives you a SQL database and full control over the API.
Some products need an indexer that no off-the-shelf framework provides: a bespoke pipeline in Rust or TypeScript, a single API that aggregates the same data across several chains, or a store shaped for a specific query pattern. We have built these in production, including Ponder-based indexers for on-chain auctions and custom indexers for emerging chains, and we operate them alongside the node and RPC infrastructure they read from.
When the requirement is cross-chain, the indexing layer and the cross-chain messaging layer are designed together.
What do we deliver?
Production subgraphs on The Graph: schema design, mapping logic, deployment to the decentralized network or a hosted setup, and ongoing maintenance as your contracts change. For the full detail on our Graph-specific work, see subgraph development.
When a subgraph is not enough, we build the indexer that is: Substreams, Ponder, Subsquid, or a purpose-built pipeline, with the store and API shaped for your queries. You get a data layer that keeps up with volume and gives your engineers the query surface they actually need.
The indexed data has to reach people and systems. We expose GraphQL or REST APIs for your frontend and backend, and build the analytics and dashboards that turn on-chain activity into metrics a team can act on, including TVL and volume feeds of the kind that power public analytics.
Who is blockchain data indexing for?
New L1 and L2 networks need an indexing layer before applications can be built on them, the same way they need oracles and explorers; we deploy it so builders arrive to a chain where querying on-chain data already works. DeFi and app teams come to us when their subgraph cannot keep up, when a feature needs real-time or cross-chain data, or when they would rather have the data layer built and operated by a team that has done it many times than pull their own engineers onto it. Protocols with analytics and reporting needs use us to turn raw activity into the dashboards, feeds, and APIs their product, their users, and their internal teams depend on. If your engineers can write a subgraph but you want the schema design, scaling, and operations done right the first time, that gap is what we close.
Subgraphs since 2019 and a top-3 Graph indexer, 2020 to 2024
Protofire is a blockchain development company with 250+ shipped projects across 60+ networks and 95+ protocols. On data specifically, we have built subgraphs since 2019, operated a Graph Network indexer from the December 2020 mainnet launch (third of 638 by cumulative indexing rewards on the original Ethereum network, December 2020 to January 2024), maintain the open-source subgraph-toolkit used across the ecosystem, and build custom indexers in Rust and TypeScript for teams that have outgrown subgraphs.
Our broader credentials: we maintain Solhint, the Solidity linter used by 1M+ developers; we deployed Safe on 120+ EVM networks, where it secures $2B+; and we run the node and RPC infrastructure that indexers read from, so the whole data path is under one roof. When we recommend an indexing architecture, it is one we know how to operate, because we already run it.
“A node can only report the current state. An indexer answers questions about the full history, every trade a wallet made, volume per pool, holders over time, which is why almost every dapp interface runs on one.”
The Protofire repositories behind this page
subgraph-toolkit
Utilities and helpers for subgraph development
lens-protocol-subgraph
A subgraph for Lens Protocol
FAQ
What is blockchain data indexing?
Do I need a subgraph or a custom indexer?
When do subgraphs stop being enough?
Can you index data across multiple chains?
Have you run an indexer on The Graph?
How does indexed data reach my app?
Get a proposal
Tell us what you are building. An engineer reads it, we have a short call, and the written proposal follows within one business day.
Budget
An NDA is available from the first message and can cover anything you share. How it works