Skip to content

Subgraph Development & Blockchain Indexing

In short

Blockchain data indexing from a top-3 indexer in The Graph ecosystem: subgraph design, deployment, and operational maintenance for 40,000+ dApps.

92%
faster queries (4.2s to 0.3s)
65%
lower indexing cost
40,000+
dApps powered
$4.7B
DeFi tx per quarter
Trusted by teams building on-chain

Subgraph development is how a team turns raw, chronological on-chain data into a fast, queryable API. A subgraph indexes the events a smart contract emits and serves them over GraphQL, so a dApp can read exactly the data it needs in milliseconds instead of scanning the chain block by block. Blockchain data indexing is the unglamorous layer underneath almost every usable Web3 product, and when it is slow or missing, developers feel it immediately.

Protofire builds and operates that layer in production. We are a long-time contributor to The Graph and a top-3 indexer in its ecosystem, we design subgraph schemas, write and test the mappings, deploy them, and keep them in sync as contracts evolve, across more than a dozen networks. This is not a tutorial repo or a hosted endpoint you rent; it is engineered, maintained indexing infrastructure built by a team that runs it at scale every day.

We work with EVM L1/L2 chains, ecosystem foundations, DeFi protocols, and analytics teams that need reliable indexed data as a primitive, without pulling their core engineers off chain or protocol priorities. If your developers are blocked by missing data, fighting slow queries, or maintaining brittle indexing scripts, that is exactly the problem we solve.

A subgraph is a three-part system we run at scale

Manifest, mappings, and schema, deployed and kept in sync as an operated service.

01

Manifest

Declares which contracts and events to index, and from which start block.
02

Mappings (AssemblyScript)

Transform raw on-chain events into structured, queryable entities.
03

GraphQL schema

Defines the shape developers query against, with filtering, pagination, and search.
04

Indexer & sync

Ingests the chain and keeps the subgraph current with every new block.
05

Custom indexing clusters

Kubernetes, Terraform, and CI/CD across 15+ networks for high-throughput workloads.
06

Monitoring & maintenance

Versioned mappings, error logging, and updates as ABIs evolve.

Customers

Astar Network, Kakarot Network, SuperRare

Node:

DevOps

01

What is a subgraph?

A subgraph is an open API that indexes a defined slice of blockchain data and exposes it over GraphQL. Smart contracts emit events as transactions are processed, but that data is stored chronologically and is expensive to read directly from an RPC node. A subgraph closes that gap with three parts: a manifest that declares which contracts and events to watch and from which start block; mappings (written in AssemblyScript) that transform those raw events into structured entities; and a GraphQL schema that defines the shape developers query against. Once deployed, an indexer ingests the chain, keeps the subgraph in sync with every new block, and answers low-latency queries, filtering, pagination, full-text search, and aggregations, that would be impractical to build against raw RPC. The Graph is the decentralized protocol that standardized this pattern, and subgraphs are now the default data layer for dApps in DeFi, NFTs, DAOs, and infrastructure.

02

How do you build and host a subgraph?

We take a subgraph from requirements to a maintained production endpoint. We start by working with your developers to define the events and entities that matter, the product-critical queries a frontend, backend, or analytics dashboard actually needs, then design an optimal entity model and GraphQL schema around them. From there we write the mappings, test them against real on-chain history, and deploy the subgraph to The Graph's decentralized network or to dedicated indexing infrastructure we operate. Because contracts change, the work does not end at launch: we version and update mappings as ABIs evolve, fix malfunctioning subgraphs, retire deprecated ones, and monitor for indexing errors so your data layer keeps pace with the protocol. We also publish open-source utilities, like the Subgraph Toolkit, that make bootstrapping and customizing new subgraphs faster for your own engineers.

03

How do you tune custom indexing and query performance?

