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.
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 and operated that layer since 2019, as a top-3 indexer in The Graph ecosystem and the maintainer of the open-source subgraph-toolkit.
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 are a top-3 indexer in The Graph 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.
A top-3 The Graph indexer since 2019
Protofire is a blockchain development company with 250+ shipped projects across 60+ networks and 95+ protocols. On data specifically, we have run indexing infrastructure since 2019 as a top-3 indexer in The Graph ecosystem, we maintain the open-source subgraph-toolkit used across the ecosystem, and we 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 are an official Safe Guardian, and Protofire-deployed networks secure $2B+ in TVL across 120+ EVM networks; 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.”
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?
Are you an indexer on The Graph?
How does indexed data reach my app?
Reviewed by Luis Medeiros, Field CTO at Protofire. Last reviewed: July 2026.