What is The Graph Network?

The Graph is a decentralized indexing protocol for Web3 applications. It indexes data from blockchain networks such as Ethereum, Polkadot, Fantom and Solana to make their data easily accessible.

An Introduction to The Graph Network.

Let’s start with a quick explanation of what The Graph Network is:

Yaniv Tal
Yaniv Tal

Edge & Node

“The Graph is an indexing protocol for organizing blockchain data and making it easily accessible with GraphQL.”

The novel idea behind The Graph Network is to decentralize the query and API layer of the internet application stack. Doing so will enable decentralized applications to query complex data from the blockchain without having to develop and operate proprietary indexing servers on a centralized service provider.

A Decentralized Indexing Protocol for Web3.

Since its inception in 2018, The Graph Protocol has become core infrastructure for Web3 and enables developers to deliver decentralized applications (dApps) with consumer-grade performance.

Without The Graph, projects like Uniswap, Bancor and Aave would have to run their own proprietary indexing servers, which requires significant engineering and hardware resources. Thanks to The Graph Network, it is now possible to query blockchain networks such as Ethereum without proprietary indexing servers.

The Dangers of Centralization.

The present structure of the Internet favors centralization. Its client-server architecture bestows unprecedented power to the organizations running the servers that power the internet as we know it. With this power, these organizations can define the rules, control the data and grant/revoke access to their services at their own discretion.

Information asymmetries and power imbalances.

The natural result of a centralized server architecture is that users are unaware how their data is used and whom it is given access to. Not allowing users to have a say in how the data is used creates information asymmetries and can cause power imbalances.

Centralized organizations have created tightly interwoven structures on the Internet and do not give the majority of individuals the ability to impact how things function.

Yaniv Tal
Yaniv Tal

Edge & Node

“People become passive observers in a world they cannot change and do not have a stake in. Monopolies make it harder for individuals to contribute their talents. People are given all or nothing deals, competition is stifled, and freedom of choice disappears.”

Full-stack decentralization.

The vision of The Graph Network is to enable applications that are fully powered by public infrastructure. Such a full-stack decentralization will foster community-owned organizations that are resilient to the failure of individual businesses. With a never-before seen level of interoperability, decentralized applications will be robust to rent-seeking and will reassure developers and users that an organization, product or software they invest time in does not simply cease operations.

Even though we have seen a rise in decentralized applications (dApps), most are only decentralized in the bottom layer of the stack (i.e. the blockchain). These dApps are still being operated by centralized organizations or businesses and are therefore at risk of rent seeking or business failures.

For The Graph’s vision to come to fruition, there needs to be a shift – away from business financing the development and maintenance of applications towards a world in which users are paying decentralized networks directly for granular access to these resources.

Yaniv Tal
Yaniv Tal

Edge & Node, Partner

“The sudden rise of cryptocurrencies and associated protocols has created a unique opportunity that we can harness to shift the balance of power away from monopolies and towards the sovereignty of individuals.”

Protocol Roles.

Depending on the technical know-how, risk confidence and desired activity level, participants of The Graph Ecosystem can choose from a variety of different user roles. In the following, we’ll have a look at the different roles participating in The Graph Network, their incentives and how each role helps the protocol to function correctly and safely.

Protocol Roles in Detail.

The Graph enables end users to query data from the blockchain. Such end users can be dApps (for example Uniswap, Bancor and Aave) but also web services, developers or middleware. Data Consumers pay Indexers based on their query volume.

Key difference to a centralized architecture: Instead of interacting with centralized APIs, Data Consumers query a decentralized network of node operators (Indexers).

This process is facilitated by a query engine that is running in the background of a data consumer’s machine – either within their browser or embedded in the dApp. The engine enables consumers to query large amounts of data without computing and storing the data. It also functions as a trading engine making decisions based on data consumer’s preferences about which Indexer to query from and how much to pay per query. Another function of the query engine is to automatically sign micropayment transactions on behalf of Data Consumers. Doing so will help users to avoid having to manually sign every transaction.

Subgraph developers define, which blockchain data is being stored in The Graph Node and the events that trigger this process. After having finished the development of a subgraph, developers then deploy the subgraph to a registry hosted on Ethereum. Developers can optionally choose to become Curators as well to signal their own subgraph to Indexers.

Key difference to a centralized architecture: Subgraphs are not deployed to a local or hosted Graph Node but instead are being deployed to the registry hosted on Ethereum.

To learn more about developing subgraphs, visit our Developer Knowledge Hub.

Comparable to Validators in other networks, Indexers operate notes in The Graph Network and are responsible for indexing data from decentralized APIs (so called “subgraphs”). Indexers are incentivized by earning query fees from Data Consumers and indexing rewards from the protocol.

