The Graph Network explained.

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.

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.

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.

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.

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:

Other functionalities of Graph Tokens include:

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:

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:

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.

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:

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:

Formula

ω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.

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:

Formula

ω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 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:

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:

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.

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.

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.

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: