Curation FAQ.

Let’s start this list of frequently asked questions with common questions about Curation in general.

Subgraphs (i.e. open APIs) are open-source, which means that anyone can build one. This makes it challenging to quickly identify quality subgraphs on The Graph Network. To solve this information asymmetry, The Graph utilizes curation. Curators analyze subgraphs and curate high-quality subgraphs by signaling on them.

For a detailed explanation, have a look at What is a Curator?

From a technical standpoint, curating is very easy thanks to The Graph Explorer’s intuitive UI. In general, curation is a very dynamic process that offers large potential gains but also large potential losses. It may not necessarily be the best option for someone not wishing to take a lot of risks. For all those wishing to reduce risks and taking on a more passive role, becoming a Delegator may be a better option.

Delegation is a safe and stable way of generating interest while not exposing yourself to the high risks Curators are confronted with. Curation, however, is significantly riskier as Curators may be confronted with loss of capital. At the same time, Curation can be more profitable than delegating.

You can use Graphscan to calculate potential curation rewards for the subggraph of your choice.

A subgraph is an open API that data consumers can use to query data directly from a supported blockchain network. Developers can use subgraphs to define, which data from which network they would like to index so that it can be queried by decentralized applications (dApps).

Curation shares are shares for a particular subgraph which entitle Curators to a proportionate portion of the query fees a subgraph generates. The price per share is influenced by supply and demand, governed through a bonding curve. If many Curators mint new shares of a subgraph (i.e. buying shares with GRT), the price per share will increase. The share price decreases if Curators unsignal from the subgraph by burning their shares.

There is no minimum amount of GRT required to curate. However, a minimum of 100 GRT is needed to curate a subgraph with no signal. Please note that you’ll have to pay gas costs and a curation fee. For this reason, it may not be profitable to signal small amounts of GRT.

This section covers frequent questions about the query fees generated by data consumers.

Curators receive query fees as soon as the particular subgraph is fully indexed and starts receiving queries from data consumers. However, please keep in mind that Curators will not earn query fees if the Subgraph does not generate query fees.

Similar to delegation rewards, Curators receive query fees whenever an Indexer closes the allocation. Indexers have the choice between closing the allocation manually or letting it be automatically closed after around 28 days.

There could be two possible reasons: The Indexer has not yet closed the allocation, which is why your query fees have not been sent to you, yet. Closing an allocation can either be done manually by the Indexer or occurs automatically after around 28 days.

No, there is no unbonding/thawing period. After you have unsignaled and the transactions have been confirmed, you are free to move your GRT however you please.

The query fees are deposited directly into the bonding curve of the subgraph. This means that each share will be worth more when you burn your shares to retrieve GRT. Similarly, your curation shares will be worth more over time, assuming the subgraph generates query fees.

Here are the exact numbers: 1% of the query fees are burned. 10% are deposited into the bonding curve, with the remaining going into a query fee rebate pool for the Indexers that serve those queries.

The reserves of a subgraph’s bonding curve come from two sources:

A) Curators depositing GRT into the bonding curve to mint new curation shares

B) 10% of the generated query fees of a subgraph are deposited into the bonding curve without minting new shares

Because 10% of the generated query fees are deposited into the bonding curve, the value of each share increaes if a subgraph receives queries.

Detailed answers to questions about curating.

It is advisable to only curate through the The Graph Explorer, which can be found here: Graph Explorer.

(Credit: DataNexus)

It is advisable to look for projects that appear to be under signaled. This is currently a relative amount since a ‘fair signal’ is still being decided by the market. We’re currently at a stage where many subgraphs have been newly migrated but haven’t yet been integrated into their live site. So currently there is a lot of speculation going on around the newer subgraphs. You might make better decisions than the rest of the market (and would stand to have your shares appreciate if true).

For subgraphs that are project specific, they will receive a lot more use if that project is also using it (rather than relying solely on 3rd party DApps to query the data from the subgraph).

This is not possible. However, you can release unlocked GRT to your beneficiary wallet and use those to curate.

The UI of The Graph Explorer will let you choose between automatically migrating to the latest version of the Subgraph you are signaling or doing it manually. If you choose auto-migration, you will get automatically migrated once the Subgraph gets updated by its developers. This is the recommended setting for new users. Advanced users may wish to migrate manually but this introduces the risk of signaling an outdated Subgraph version that is no longer generating query fees.

Slippage protection is there to protect Curators if share price changes unfavorably (above the threshold of 0.5%) while submitting a transaction. The default slippage tolerance is 0.5% and Curators can update that value at the bottom of the signal if they understand the risks of doing so.

Why do I need to sign two transactions to signal on a subgraph?

To curate, you will have to sign two transactions:

A) Approving: this transaction allows the contract to spend your GRT
B) Curating: this deposits GRT to mint the subgraph’s curation shares

Curators receive a portion of the generated query fees of the subgraph they have signaled on in relation to the amount of shares they have minted. To get rewarded, Curators need to burn their curation shares.

Curators play a key role in signaling Indexers which subgraphs they should index. At the same time, Curators may wish to signal already indexed subgraphs for a longer period of time in order to earn a portion of the generated query fees and to let their curation shares appreciate in value. For this reason, Curators may find it lucrative to signal already indexed subgraphs with an attractive query generation potential. However, the risk of other Curators burning their curation shares (which would then decrease the value of the Curators’ shares) is higher.