To participate in the network, Indexers have to stake at least 100,000 GRT, which are subject to slashing in case of malicious behaviors. Secondly, Indexers will have to run a version of The Graph Node. With the aid of an Indexer agent, Indexers can programmatically monitor their resource usage, define prices and chose which subgraphs to index. To gain competitive edges in the market, Indexers can define their own pricing strategies. Learn more: Indexer Knowledge Hub.

To help Indexers identify high-quality subgraphs, Curators are incentivized to find attractive subgraphs and signal on them. The process of curating on The Graph Network is facilitated by a Bancor bonding curve. In order to signal on a subgraph, Curators mint curation shares of the subgraph by depositing GRT tokens into the curve and burn shares by withdrawing tokens. The incentive for Curators is to signal on attractive subgraphs early on. Doing so will allow them to earn a portion of the query fees a subgraph generates. At the same time, however, Curators are confronted with the risk of misjudging the attractiveness of a subgraph, which could leave them with earning only few query fees or none at all. Another risk is that the curation shares a Curator has minted loose substantially in value if the subgraph’s curation shares are burned by other Curators. Learn to become a successful Curator on The Graph Network: Curator Knowledge Hub.

Being a Delegator is an excellent role for investors of The Graph who wish to stake their GRT to passively earn a share of the indexing rewards and query fees that an Indexer generates. To do so, Delegators delegate their stake towards carefully selected Indexers of their choice. Being a Delegator is the ideal choice for all those who wish to participate in the Graph Network without having to run their own node. Delegators are confronted with less risks than other participants and do not need sophisticated technical skills.

If you’re interested in becoming a Delegator, be sure to have a look at our Delegator Knowledge Hub, which is packed with all the information you need to thrive as a Delegator.

Fishermen validate very responses and are thereby responsible for securing the network. Arbitrators resolve disputes and determine if an Indexer is acting maliciously.

Architecture of The Graph Network

The Graph Network is a network of nodes that index data from multiple blockchains and serve that data through GraphQL compliant HTTP endpoints. The network tokenomics are settled using the Ethereum network, so all protocol related smart contracts that function to settle payments, stake, etc. live in the Ethereum network. As a side note, micropayments (query payments mostly) are settled through state channels. In short, the network consists of Ethereum powered smart contracts in combination with off-chain operated services and clients.

The Graph Network consists of several components as can be seen below:

Graph Tokens.

The native utility token of The Graph Network is called Graph Token (GRT). The token has been introduced by The Graph to ensure the proper functioning of the query market within the network.

The two primary functions of Graph Tokens are vital to the proper functioning of the protocol:

  • Indexer Staking: Indexers in The Graph Network need to deposit at least 100k GRT as an economic security. Their deposit is subject to slashing in case of malicious behavior. The deposited Graph Tokens allow Indexers to be discoverable in the query market.
  • Curator Signaling: The Graph’s Curation Market is powerd by Graph Tokens. Curators deposit GRT into a Bancor Bonding Curve to mint curation shares of a subgraph. As a reward for correctly predicting high-quality subgraphs, Curators receive a portion of the subgraph’s generated query fees.

Other functionalities of Graph Tokens include:

  • Settlement of Payments: Data Consumers of The Graph are encouraged deposit either Ethereum or their prefered stable coin into their wallet. To ensure a common arithmetic unit across the protocol, query payments are settled in GRT. The same holds true for Delegators and Curators who will have to pay a delegation tax or curation tax in GRT whenever they interact with the respective contracts.
  • Delegator Staking: Delegators help to secure The Graph Network by delegating their stake to the Indexers of their choise. As a reward, they receive a percentage of the query fees and indexing rewards an Indexer earns.
  • Incentive Mechanism: Graph Tokens can also be used to provide incentives for certain desired behaviors of market participants, for example issuing new tokens to incentivize indexing of new subgraphs.

Query Market.

The pricing of query transactions in the query market is calculated based on the required bandwidth and compute to process the queries. The typical interaction of a data consumer with the query market looks as follows:

  • Service Discovery: Data Consumers explore The Graph Network to identify Indexers that provide the required data.
  • Indexer Selection: Based on a number of different factors, Data Consumers select an Indexer to query the data from. Selection criteria can include: the Indexer’s pricing strategy, performance, data freshness, perceived reputation and economic securities provided.

Indexers can utilize different pricing strategies to gain an edge in the query market and to attract Data Consumers. To express their prices, Indexers use a cost model detailing the costs for querying the provided data and the prices for additional variables such as database statistics or query features. From this follows that pricing is not set at the network level like it is the case on Ethereum for example but is instead negotiated between Data Consumers and Indexers.

