Web 3 has a number of intriguing features for developers to investigate, particularly its distributed storage capability, which is based on the development of blockchain technology. Data saved on blockchains, however, must be pre-processed before being usable for dApp, which takes time and resources. Furthermore, the current solution is based on centralized indexing servers, which negates all of the benefits of a decentralized ecosystem.

The Graph was built to take a fresh approach to solve the problem and to pave the way for a completely decentralized web 3 development stack.

It's a decentralized query protocol for indexing data on blockchains that allows users to query data on the blockchain quickly and effectively without relying on a centralized infrastructure. In fact, several apps have adopted Graph Solution for their services, such as Uniswap, AAVE, Balancer, and Decentraland.

In this article, we provide readers with the basic information about The Graph and explain why it is called “The Google of blockchain”.

How The Graph works?

In The Graph protocol, end-users (typically dApp developers) can rely on a decentralized network of indexing nodes instead of centralized indexing servers to query data on blockchains. Instructions for handling these on-chain data (such as events emitted from activities of smart contracts) will be defined in a special type of API called “subgraph”. According to these subgraphs, indexing nodes will select, index, and store data on the blockchain. After being indexed,  data may now be readily queried by dApps using GraphQ, a convenient and straightforward query language.

The working mechanism of The Graph protocol, including Smart Contract, Subgraph, Database, Graph AL and dApps
The working mechanism of The Graph protocol. Source: thegraph.com

Given that The Graph uses a proof-of-stake model, node operators have to stake an amount of money to guarantee the validity of their work. Then, they can receive money by running their nodes for end-users as a contribution to the network. Both the money they have staked and the incentives they have received are in GRT - The Graph’s native token.

The different roles in The Graph Network

The Graph operation is a distributed protocol that relies on the engagement of a community made up of four main roles: consumer, indexer, curator, and delegator.


Consumers are the end-users of the network. They pay Indexers for properly indexed subgraphs from which they may query high-volume, high-speed data.

The Graph proves itself to be exceptionally more convenient for end-users  compared to traditional methods:

  • The Graph simplifies the procedure of getting data from the blockchains. Rather than developing a specific method of querying data for every single dApp, now simply need to create an appropriate subgraph (either on their own or via the "Subgraphs Explorer"), which they can then release on the network for Indexers to use.
  • A distinguishing characteristic of the Graph is the querying market. Instead of depending on a single service provider over whom they have little control, end-users may choose from a number of Indexers for the most appropriate service at the best price.


Indexers are the protocol's node operators who handle The Graph Network's principal workload: indexing subgraphs.

Being an Indexer requires technical knowledge since they will have to efficiently operate a version of Graph Node on their machine while maintaining a database for customers to query. Secondly, the Indexers' job also needs sufficient funding to meet the network's hardware requirements and stake in the staking pool. The latter, however, can be funded by the participation of Delegators.

If an expert meets both the technical and financial requirements, they will be able to recover revenue from the following sources:

  • Indexing reward: Indexers are compensated based on the amount of work they have completed on a subgraph.
  • Query fee: Consumers will pay indexing nodes an amount of query fee for indexed data. The price is decided by Indexers, so they will need to wisely choose which subgraph to index and experiment with their own pricing model to attract Consumers.
  • Rebate pool: a proportion of the money Indexers staked will be returned back to them. This encourages Indexers to stake more money and increase the security of their job.


As all subgraphs are open-source and freely developed by developers worldwide, Indexers may find it difficult to decide which subgraph to index. In this case, Curators are responsible for signaling to Indexers which subgraph is useful.

If they find one, they can deposit GRT into that subgraph’s “bonding curve reserve”, and gain back “curation shares' '. The bonding curve model of a subgraph’s curation shares reserve means that the more Curators deposit into a subgraph, the more expensive the curation share becomes. This approach provides a reliable prediction about the future value of a subgraph.

Bonding curve for Subgraph
Bonding curve reserve. Source: thegraph.com

Curators can be subgraph developers who want Indexers to find and index their subgraph. They can also be individuals who are motivated by financial rewards in two ways:

  • Predict the appropriate subgraph: Curators can benefit if the value of the subgraph they deposit into improves (which increases the price of the curation share). Similarly, they may need to remove GRT from a subgraph if the curation share of that subgraph is projected to decrease in value.
  • Query fee: Curators are paid a portion of the query fees for the subgraphs that they have indicated.


While Curators assist Indexers in determining which subgraphs to index, Delegators provide Indexers with financial support in staking GRT. Delegators can take part in the staking pool on behalf of Indexers and get corresponding rebates from the query fees from Consumers.

Operating node incentives will be split between Indexers and Delegators via a staking pool, with a percentage of Indexers' revenue going to Delegators. Delegators must carefully pick which Indexer to delegate since the amount of money a Delegator may recover is solely dictated by their Indexers.

Primary roles of The Graph include consumer, delegator, indexer, and curator
Primary roles of The Graph

