The Graph: Economics of Web3 Indexing
The ICO Drops team is an investor in Graph Protocol.
The road to Web 3.0 is a thorny and bumpy one. Today, any team that builds something on Ethereum (or any other) or a service around it faces the problem of getting data from the Ethereum blockchain. In addition to interaction at the level of smart contracts, it is necessary not to forget about other interaction components: for example, about the hosting provider.
For this, centralized services are used. To get more complex data, you need to build your API to interact with Ethereum, which is costly and time-consuming.
The Graph Protocol
The Graph Protocol is a protocol for indexing data on Ethereum using APIs called subgraphs. Any data from the blockchain can be obtained using simple queries. Expansion to other blockchains is also planned in the future (if necessary).
Subgraph queries are made with the GraphQL query language. This allows you to flexibly combine different data in one request, which would be more difficult with other approaches. Each subgraph has its own GraphQL query schema, which allows the developer to quickly begin working with any subgragh.
At the moment, the team supports the entire infrastructure of already existing subgraphs, providing data for the most famous dApps: Uniswap, Synthetix, Aave, etc. Since there is a single point of failure, there is a risk that the interface for these services may be temporarily unavailable.
The mainnet went live on December 17, marking the beginning of the Graph Protocol’s transition from a single point of failure to a distributed system.
Currently, there are 99 indexers (aka stakers) on the network. Almost all of them came from the testnet, which was attended by about 200 indexers. However, the functionality of the network is currently limited. There is 1 subgraph from PoolTogether in the network, and the possibility of earning money for requests is limited.
It is worth noting that two versions of the Graph Protocol operate in parallel:
- Main network (distributed network of indexers)
- The network that the team maintains (due to which many services work)
Protocol participants
The protocol functions as a marketplace that has combined 4 types of agents:
- Consumers
- Indexers
- Curators
- Delegating
The main element of the protocol’s functioning is the GRT token, which coordinates agents’ behaviour using the token economy.
Consumers: decentralized applications, services, exchanges that need data.
Indexers: are responsible for indexing all data, receiving a reward in the form of 3% protocol inflation (indexer rewards), which is distributed among all signalled subgraphs. If the supplied data is incorrect, they risk losing their staked GRT.
Indexers also receive a commission in the form of query fees. The price per request depends on the popularity of the subgraph, the price of indexing the subgraph, the market value of the request, opportunity cost, etc.
Since their infrastructural capabilities for indexing subgraphs are limited, and queries are not stable, they need to monitor how popular the subgraph. This is where curators come into play.
Curators: These are agents who need to have both technical skills, but they can also operate online and without them.
The curator’s primary goal is to identify a popular subgraph and send a signal (GRT tokens). The more the subgraph has collected signals (the number of staked GRTs), the higher the protocol inflation it will receive.
You can say that indexers and curators can cooperate and send a signal to one subgraph. What are the incentives to lead a curator rationally?
- They receive 10% of rewards only from commissions per request; thus it is beneficial for them to signal rationally.
- The sooner they find a subgraph that will be popular soon, the more rewards they will receive compared to other curators. This incentive is implemented by determining the share of awards in the subgraph formed according to the Bonding Curve.
- tax on the deposit that is incinerated
Thus, curators should be very careful when choosing a subgraph: in the end, they may end up with less GRT than they had with the deposit.
Delegators: users who delegate GRT tokens to indexers in exchange for a commission. It is worth noting that unlike other protocols, the indexer and delegator rewards are combined. Therefore, the Reward Cut of some indexers may nominally be higher than that of others, but in fact, they will be equal or even lower. Delegators are also encouraged to make rational decisions when choosing an indexer (they have a 0.5% fee on entry, which is also burned).
Many people may have a question, what is the incentive for developers to create subgraphs? No developers — no subgraphs — no income.
Since developers can be both indexers and curators, in case they have incentives to build a subgraph and be an early curator / indexer in it, thereby earning a reward.
Comparison with other services
After Graph has shown the “blue ocean” of the blockchain query market, it will be interesting to watch services from competitors. We looked at the most noticeable ones at the moment:
- Is a centralized service
- A limited set of data that can be taken from the blockchain
- Supports over 40 blockchains
- QT (company) sets the price per request itself (The Graph — market sets the price for indexers and consumers)
- Is a centralized service
- Provides a limited set of data and a limited number of queries
- The agent sets the price himself
- Currently supports 6 blockchains
Protocol economics
We want to discuss the economics of the protocol and assess the potential for future cash flows. You can read more about the GRT tokenomics and the roles of ecosystem participants in a particular post.
Protocol participants will earn from the two primary sources:
- Query Fees. Consumers are the end-users of The Graph that query subgraphs and pay query fees to the Indexers, Curators and Delegators. Fees to be paid in GRT.
- Indexer rewards: inflationary reward of the new GRT on an annual basis to the indexers of the protocol.
The price in GRT for the query marketplace has not yet been set and will be determined by market participants in a decentralized format.
The Grath in the post about tokenomics describes the pricing in this way:
The price of these queries will be set by Indexers and vary based on cost to index the subgraph, the demand for queries, the amount of curation signal and the market rate for blockchain queries. Since Consumers (ie. applications) are paying for queries, the aggregate cost is expected to be much lower than the costs of running a server and database.
We readily believe that the cost of using the Graph will be lower than working on your infrastructure. Our goal is to try to understand the potential of the Graph cash flows based on the number of requests and the average price per request in the market.
Recently, Graph has shown a growing trend in the number of requests. Today it is already about 350 million requests per day or about 10 billion per month. Let’s estimate the potential earnings. We have taken approximate figures from RapidAPI. If we have time, we will add pricing of one of the leaders of financial API marketplaces — Xignite (requested by mail).
Assuming 350M queries per day and the average cost per request in our super little sample it’s roughly around $13.8M of yearly earning of the protocol. We can make a lot of assumptions here to make our data looks good, but it’s not the case of our simple exercises here. The protocol has an understandable business model and projected cash flows. More and more DeFi projects are showing or seeking to establish profits: in a recent Yearn Quarterly Report project showed Net Income (not audited) of $3.8M for the Period Aug-Oct. Good to see that Graph complements the DeFi and Web3 ecosystem with a well-developed economic model, where all participants (Indexers, Curators and Delegators) are interested in the development of the ecosystem.
We’re looking forward to the launch of query market and price establishment for the query fees price.
Summary
Summing up, it should be noted that the full launch of the Graph Protocol is a new era in the development of Web 3.0. Applications, or rather their interfaces, are becoming less dependent on centralized services.
We are looking forward to launching query markets, which will allow us to predict the potential revenue of the protocol more accurately, as the trend for the growth of queries can also be caused by the fact that they are subsidized by the team (the team maintains the infrastructure).
The report was prepared in collaboration with Nikita
