How to evaluate a subgraph for a non tech curator

The graph protocol

Before jumping into the subject, let’s first take some moment to define what is ‘The Graph’ and what is a ‘curator’

The Graph

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.

The Graph explorer

Protocol roles

  • Indexers are the node operators of The Graph. They are motivated by earning financial rewards.
  • Curators use GRT (The Graph token) to signal what subgraphs are valuable to index. These will typically be developers but they could also be end users (non technical) supporting a service they rely upon or a persona that is purely financially motivated.
  • 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.
Curators, Delegators, Indexers in The Graph protocol
Curators, Delegators, Indexers in The Graph protocol
The Graph roles

Now let’s see how a non technical curator can evaluate subgraphs.

How to evaluate subgraphs

Search result in The Graph explorer
Search result in The Graph explorer
Search result from The Graph explorer

Here we have the ‘All the Keeps’ subgraph which is related to the KEEP / tBTC network, and it should be interesting to evaluate.

When clicking on the subgraph we have the following information:

KEEP subgraph
KEEP subgraph
KEEP/tBTC subgraph
  • we already know the subgraph is running on mainnet
  • we have access to the Github repository
  • and more importantly we have the subgraph ID

From here we can first have a look into the Github repository

From the first look, we see that things are pretty well organised as we can find a, a subgraph manifest (subgraph.yaml) and a GraphQL schema (schema.graphql)

KEEP/tBTC Github repository

We know that for evaluating a subgraph we would need to look into the 3 key components which defines what a subgraph is doing:

1- the subgraph manifest which give us a kind of instruction guide on how the graph node is working. It shows where the data is indexed from the Ethereum blockchain.

In this case we can see that we are in front of a complex subgraph where the data is indexed from multiple contracts on the Ethereum blockchain

KEEP subgraph manifest
KEEP subgraph manifest
KEEP/tBTC subgraph manifest

and this is just a small part of the manifest. Actually it has more than 475 lines describing which contracts are used from the mainnet (there are 10 in total) to extract blockchain data and which events are tracked.

Events in the subgraph manifest
Events in the subgraph manifest
Events from the KEEP/tBTC GraphQL schema

In the picture above, this is just an example of the events that are indexed in the subgraph. When you look into the manifest you will find much more !

2- the GraphQL schema is describing the entities or data objects used in the subgraph to organize the data collected from the blockchain. The entities does not need to be event based. For more information, please have a look in The Graph web site here to get more details on how the GraphQL schema should look like.

Below an example of an entity in the GraphQL schema of the KEEP/tBTC network subgraph

An entity definition in the GraphQL schema
An entity definition in the GraphQL schema
An entity in the KEEP /tBTC GraphQL schema

This entity / data object (SetupFailedEvent) is defined by an id, submitter, transaction Hash, timestamp, deposit, operator and the reason why the setup has failed

At this stage beeing able to read the subgraph manifest and the GraphQL schema gives you a good idea on what the subgraph is aiming to do.

3- If you want to deep dive more into what the subgraph is doing, you can look at the mappings file which transforms the lower level Ethereum data into the desired entities that are specified in the GraphQL schema file. To elaborate further, the manifest extracts the raw Ethereum data, and the mappings manipulate this data into the form that is set out in the schema.

Now we had the chance in the subgraph page from The Graph explorer to find a Github repository which has provided us with all this great information. So what could we do if we face this case:

A subgraph without a Github repository

A subgraph without a Github repository … and there comes the ID !

In this case you need to use the ipfs link and add to it the subgraph ID to get the subgraph manifest. In this case we would need to go to: to access the subgraph manifest

A subgraph manifest through ipfs

There we can find out that this subgraph is running on the Rinkeby Ethereum testnet, indexing data from a contract named Pollen with the specific address 0x8B9222DAac6F30fB054b44B335852c37a5c17fE0

At the end of the manifest we have an ID to access the corresponding GraphQL schema. In this case we just need to use the same ipfs url and changing the ID at the end by adding the one in the manifest. It this specific case we would need to visit to access the GraphQL schema:

GraphQL schema from ipfs

We can clearly see the definition of different entities.


Blockchain and crypto enthusiast