In times of high query demand, Indexers can indicate with a flag that queries are throttled.

Typical Flow of Query and Payment

To gain a better understanding of the underlying process of the query market, we’ll have a look at how queries and payments are executed:

  • Query + Conditional Micropayment: If a Data Consumer is interested in an Indexer’s data, they will send a query in combination with a conditional micropayment detailing the consumer’s asking price for bandwidth and compute. The consumer’s query specifies in detail, which subgraph they want to query, which data they want to receive and as of what block they need the data from.
  • Response + Attestation: If the Data Consumer’s asking price conforms with the Indexer’s selling rate, the query will be processed. The consumer will receive the resulting data, which comes with an attestation of data correctness. In turn, the Indexer will receive the conditional micropayment by providing the attestation. For the purpose of resolving disputes in the protocol and to provide a purpose of verification, the deterministically-produced attestation is uniquely attributable to the Indexer.

Data Consumers such as dApps can query multiple subgraphs from different Indexers but the process explained above would always be the same for each subgraph queried.

Indexer Staking.

Indexers in The Graph Network have to stake at least 100k GRT in order to participate in the protocol and sell their services in the query market. As such, The Graph has adopted a work token model to enable this process. The two primary functions of the work token are as follows:

  • Economic security: An Indexers staked GRT is subject to slashing should an Indexer perform their indexing work maliciously. Secondly, the staked GRT can only be withdrawn after a 28-day thawing period, during which the tokens are locked and cannot be transferred. The thawing period provides a timeframe during which disputes can be resolved.
  • Sybil resistance mechanism: The high entry barrier of 100k GRT ensures that Indexers are highly committed to their work and it also prevents low-quality Indexers without the necessary dedication from entering the protocol.

Indexers have an incentive to stake an amount of GRT that is in rough proportion to the indexing work they seek to do within the network. Doing so ensures that the above-mentioned protection mechanisms work correctly.

The Graph’s rebate pool serves as an incentive for Indexers to stake GRT in the network. The rebate pool is created by collecting a protocol-wide fee on every transaction within the network. The resulting fees are then rebated to network participants in relation to their proportional stake and the work they have performed for the network (e.g., proportional fees collected). This is accomplished by using the Cobb-Douglas Production Function.

Here is the formula to calculate the share that an Indexer i receives of the rebate pool Yi during a given time period:


ωij allocated stake of an Indexer towards a specific subgraph j

Ω total amount staked in The Graph Network

θij generated query fees by Indexer i for the rebate pool

j and Θ total query fees collected within the protocol


Delegators in The Graph Network contribute to securing the network by delegating (i.e., staking) their tokens to an Indexer so that the Indexer can put the delegated GRT to productive use. It is the ideal role for all those that wish to hold their tokens and earn a portion of the generated indexing rewards and query fees.

To become a Delegator, token holders “loan” their GRT tokens to the Indexer(s) of their choice. In turn, Delegators will receive a portion of the generated query fees and the indexing rewards an Indexer receives. Aside from fostering token participation in the network, delegation provides an opportunity for individuals who lack the required technical background to operate an indexing node on their own. Similarly, smaller Indexers who provide high-quality indexing services may be able to attract delegations to become more competitive in the network and earn a higher amount of query fees and indexing rewards.

An important distinction to other staking protocols is that The Graph does not subject the delegated stake of a Delegator to slashing should the Indexer behave maliciously. Another noteworthy difference is that delegation rewards will be automatically compounded to the ongoing delegation of a Delegator. Similar to other networks, however, The Graph enforces a limit

However, The Graph is – similarly to other protocols – enforcing a limit on the delegations an Indexer is allowed to accept. This limit is based on the stake of an Indexer. Limiting the delegation capacity of an Indexer to their own stake ensures that Indexers stake their own funds in order to provide their services to the network.


In order to query a subgraph, data consumers rely on Indexers that index a subgraph. Due to the number of available subgraphs, Indexers need help in identifying quality subgraphs that are potentially promising high query fees. To accomplish this, Curators deposit GRT into the bonding curve of a subgraph to indicate to Indexers which subgraphs are of a high quality. Doing so helps Indexers to understand which subgraphs should be indexed.

By depositing GRT, Curators mint curation shares of the respective subgraph. These shares entitle Curators to a portion of the future query fees collected on the subgraph.

The bonding curve acts as an algorithmic market maker meaning that the minting of curation shares causes an increase in the exchange rate between GRT and curation shares.

Indexer Reward.