Calculating how many GRT it takes to mint one share of a subgraph is really simple. Assuming a subgraph does not generate any query fees, the formula for the calculation of the share value in GRT looks as follows

(total number of shares x total number of shares) = GRT needed to mint 1 share

So if the total number of shares is 25, it would take 625 GRT (25 x 25) to mint one share. Here’s a projection:

• 25 shares = 625 GRT
• 50 shares = 2,500 GRT
• 100 shares = 10,000 GRT
• 150 shares = 22,500 GRT
• 200 shares = 40.000 GRT

Let’s have a look at common questions Curators have about subgraphs.

We find ourselves at an early stage of the project where there is not a simple way to verify the legitimacy of a subgraph, yet. ENS names can help you in this just as much as verifying the publisher’s ETH address. Simlarly, subgraph developers may choose to publicly announce the deployment of their subgraph.

In the subgraph’s code, there are links to the GitHub as metadata. You can get the deployed assets to verify the subgraph by catting the subgraph deployment ID on IPFS. For example, Livepeer’s subgraph address is 0xb31aa1f312595af94f184c5791dc03d6af12fbff, which you could then match against the source in their repository.

Your goal as a Curator is to assess which subgraphs are going to get query fees. You can evaluate the subgraph itself, but that doesn’t tell you who’s going to use it or if the actual project team is going to deploy their own subgraph later on.

Developers are free to create multiple versions of a subgraph without deactivating its older versions as they may be still relevant to some. This introduces the risk that you signal an outdated version of a subgraph that is no longer generating query fees. If you do not wish to monitor if you are still signaling the latest version of your subgraph, make sure to choose the auto-migration feature when minting new shares of a subgraph (i.e. signaling on it).

When a new version of a subgraph is deployed, it does not replace the previous subgraph. One dApp may wish to regularly upgrade the subgraph with new features. Another dApp may prefer to use an older, well tested subgraph version.

[Credit: Matheos]

Step 1. Check if the subgraph is published by the official project team:

• Assume by default it is not, in particular if there is ‘official’ in the name
• Check the project team’s official channels (Twitter, Discord, ask in DM, ..)
• Check the address of the subgraph owner, from where it was funded, if it has an ENS name or not
• Check if the subgraph is used by the project’s team, checking on Github or inspecting the requests from your web browser

Step 2. If the project is not official, there might still be some demand but this is getting very risky!

• Check IPFS/metadata to verify the data matches with the project’s github (if any)
• Check the amount of queries (if already indexed)
• Check if the owner already rugpulled on other subgraphs, was part of the curator program, has POAP badges.

The bonding curve of each subgraph starts the same but starts to change as query fees are being generated. Calculating how many GRT it takes to mint one share of a subgraph is really simple. Assuming a subgraph does not generate any query fees, the formula for the calculation of the share value in GRT looks as follows

(total number of shares x total number of shares) = GRT needed to mint 1 share

So if the total number of shares is 25, it would take 625 GRT (25 x 25) to mint one share. Here’s a projection:

• 25 shares = 625 GRT
• 50 shares = 2,500 GRT
• 100 shares = 10,000 GRT
• 150 shares = 22,500 GRT
• 200 shares = 40.000 GRT

Detailed answers to errors and other problems.

Slippage protection is enabled so that if the share price changed unfavorably (above a certain percentage threshold) while you are setting up and submitting the transaction it will revert your transaction. The default slippage tolerance is 0.5% and you can update that value at the bottom of the signal pane if you are feeling risky.

The error occurs when someone signaled shortly before you, thereby changing the share price to your disfavor. Please try submitting the transaction again. You can also use the slippage dropdown to allow for more slippage but this is not recommended.

It is possible to retrieve GRT from deprecated subgraphs. Though, be aware that due to the bonding curve, it might be (significantly) less than you put in.

[Credit: James The Bondsmith, Curation Specialist]

You can recover your GRT by following these steps:

• Step 1: Go to the GraphProxy
• Step 2: Find the withdraw function
• Step 3: Find the subgraph ID of the deprecated subgraph (ex. 0x2382ab6c2099474cf424560a370ed1b1fdb65253-0).
• For the graphAccount enter the first part of the subgraph ID (ex. 0x2382ab6c2099474cf424560a370ed1b1fdb65253)
• For the subgraphNumber enter the second part of the subgraph ID (ex. 0)
• Step 4: Write the txn (connect Etherscan to your MetaMask wallet)

If the above steps do not work and all the information in Step 3 is correct, then your first troubleshooting step is to reconnect wallet

Go to your curated Subgraph, click on Unsignal and select the signal version you’d like to check. Here you can see if it is set to auto-migrate or not auto-migrate.

Bots may be programmed to beat any gas price that you set for a signaling transaction. Most likely, you will not win if you try to signal earlier than a frontrunning bot. It is therefore recommended to define your curation strategy based on a medium and long-term orientation and to take the quality of a Subgraph into account so that you can generated attractive query fees over a longer period of time. Frontrunning bots may eventually take profits and leave the Subgraph, causing the signal to rebalance.