Fisherman and Arbitrator

Besides these four fundamental roles, which form The Graph Platform, two more additional functions are required in the event of disputation:

  • Fisherman: Their jobs are detecting the inaccurate data provided by indexers and reporting it to Arbitrators. Fishermen run specific nodes that determine the correctness of The Graph Network’s response to queries.
  • Arbitrator: once unqualified Indexers are reported, they will be penalized by the Arbitrators. These Arbitrators have the power to reduce the GRT staked by defective Indexers or even remove them from the network if their actions have serious implications.


One of the key concepts in The Graph ecosystem is the creation of data-querying APIs called “subgraphs”. A subgraph includes various types of information such as the data source, which blocks to index, which events to notice, how the data will be retrieved, or the schema that data should be stored. Indexing nodes only need to follow instructions in subgraphs to function.

Before The Graph, dApp developers had to undergo a lengthy and tedious process of designing specific data querying solutions for every single project. With the implementation of a subgraph, Developers just need a subgraph that meets their requirements. They can either create their own subgraph or use a third-party subgraph through the use of Subgraph Explorer, then deploy it on the network for Indexers to handle the rest of the process.

List of places developers can view subgraphs deployed on the related networks
Where developers can view subgraphs deployed on the network. Source: thegraph.com

However, if developers don’t want to depend upon the distributed network of Indexers to run their subgraph, the Graph team still supports a Hosted Service. On The Graph’s Hosted Service, subgraphs are operated on centralized Graph Nodes, without the need for GRT, Indexers, or Curators. Of course, this is only a temporary service and will be dropped soon when The Graph becomes fully decentralized.


Besides actualizing a decentralized protocol for querying data from the blockchain, The Graph also applies GraphQL, a simple and universal query language. GraphQL was created by Facebook in 2012 for APIs to fetch data. It has a number of advantages over more standard techniques such as REST or SOAP:

  • The syntax is very intuitive, and the result is predictable.
  • Get every data required in a single request, improving querying speed even on a slow network connection.
  • Client-driven, more suitable for distributed systems.
An infographic that compare GraphQL and REST
Comparison between GraphQL and REST. Source: mobilelive.ca

Graph Token (GRT)

The Graph Token serves as a trade tool within the Graph ecosystem. It's critical for the protocol's overall functionality, notably the two aspects listed below:

  • Indexer staking: Indexers will have to stake GRT to ensure the quality of their subgraph indexing assignment. Indexers receive a portion of the profits from the indexed subgraphs in GRT.
  • Curator signaling: Curators can deposit or remove GRT into a subgraph to indicate whether it is valuable for indexing. The more GRT that is put into a subgraph, the more appealing it becomes to Indexers.


Although being a very young product (announced in 2018), The Graph has proven exceedingly promising. Being the lone pioneer in the brand new field of Web3 and dApp development brings both challenges and opportunities to The Graph team. However, the team has taken advantage of every opportunity and overcome most of their challenges. The protocol has addressed the difficult challenge of fully decentralizing the Web3 development stack, made data querying on blockchains easier, and removed the weight of needing to construct data accessing solutions for each project from the shoulders of Dapp developers while still maintaining centralized system support for specific users. As a result, the Graph has successfully become a leading figure on the Web3 platform, heavily utilized by numerous decentralized applications as the primary data-providing solution.

Despite this, The Graph is not yet a flawless product, with various features that need to be investigated and several drawbacks to be addressed. Firstly, The Graph project originated from the Ethereum blockchain, and up until now, it’s the only officially supported platform. Despite the development team's efforts to introduce the protocol to other platforms, only beta versions of the protocol have been released for major blockchains such as Polygon, Polkadot, BSC, and others. Secondly, despite its dominant position on the Web3 developing stack, The Graph has never been a contender for off-chain databases, a feature that some dApps might need for privacy or performance requirements. All the reasons above make The Graph, no matter how advanced it might be, still far from becoming a universal solution.

In the end, The Graph team has been doing an excellent job of developing their product, with a catalog of miraculous features that revolutionized the way people use blockchains in decentralized applications. And with several upcoming improvements and additions, such as the launch of The Graph Council - the on-chain governance of the platform, it must be said that the analogy between The Graph and Google is not unfounded, and The Graph will play a crucial role in the process of realizing and popularizing Web3 in the near future.


[1] Introduction to The Graph, thegraph.com, accessed March 2nd, 2022.

[2] The Graph network in-depth part I, thegraph.com, accessed March 2nd, 2022.

[3] The graph network in-depth part II, thegraph.com, accessed March 2nd, 2022.

[4] The Graph will power the decentralized web, medium.com, accessed March 2nd, 2022.  

[5] GraphQL vs. REST: What You Didn’t Know, mobilelive.ca, accessed March 3rd, 2022.  

[6] The Graph Academy, thegraph.academy, accessed March 3rd, 2022.