The mission of The Graph is to enable internet applications that are entirely powered by public infrastructure.
Full-stack decentralization will enable applications that are resistant to business failures and rent seeking and also facilitate an unprecedented level of interoperability. Users and developers will be able to know that software they invest time and money into can’t suddenly disappear.
To reach this vision of fully decentralized applications (dApps), it’s critical that we shift from a paradigm of businesses paying for the ongoing storage, compute, and other services required to keep an application running, toward users directly paying networks of decentralized service providers for granular usage of these resources.
Today, most “decentralized” applications only adopt such a model in the bottom layer of the stack—the blockchain—where users pay for transactions that modify application state. The rest of the stack continues to be operated by centralized businesses and is subject to arbitrary failures and rent seeking.
What is The Graph Network
The Graph Network decentralizes the query and API layer of Web3, removing a tradeoff dApp developers struggle with today: whether to build an application that is performant or to build an app that is truly decentralized.
Today, developers can run a Graph Node on their own infrastructure, or they can build on our hosted service. 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. In The Graph Network, any Indexer will be able to stake Graph Tokens (GRT) to participate in the network and earn fees as well as inflation rewards for serving queries.
Consumers will be able to use this growing set of Indexers by paying for their metered usage, proving a model where the laws of supply and demand sustain the services provided by the protocol.
Protocol Roles
These are the roles that interact with the system, the behaviors they must engage in for the protocol to function correctly, and what incentives motivate them.
- Consumers. Consumers pay Indexers for queries. These will typically be end users but could also be web services or middleware that integrate with The Graph.
- Indexers. Indexers are the node operators of The Graph. They are motivated by earning financial rewards.
- Curators. Curators use GRT to signal what subgraphs are valuable to index. These will typically be developers but they could also be end users supporting a service they rely upon or a persona that is purely financially motivated.
- Delegators. 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.
- Fishermen. Fishermen secure the network by checking if query responses are accurate. Fishermen are altruistically motivated, and for that reason, The Graph will initially operate a fisherman service for the network.
- Arbitrators. Arbitrators determine whether Indexers should be slashed or not during dispute resolution. They may be financially or altruistically motivated.
Usage
Developers
For developers, the APIs for building a subgraph will remain largely the same as it is using a local or hosted Graph Node.
One notable difference is in how developers deploy subgraphs. Rather than deploying to a local or hosted Graph Node, they will deploy their subgraph to a registry hosted on Ethereum and deposit a stake of GRT to curate that subgraph. This serves as a signal to Indexers that this subgraph should be indexed.
End Users
For end users, the major difference is that rather than interacting with centralized APIs that are subsidized, they will need to begin paying to query a decentralized network of Indexers. This will be done via a query engine running on their machine—either in the browser, as an extension, or embedded in the dApp.
The query engine allows the user to safely query the vast amounts of data stored on The Graph without having to personally do the work to compute and store that data. The query engine also acts as a trading engine, making decisions such as which Indexers to do business with or how much to pay, based on the dApp being used or the user’s preferences.
For the query engine to provide a good user experience, it will need to automatically sign micropayment transactions on behalf of users rather than prompting them for every transaction that needs signing. We’re working with several state channel teams building on Ethereum to make sure that the wallets and functionality they ship meets the needs of metered usage protocols like The Graph. In the meantime, we will host a gateway that allows dApps to subsidize queries on behalf of users.
Indexers
Indexers will be able to join The Graph by staking GRT and running a version of Graph Node.
They will also want to run an indexer agent that programmatically monitors their resource usage, sets prices, and decides which subgraphs to index. The indexer agent will be pluggable, and we expect that node operators will experiment with their own pricing models and strategies to gain a competitive edge in the marketplace over other Indexers.
Curators and Delegators
Curators and delegators will curate and delegate via Graph Explorer. When we launch the network, Graph Explorer will be a fully decentralized application, and using it will require a dApp-enabled browser with an Ethereum wallet.
Architecture
The Graph Network includes smart contracts that run on Ethereum combined with a variety of additional services and clients that operate off-chain.
Query Market
The query market serves a similar purpose to an API in a traditional cloud-based application—efficiently serving data required by a front end running on a user’s device. The key difference is that whereas a traditional API is operated by a single economic entity that users have no say over, the query market comprises a decentralized network of Indexers, all competing to provide the best service at the best price.
This redundancy means that even if a single Indexer goes offline, as long as there exists demand for querying a dataset, other Indexers will be incentivized to absorb the additional work.
Transactions in the query market are priced based on the bandwidth and compute required to process the query.
Let’s take a look at what a typical flow might look like for a consumer interacting with the query market.
- Service Discovery. The consumer asks The Graph which Indexers have the data they are interested in.
- Indexer Selection. The consumer selects an Indexer to transact with based on which they deem most likely to provide the highest quality service at the best price.
- Query + Conditional Micropayment. The consumer sends the Indexer a query along with a conditional micropayment that specifies how much they are willing to pay for compute and bandwidth.
- Response + Attestation. If the Indexer accepts the price offered by the consumer, then they process the query and respond with the resulting data, as well as an attestation that this response is correct. Providing this attestation unlocks the conditional micropayment.
The attestation is produced deterministically and is uniquely attributable to the Indexer for the purposes of verification and dispute resolution elsewhere in the protocol.
A single decentralized application querying The Graph may use multiple subgraphs indexed by different Indexers and in that case would go through the above flow for each subgraph being queried.
Graph Tokens
To support the functioning of the query market, the protocol introduces a native token: Graph Tokens (GRT).
Graph Tokens have two primary uses in the protocol:
- Indexer Staking. Indexers deposit Graph Tokens to be discoverable in the query market and to provide economic security for the work they are performing.
- Curator Signaling. Curators deposit Graph Tokens in a curation market, where they are rewarded for correctly predicting which subgraphs will be valuable to the network.
Consumers will be able to pay for queries in ETH or DAI. Payments will be settled, however, in GRT to ensure a common unit of account across the protocol.
In addition to the uses outlined above, having a native token allows us to incentivize certain behaviors through inflation. The ability to have a dynamically adjusted inflationary monetary policy is a powerful tool in the toolbelt.
Indexer Staking
The Graph adopts a work token model, where Indexers must stake Graph Tokens in order to sell their services in the query market. This serves two primary functions.
- It provides economic security, as the staked GRT can be slashed if Indexers perform their work maliciously. Once GRT is staked, it may only be withdrawn subject to a thawing period, which provides ample opportunity for verification and dispute resolution.
- It provides a Sybil resistance mechanism. Having fake or low quality Indexers on a given subgraph makes it slower to find quality service providers. For this reason we only want Indexers who have skin in the game to be discoverable.
In order for the above mechanisms to function correctly, it’s important that Indexers are incentivized to hold GRT roughly in proportion to the amount of useful work they’re doing in the network.
A naive approach would be to try to make it so that each GRT staked entitles an Indexer to perform a specified amount of work on the network. There are two problems with this: first, it sets an arbitrary upper bound on the amount of work the network can perform; and second, it is nearly impossible to enforce in a way that is scalable, since it would require that all work be centrally coordinated on-chain.
A better approach has been pioneered by the team at 0x, and it involves collecting a protocol fee on all transactions in the protocol, and then rebating those fees to participants as a function of their proportional stake and proportional fees collected for the network, using the Cobb-Douglas production function.
In our construction, the rebate Yi an Indexer i receives during a time period is 
I recommend reading the paper — but what’s interesting for our purpose is that in equilibrium a rational decision maker would be expected to budget a stable proportion of their spending between the two inputs to the production function. In our case, that would be the cost of renting or owning GRT and the operating expenses related to running a Graph Node which allows an Indexer to perform more work, and by extension collect more protocol fees.
Because we would expect all rational Indexers to make an equivalent budgeting decision, in equilibrium, we should expect Indexers to stake a proportion of total GRT staked, equal to the proportion of work they have performed for the network.
The beauty is that this distribution of stake doesn’t need to be enforced in the protocol, but rather, it arises naturally from Indexers making decisions in their own economic best interest.
Curator Signaling
For a consumer to query a subgraph, the subgraph must first be indexed—a process which can take hours or even days. If Indexers had to blindly guess which subgraphs they should index on the off-chance that they would earn query fees, the market would not be very efficient.
Curator signaling is the process of depositing GRT into a bonding curve for a subgraph to indicate to Indexers that the subgraph should be indexed.
Indexers can trust the signal because when curators deposit GRT into the bonding curve, they mint curation signal for the respective subgraph, entitling them to a portion of future query fees collected on that subgraph. A rationally self-interested curator should signal GRT toward subgraphs that they predict will generate fees for the network.
Using bonding curves—a type of algorithmic market maker where price is determined by a function—means that the more curation signal are minted, the higher the exchange rate between GRT and curation signal becomes. Thus, successful curators could take profits immediately if they feel that the value of future curation fees has been correctly priced in. Similarly, they should withdraw their GRT if they feel that the market has priced the value of curation signal too high.
This dynamic means that the amount of GRT signaled toward a subgraph should provide an ongoing and valuable market signal as to the market’s prediction for future query volume on a subgraph.
Indexer Inflation Reward
Another mechanism we employ related to indexer staking and curator signaling is the indexer inflation reward.
This reward is intended to incentivize Indexers to index subgraphs that don’t yet have significant query volume. This helps to solve the bootstrapping problem for new subgraphs, which may not have pre-existing demand to attract Indexers.
The way it works is that each subgraph in the network is allotted a portion of the total network inflation reward, based on the proportional amount of total curation signal that subgraph has. That amount, in turn, is divided between all the Indexers staked on that subgraph proportional to their amount of contributed stake.
More formally, the indexer inflation reward for Indexer i is
Setting the inflation rate dynamically in a way that is optimal is an area of ongoing research, but suffice to say that it will be low, most likely single digit.
This mechanism provides an additional incentive for Indexers to be responsive to the signal provided by curators, making curation an even more useful activity to engage in.
In the long term, we would expect rational Indexers to stake GRT on subgraphs where they will earn inflation rewards and earn query fees. During the early days of the network, however, there is an incentive for Indexers to stake but not actually do the work of indexing and serving queries on any subgraphs.
For that reason, during a bootstrapping phase, there will be an indexer monitoring service which is set via protocol governance. This service has the authority to add Indexers to a blacklist if they are found to be unavailable for serving queries on the subgraphs they are staked on.
Because there are benign reasons for becoming unavailable, the only penalty for ending up on a blacklist is that you are disqualified from earning inflation rewards until you are removed. Being blacklisted will not result in slashing.
Graph Explorer and Graph Name Service
Curating subgraphs for Indexers is only half of the story when it comes to surfacing valuable subgraphs. We also want to surface valuable subgraphs for developers.
This is one of the core value propositions of The Graph—to help developers find useful data to build on and make it effortless to incorporate data from a variety of underlying protocols and decentralized data sources into a single application.
Currently, developers accomplish this by navigating to Graph Explorer: 
In The Graph Network, Graph Explorer will be a dApp, built on top of a subgraph that indexes the Graph Protocol smart contracts (meta, I know!)—including the Graph Name Service (GNS), an on-chain registry of subgraphs.
A subgraph is defined by a subgraph manifest, which is immutable and stored on IPFS. The immutability is important for having deterministic and reproducible queries for verification and dispute resolution. The GNS performs a much needed role by allowing teams to attach a name to a subgraph, which can then be used to point to consecutive immutable subgraph “versions.”
These human readable names, along with other metadata stored in the GNS, allows users of Graph Explorer to get a better sense for the purpose and possible utility of a subgraph in a way that a random string of alphanumeric characters and compiled WASM byte code does not.
In The Graph Network, discovering useful subgraphs will be even more important, as we will be shipping subgraph composition. Rather than simply letting dApps build on multiple separate subgraphs, subgraph composition will allow brand new subgraphs to be built that directly reference entities from existing subgraphs.
This reuse of the same subgraphs across many dApps and other subgraphs is one of the core efficiencies that The Graph unlocks. Compare this approach to the current state of the world where each new application deploys their own database and API servers, which often go underutilized.
Conditional Micropayments
Our payments layer is designed to minimize trust between the consumer and the Indexer. Payment channels is a technology that has been developed for scalable, off-chain, trust-minimized payments. It involves two parties locking funds on-chain in an escrow where the funds may only be used to exchange funds off-chain between them until a transaction is submitted on-chain to withdraw funds from the escrow.
Traditionally, payment channel designs have emphasized securely sending a micropayment off-chain without regard for whether or not the service or good being paid for was actually received.
There has been some work, however, toward atomic swaps of micropayments for some digital good or outsourced computation, which we build on here. We call our construction WAVE Locks. WAVE stands for work, attestation, verification, expiration, and the general design is as follows:
- Work. A consumer sends a locked micropayment with a description of the work to be performed. This specification of the work acts as the lock on the micropayment.
- Attestation. A service provider responds with the digital good or service being requested along with a signed attestation that the work was performed correctly.
- Verification. The attestation is verified using some method of verification. There may be penalties, such as slashing, for attesting to work which was incorrectly performed.
- Expiration. The service provider must either receive a confirmation of receipt from the consumer or submit their attestation on-chain to receive their micropayment before the locked micropayment expires.
Using locks with payment channels is not new. Both Lightning and Raiden papers discuss using a hash preimage to unlock a micropayment. This is particularly useful for multi-hop micropayments where each “hop” is locked with the same hash and can be unlocked by a value, the preimage, that produces that hash when input to a specified hashing function. 
While we could roll our own payment channel solution, which is purpose-built with this new locking mechanism, a more pragmatic solution is to use state channels.
We can think of state channels being to payment channels, what smart contract blockchains like Ethereum are to Bitcoin. They can handle the simple payments use case, but they can also codify more complex state transitions while keeping the same scalability and security properties as a payment channel.
What payment and state channels have in common, however, is that in their most basic form they are a means of exchanging value or state updates between two participants, which are known ahead of time. As alluded to above with the multi-hop micropayments, sending between any two participants requires being able to form a chain of payment channels across multiple other participants, which connects the two original participants.
There are a variety of clever projects working on different forms of graph traversal to facilitate these micropayments between any two arbitrary participants. For simplicity, The Graph Network will initially use a hub and spoke topology.
This means that in order to use The Graph a consumer will need to have a state channel open on-chain with the state channel hub, which is loaded with their preferred stable token or ETH. The Indexers, meanwhile, will also need to have a state channel open with the hub where they can receive GRT.
The state channel hub will be collateralized with GRT and be responsible for setting the exchange rate between the payment denomination and GRT so that all micropayments are settled in the same unit of account.
Verification
In order for the WAVE Locks construction and indexer staking to be meaningful, there must be an effective verification mechanism that is capable of reproducing the work performed by an Indexer, identifying faults and slashing offending Indexers.
In the first phase of The Graph Network, this is handled through an on-chain dispute resolution process, which is decided through arbitration.
Fishermen submit disputes along with a bond, as well as an attestation signed by an Indexer. If the Indexer is found to have attested to an incorrect query response, the fisherman receives a portion of the slashed amount as a reward. Conversely, the fisherman’s bond is forfeit if the dispute is unsuccessful.
Importantly, the fisherman’s reward must be less than the slashed amount. Otherwise, malicious Indexers could simply slash themselves to get around thawing periods or avoid slashing by someone else.
In the long run, as the network becomes more reliable, we would expect the reward to active fishermen to dwindle to near zero. Thus, even though there is a fisherman’s reward, we consider this actor to be motivated by altruistic incentives.
For that reason, initially, there will be a fisherman service where consumers may post attestations, and we will take on the responsibility of verifying query responses and submitting disputes on-chain. Of course, anyone who wishes may also perform this role.
Additionally, in the early days of the network, there will be an arbitration service set via protocol governance, which will act as the sole arbitrator in the dispute resolution. This allows us to exercise judgment when incorrect queries may arise as a result of bugs in the software, Indexers missing events from the blockchain, or other accidental factors that could lead to a slashable offense.
Eventually, as the software matures, Indexers will be expected to develop the operational know-how to avoid these sorts of errors.
Future Work
Future work on The Graph Network involves exploring new market mechanisms and parameterization of existing mechanisms, which will make the query market more dynamic and efficient. The latter will involve running agent-based and dynamic simulations on the existing mechanism design, as well as analyzing the network after launch.
The contracts will be upgradeable so the protocol can continue to be improved after launch.
In the longer term, we would like to eliminate the roles of fisherman and arbitrator altogether, by relying on authenticated data structures, consensus and cryptographic proofs. Doing this performantly has been an area of ongoing research for our team and something we’ll be writing more about in the near future.
