When we first introduced The Graph in July of last year, we shared our vision of building a decentralized indexing protocol for Web3. The team has been hard at work and today I’m excited to share the design of the first version of The Graph's decentralized network in detail. The Graph Network is core infrastructure for Web3—a necessary component for delivering decentralized applications with consumer-grade performance.

For this post, I assume some prior familiarity with The Graph. If you’ve never heard of The Graph, a great place to start is our announcement post, our docs, or several great posts from our community.

This is the first part of a two part post exploring the design of The Graph Network. You can jump to part two here.

Full-Stack Decentralization

The mission of The Graph is to enable internet applications that are entirely powered by public infrastructure.

Full-stack decentralization will enable applications that are resistant to business failures and rent seeking and also facilitate an unprecedented level of interoperability. Users and developers will be able to know that software they invest time and money into can’t suddenly disappear.

To reach this vision of fully decentralized applications (dApps), it’s critical that we shift from a paradigm of businesses paying for the ongoing storage, compute, and other services required to keep an application running, toward users directly paying networks of decentralized service providers for granular usage of these resources.

Today, most “decentralized” applications only adopt such a model in the bottom layer of the stack—the blockchain—where users pay for transactions that modify application state. The rest of the stack continues to be operated by centralized businesses and is subject to arbitrary failures and rent seeking.

What is The Graph Network

The Graph Network decentralizes the query and API layer of Web3, removing a tradeoff dApp developers struggle with today: whether to build an application that is performant or to build an app that is truly decentralized.

Today, developers can run a Graph Node on their own infrastructure, or they can build on our hosted service. Developers build and deploy subgraphs, which describe how to ingest and index data from Web3 data sources. Many leading Ethereum projects have already built subgraphs including: Uniswap, ENS, DAOstack, Synthetix, Moloch, and more. In The Graph Network, any Indexer will be able to stake Graph Tokens (GRT) to participate in the network and earn fees as well as inflation rewards for serving queries.

Consumers will be able to use this growing set of Indexers by paying for their metered usage, proving a model where the laws of supply and demand sustain the services provided by the protocol.

Protocol Roles

These are the roles that interact with the system, the behaviors they must engage in for the protocol to function correctly, and what incentives motivate them.


  • Consumers. Consumers pay Indexers for queries. These will typically be end users but could also be web services or middleware that integrate with The Graph.

  • Indexers. Indexers are the node operators of The Graph. They are motivated by earning financial rewards.

  • Curators. Curators use GRT to signal what subgraphs are valuable to index. These will typically be developers but they could also be end users supporting a service they rely upon or a persona that is purely financially motivated.

  • Delegators. Delegators put GRT at stake on behalf of an Indexer in order to earn a portion of inflation rewards and fees, without having to personally run a Graph Node. They are financially motivated.

  • Fishermen. Fishermen secure the network by checking if query responses are accurate. Fishermen are altruistically motivated, and for that reason, The Graph will initially operate a fisherman service for the network.

  • Arbitrators. Arbitrators determine whether Indexers should be slashed or not during dispute resolution. They may be financially or altruistically motivated.



For developers, the APIs for building a subgraph will remain largely the same as it is using a local or hosted Graph Node.

One notable difference is in how developers deploy subgraphs. Rather than deploying to a local or hosted Graph Node, they will deploy their subgraph to a registry hosted on Ethereum and deposit a stake of GRT to curate that subgraph. This serves as a signal to Indexers that this subgraph should be indexed.

End Users

For end users, the major difference is that rather than interacting with centralized APIs that are subsidized, they will need to begin paying to query a decentralized network of Indexers. This will be done via a query engine running on their machine—either in the browser, as an extension, or embedded in the dApp.

The query engine allows the user to safely query the vast amounts of data stored on The Graph without having to personally do the work to compute and store that data. The query engine also acts as a trading engine, making decisions such as which Indexers to do business with or how much to pay, based on the dApp being used or the user’s preferences.

For the query engine to provide a good user experience, it will need to automatically sign micropayment transactions on behalf of users rather than prompting them for every transaction that needs signing. We’re working with several state channel teams building on Ethereum to make sure that the wallets and functionality they ship meets the needs of metered usage protocols like The Graph. In the meantime, we will host a gateway that allows dApps to subsidize queries on behalf of users.


Indexers will be able to join The Graph by staking GRT and running a version of Graph Node.

They will also want to run an indexer agent that programmatically monitors their resource usage, sets prices, and decides which subgraphs to index. The indexer agent will be pluggable, and we expect that node operators will experiment with their own pricing models and strategies to gain a competitive edge in the marketplace over other Indexers.

Curators and Delegators

Curators and delegators will curate and delegate via Graph Explorer. When we launch the network, Graph Explorer will be a fully decentralized application, and using it will require a dApp-enabled browser with an Ethereum wallet.



The Graph Network includes smart contracts that run on Ethereum combined with a variety of additional services and clients that operate off-chain.

Query Market

The query market serves a similar purpose to an API in a traditional cloud-based application—efficiently serving data required by a front end running on a user’s device. The key difference is that whereas a traditional API is operated by a single economic entity that users have no say over, the query market comprises a decentralized network of Indexers, all competing to provide the best service at the best price.

query market

This redundancy means that even if a single Indexer goes offline, as long as there exists demand for querying a dataset, other Indexers will be incentivized to absorb the additional work.

Transactions in the query market are priced based on the bandwidth and compute required to process the query.

Let’s take a look at what a typical flow might look like for a consumer interacting with the query market.

  • Service Discovery. The consumer asks The Graph which Indexers have the data they are interested in.

service discovery

  • Indexer Selection. The consumer selects an Indexer to transact with based on which they deem most likely to provide the highest quality service at the best price.

indexer selection1 discovery

indexer selection2 discovery

  • Query + Conditional Micropayment. The consumer sends the Indexer a query along with a conditional micropayment that specifies how much they are willing to pay for compute and bandwidth.

conditional micropayment discovery

  • Response + Attestation. If the Indexer accepts the price offered by the consumer, then they process the query and respond with the resulting data, as well as an attestation that this response is correct. Providing this attestation unlocks the conditional micropayment.

The attestation is produced deterministically and is uniquely attributable to the Indexer for the purposes of verification and dispute resolution elsewhere in the protocol.

conditional micropayment discovery

A single decentralized application querying The Graph may use multiple subgraphs indexed by different Indexers and in that case would go through the above flow for each subgraph being queried.

Graph Tokens

To support the functioning of the query market, the protocol introduces a native token: Graph Tokens (GRT).

Graph Tokens have two primary uses in the protocol:

  • Indexer Staking. Indexers deposit Graph Tokens to be discoverable in the query market and to provide economic security for the work they are performing.
  • Curator Signaling. Curators deposit Graph Tokens in a curation market, where they are rewarded for correctly predicting which subgraphs will be valuable to the network.

Consumers will be able to pay for queries in ETH or DAI. Payments will be settled, however, in GRT to ensure a common unit of account across the protocol.

In addition to the uses outlined above, having a native token allows us to incentivize certain behaviors through inflation. The ability to have a dynamically adjusted inflationary monetary policy is a powerful tool in the toolbelt.

Continue Reading

At this point we’ve walked through many of the core concepts in The Graph. There are, however, additional mechanisms needed to support an efficient query market, a performant protocol, and an elegant experience for developers.

In part two we’ll be continuing with an exploration of these components, including the various uses of Graph Tokens, such as indexer staking, curation markets, and inflation rewards.

We’ll also be covering our micropayments infrastructure, how we verify query responses, and how end users will interact with The Graph via a decentralized Graph Explorer.

See you there!