Standard subgraphs cover most needs, but high-throughput dApps and chains often need more than a stock deployment. As an indexer operating at scale, we engineer the infrastructure underneath: scalable clusters built with Kubernetes, Terraform, and CI/CD workflows that run subgraph indexing and querying across 15+ networks and process 18M+ queries per day. That operational depth is where blockchain indexing becomes a performance discipline rather than a one-time deploy, tuning ingestion for chains with heavy event volume, optimizing schemas and queries so real-time dApps stay responsive, and adding monitoring and error logging so issues surface before users do. When a stock subgraph is not enough, we design custom indexing pipelines around the specific access patterns of your application, so the read path matches how your product actually queries data.

04

Who is subgraph development for?

This is for teams that treat indexed on-chain data as infrastructure, not an afterthought.

  • EVM L1/L2 chains and ecosystem foundations:
    • offer maintained subgraphs and indexing as a primitive, closing the developer-experience gap against competitor chains without diverting their core team.
  • DeFi protocols and dApp teams:
    • need fast, queryable data to power search, filtering, pagination, and analytics that raw RPC cannot deliver.
  • Analytics and data teams:
    • need reliable, queryable historical data behind their dashboards and products.

Common signals that it is time: developers blocked by missing indexed data, a recent mainnet launch or developer-growth push, brittle in-house indexing scripts that keep breaking, or query performance and reliability that are no longer good enough for the experience you want to ship.

05

Inside our work across The Graph ecosystem

Accessing blockchain data is a recurring bottleneck: chronological storage makes application-specific data hard to extract, custom indexing systems are resource-intensive to run, and traditional querying struggles at high throughput. Protofire partnered with The Graph to attack all three. We built custom subgraphs for leading protocols like Maker, Curve, and Synthetix; deployed scalable indexing clusters on Kubernetes, Terraform, and CI/CD across multiple networks; and shipped open-source tooling so other developers could move faster. The outcome is measured, not promised: average query response times dropped 92%, from 4.2 seconds to 0.3 seconds; indexing costs fell 65%; and subgraph go-to-market accelerated from 6-8 weeks to under 10 days, a more than 80% reduction. Today the subgraphs we maintain power 40,000+ dApps and $4.7B in DeFi transactions per quarter and make Protofire a top-3 indexer in The Graph ecosystem. (Read the full case study.)

06

A top-3 indexer in The Graph ecosystem since 2019

Protofire is a blockchain development and infrastructure company that has shipped 250+ projects since 2016, across 60+ networks and 95+ protocols. We have been an active contributor to The Graph since 2019, building subgraphs for leading DeFi protocols, operating one of the larger indexer footprints in the network, and releasing open-source tools like the Subgraph Toolkit back to the community. Our broader credentials back the indexing work: we maintain Solhint, the open-source Solidity linter used by 1M+ developers; we are an official Safe Guardian behind deployments across 120+ EVM networks securing $2B+ in assets; and we run production node and indexing infrastructure for chains and foundations. When we recommend an indexing architecture, it is one we already run at scale, not a pattern we read about.

“We design and ship indexed data as production infrastructure, not a tutorial repo or a rented endpoint.”

Indexing, at network scale
92%faster queries (4.2s to 0.3s)

We built subgraphs for leading protocols like Maker, Curve, and Synthetix and deployed indexing clusters on Kubernetes and Terraform. Query times fell 92%, indexing costs 65%, and subgraph go-to-market dropped from 6-8 weeks to under 10 days.

The Graph ecosystemView project →

Success Stories & Media

Protofire x The Graph Partnership
Empowering Astar Network with The Graph Infrastructure

FAQ