New subgraphs may initially have no significant query volume and could therefore struggle to attract Indexers. To overcome potential bootstrapping problems of new subgraphs, the Indexer reward incentivizes Indexers to index subgraphs with low query volume. The reward is paid through new token issuance. The mechanism works by allotting each subgraph in the network a portion of the total token issuance based on the subgraph’s curation signal. Indexers then receive a the Indexer reward proportionally to the amount of their contributed stake.

The formula for this is:


ωi = amount of GRT the Indexer has staked on subgraph j
Ωj = total amount of GRT staked on subgraph j
ψj = the curation signal in GRT for subgraph j
Ψ = total amount of GRT signaled in the network by Curators
Φ = total network Indexer reward in GRT

Proofs of Indexing and Subgraph Availability Oracle.

Proofs of Indexing and the Subgraph Availability Oracle were introduced to subsidize useful work in the network and to prevent economic attacks in which Indexers try to collect indexing rewards without having done the required work in the network. Such economic attack vendors could look the following way:

  • An Indexer collects rewards for a subgraph that they are not actually indexing
  • An Indexer receives rewards for indexing a broken subgraph or whose subgraph manifest is not available

Proof of Indexing is therefore introduced to prevent attack vendor #1 and some instances #2. As of now, a signature over a message digest is used, which is generated when a subgraph is indexed from genesis. Likewise, the message digest is updated whenever the state of a subgraph is updated.

In order to claim their indexing rewards on a given subgraph, Indexers need to provide a recent Proof of Indexing (PoI). The PoI is computed from the signature of an Indexer, which is why it is necessary for Indexers to submit an individual PoI specific to them. Due to the competitive nature, Indexers are not incentivized to collude in helping each other generating correct PoIs without having done the work.

The Proofs of Indexing unlock rewards immediately, meaning they are accepted optimistically. However, it is possible to use these rewards to slash an Indexer later on, should the PoI be found to be formed incorrectly. The conditions for slashing an Indexer could include deterministically attributable faults such as:

  • The state of a subgraph is incorrectly represented in the PoI
  • The PoI is provided for an invalid subgraph

Disputes will initially be decided by an Arbitrator who is appointed through governance. If a fault is not clearly attributable or the result of a software bug, the Arbitrator has the power to end disputes in a “draw.” Based on an arbitration charter and the protocol specifications, Arbitrators evaluate disputes and settle them.

Whether or not a subgraph manifest is available is completely subjective because of the speaker/listener fault equivalence. This is another type of fault but an Arbitrator cannot settle any of the other raised disputes for that subgraph if the subgraph manifest is not available. Likewise, it is not possible for other Indexers to compete for the indexing rewards of that particular subgraph.

To solve this issue, The Graph has introduced a Subgraph Availability Oracle, which is set through governance as well. To determine whether or not a subgraph manifest is available, the oracle looks at various prominent IPFS endpoints, like the Cloudflare IPFS Gateway. Should the subgraph manifest be not available, the subgraph is not eligible for the distribution of indexer rewards.

Graph Explorer and Graph Name Service.

The Graph Explorer helps developers to surface valuable subgraphs which provide the data they need for building their dApps and to effortlessly incorporate the data from various data sources into a single application. In essence, the explorer is a dApp that is built on top of a subgraph, which indexes The Graph’s protocol smart contracts.

The Graph Name Service (GNS) is an on-chain registry of subgraphs that is indexed by The Graph Explorer. The GNS allows subgraph developers to define a name for a subgraph and to attach it to it. The name can then be used to point to consecutive “versions” of a subgraph that are immutable.

Thanks to subgraph composition, new subgraph can directly reference entities from existing subgraphs. As a result, the same subgraphs can be used across a variety of different dApps, increasing the overall efficiency in the The Graph Network. So instead of new applications having to deploy their own database and API servers, they can use preexisting entities in existing subgraphs.

Conditional Micropayments.

The Graph’s payment layer utilizes conditional micropayments to minimize the need for trust between Indexers and Data Consumers. To enable scalable, off-chain, trust-minimized payments, the technology of payment channels is utilized. The payment process involves the two parties using an escrow to lock funds on-chain. These funds are then used to exchange funds off-chain until a transaction is submitted on-chain.

Query Verification.

An effective verification mechanism makes sure that indexer staking in the network is meaningful. This mechanism will have to be able to reproduce the indexing work performed by an Indexer. Additionally, it needs to be able to identify faults and slash Indexers that performed their work maliciously or erroneously.

This is accomplished by implementing an on-chain dispute resolution process, which is then decided through arbitration. The types of disputes currently supported are:

  • Single Attestation Disputes
  • Conflicting Attestation Disputes


That was it! We hope you enjoyed this introduction to The Graph Network and that it has helped you to gain a better understanding about the underlying protocol and its architecture.

Go Back

General Knowledge Base

Up next

Coming soon