What is a subgraph?
A subgraph is an open API that indexes a specific slice of blockchain data and serves it over GraphQL. It is built from three parts: a manifest that declares which smart contracts and events to watch and from which start block, mapping code written in AssemblyScript that transforms raw events into structured entities, and a GraphQL schema that defines the shape developers query against. Once deployed, an indexer ingests the chain, keeps the subgraph in sync with every new block, and answers low-latency queries, so a dApp fetches exactly the data it needs in milliseconds instead of scanning the chain block by block through an RPC node. Subgraphs are the default data layer for dApps built on The Graph across DeFi, NFTs, DAOs, and infrastructure, powering features like search, filtering, pagination, full-text search, aggregations, and analytics dashboards.
What's the difference between The Graph and a custom indexer?
The Graph is a decentralized protocol and network for publishing and querying subgraphs, a standardized, shared way to index on-chain data that most dApps use. A custom indexer is purpose-built indexing infrastructure tuned to one application's access patterns, used when a standard subgraph cannot meet the throughput, latency, or data-shape requirements. High-throughput dApps and chains with heavy event volume often need this: scalable clusters built with Kubernetes, Terraform, and CI/CD, tuned ingestion, and schemas optimized for the way the product actually reads data. Most teams should start with a subgraph on The Graph; we build custom indexing only when the workload genuinely needs it. Because we operate both, as a top-3 indexer in The Graph ecosystem and as a team that runs its own indexing clusters across 15+ networks, we can recommend the right one honestly instead of defaulting to whatever we happen to sell.
Do we still need a subgraph if our frontend queries the chain directly from RPC?
Direct RPC works for simple, single-record reads, but it does not replace a maintainable indexed-data layer. As soon as you need filtering, pagination, full-text search, aggregations, or historical queries, the things that make a real product UX, querying raw RPC becomes slow, brittle, and expensive, because on-chain data is stored chronologically and is costly to read directly from a node. A subgraph closes that gap with a fast, structured GraphQL API for exactly those access patterns, kept in sync with every new block by an indexer. Developer experience usually degrades immediately when that indexing layer is missing or slow, which is why indexed data is best treated as infrastructure rather than an afterthought. You can keep RPC for trivial reads and use a subgraph for everything your product actually queries at scale.
How long does it take to build a subgraph?
It depends on the contracts and the queries you need, but our infrastructure work has cut typical subgraph go-to-market from 6-8 weeks to under 10 days, a more than 80% reduction, once contracts and ABIs are available and the product-critical events are identified. We start by working with your developers to define the events and entities that matter, design an optimal entity model and GraphQL schema, write the mappings, then test them against real on-chain history before deploying. Because contracts change, the work continues after launch: we version and update mappings as ABIs evolve, fix malfunctioning subgraphs, and monitor for indexing errors. We confirm the exact timeline after scoping which events and entities your application actually queries, and whether a stock subgraph or a custom indexing pipeline is the right fit.
Which chains and networks do you support?
EVM-compatible chains are our core. We operate subgraph indexing and querying across 15+ networks and process 18M+ queries per day on scalable clusters built with Kubernetes, Terraform, and CI/CD. We have delivered subgraph and indexing work for chains and ecosystems including Astar Network and Kakarot Network, and built custom subgraphs for leading protocols like Maker, Curve, and Synthetix. If your network is EVM-compatible and has reliable RPC, we can usually index it; non-EVM chains depend on whether a supported indexing path exists. For chains launching or scaling, we also tune ingestion for heavy event volume and add monitoring and error logging so issues surface before users feel them. As a top-3 indexer in The Graph ecosystem, we scope the supported path and the right indexing approach for your specific network during a short discovery call.
We're a chain or foundation, can you run subgraph indexing as an ecosystem primitive?
Yes, this is a primary use case. We deliver maintained subgraphs and indexing infrastructure as a managed primitive for chains and foundations, so your builders get reliable, queryable data and you close the developer-experience gap against competitor chains, without diverting your core team from protocol priorities. We define a subgraph roadmap, deploy and maintain the indexing layer across 15+ networks, and provide open-source developer tooling, like the Subgraph Toolkit, plus tutorials so your ecosystem can build on it. Because we run this at scale as a top-3 indexer in The Graph ecosystem, the architecture we recommend is one we already operate every day, not a pattern we read about. We also tune ingestion for heavy event volume and add monitoring so indexing errors surface before they reach your developers.

Reviewed by Luis Medeiros, Field CTO at Protofire. Last reviewed: June 2026.

Book a call with Arsenii Petrovich

Schedule a call with our CTO to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved