Disclaimer: This report has been produced through a collaborative process between the parties involved. The content of this report is intended solely for providing information and reflects the opinions of the author. It is not intended for the purpose of buying or selling tokens or recommending the use of any protocol. None of the content included in this report should be construed as investment advice, nor should it be interpreted as such.
1. Issues with Blockchain Data Indexing Solutions
Blockchain, from a technical standpoint, can be viewed as a decentralized database. In pursuit of decentralization, blockchain databases support only fundamental functionalities based on key-based read and write operations. These limitations lead to inconveniences for both blockchain-based dApps and users.
One of the causes of this inconvenience lies in the indexing method used in blockchain databases. Indexing involves optimizing data within a database into structured forms, allowing for swift retrieval of requested information.
Most databases used in Web2 environments support various indexing structures, making it easy to fetch the necessary data and present it to users. In contrast, blockchain databases only store transaction data and contract state and do not efficiently provide the information required by dApps. As a result, dApp developers often face the cumbersome task of further processing blockchain data to meet their needs. Let's illustrate this issue with an example.
1.1. Example: How is Liquidity Information in Uniswap V3 Handled?
Consider a user who wants to supply liquidity to Uniswap V3. One critical factor they need to consider is the size of the liquidity pool they intend to contribute to. If a pool has low liquidity, there will be fewer swaps in that pool, resulting in lower fee earnings.
Uniswap currently provides liquidity information for each pool on its website. However, the blockchain database does not offer direct indexing for this information. So, how does Uniswap retrieve and process this data?
Liquidity pools in Uniswap V3 are in a concentrated liquidity form. To determine the total liquidity, one must aggregate liquidity information available in small segments based on price. However, Uniswap does not track the entire liquidity of a pool within its contract. The "liquidity" function in the code snippet below refers to the liquidity existing around the current price tick, making it impossible to obtain complete liquidity information using this data.
Two possible solutions come to mind.
- First, record the total liquidity information of each pool in a separate database and update it whenever swaps, liquidity provisions, or withdrawals occur. However, this approach involves tracking a vast amount of liquidity pool data in the backend, incurring significant costs.
- Second, use centralized third-party solutions that provide blockchain data. While these solutions are fast and cost-effective, they come with the drawback of relying on third parties, which may compromise data accuracy and face potential disruptions due to single points of failure.
In summary, the required data in Uniswap is not directly indexed in the blockchain database, necessitating additional off-chain indexing processes. However, the approaches mentioned earlier both present challenges, including "high cost" and "single-point-of-failure issues."
1.2. The Graph's Mechanism
The Graph emerges as a solution to these issues, providing a blockchain data service that ensures accurate and secure data retrieval through a decentralized network. The Graph establishes an open data marketplace for blockchains, featuring subgraphs that define what data to index and indexers that process and store blockchain data on-demand.
Let's delve into how The Graph works through the example of Uniswap V3.
- Uniswap creates a subgraph to track liquidity information within V3 pools. A subgraph acts as a "code snippet" that collects and processes event information occurring within blockchain smart contracts.The following steps illustrate how liquidity information in a pool is tracked:
- Reading events generated during pool creation and adding information to the database.
- Capturing specified events and updating pool information when they occur. For instance, when 10 ETH is added to pool A, the liquidity of pool A increases by 10 ETH.
- Providing organized information from the database through API endpoints.
- Uniswap requests indexing for this subgraph. Indexers then start the process of collecting and processing liquidity information according to the instructions in the subgraph. Indexers store this information in a separate database and create endpoints for data retrieval.
- Once this process continues until the current block, and indexing is completed, Uniswap can receive information through the API provided by the indexer for the subgraph. Additionally, the indexer can receive GRT fees each time Uniswap sends a query, in addition to the GRT rewards provided through protocol inflation.
1.3. Issues Arising from Centralized Data Platforms
If you read this far, The Graph might look similar to that of a typical third-party data platform. Therefore, certain concerns may arise:
- Can data accuracy be guaranteed?
If indexers were to provide incorrect data or if indexer performance were subpar, dApps relying on those indexers could suffer losses. Therefore, with centralized data providers, dApps must place their trust in the provider. - Can useful subgraphs be incentivized?
Conversely, indexers must also trust dApps. Indexers usually follow block events from a few years back to create databases for subgraphs, a resource-intensive task. If a dApp were to write useless subgraphs, indexers would waste computing resources without gaining any query volume. This situation, if prolonged, could render indexers incapable of performing their tasks.
The Graph addresses these trust-related issues through specific mechanisms.
2. Ensuring Fast and Secure Data Retrieval: The Graph's Approach
2.1. GRT Utility and Participants
The Graph operates its protocol centered around GRT, a utility token compliant with the ERC-20 standard, which serves the following functions:
- Staking: Indexers stake GRT to provide indexing and query services.
- Delegation: Delegators allocate their GRT to existing Indexers to earn a portion of the query fees and indexing rewards.
- Payment: Consumers (developers) pay GRT to Indexers, Curators, and Delegators for subgraph queries.
- Reward: Indexers and Delegators receive indexing rewards in GRT.
Ecosystem participants revolve around GRT, which holds the aforementioned utilities, with each participant playing distinct roles as follows:
- Developer: Participants who act as consumers within The Graph network. They create and deploy subgraphs to The Graph network, requesting indexing. They use the processed data from The Graph network and pay for it with GRT.
- Indexer: Indexers are node operators in The Graph network, providing indexing and query processing services. To become an indexer, a certain amount of GRT must be staked (currently 100,000), and indexers choose subgraphs to index based on the curation signals from Curators.
- Curator: Curators assess the quality of subgraphs and select those that should be indexed.
- Delegator: Delegators are network participants who delegate their GRT to indexers. They contribute to network security by increasing the stake of GRT in the network and sharing in the protocol revenue received by the indexer they delegate to.
Within The Graph network, GRT plays a role in generating signals to select good subgraphs and outstanding indexers, while the revenue and added value generated from them are distributed as GRT rewards to ecosystem participants. This decentralized data marketplace formed by The Graph digests the data indexing demands of dApps and others, with costs also billed in GRT.
Thus, The Graph network provides safe and high-quality data indexing services centered around its tokenomics of GRT. I will further examine the roles and functions of Indexers, Curators, and Delegators, the network participants, to gain a detailed understanding of the network mechanism.
2.2. Indexer
As previously mentioned, an indexer in The Graph network is a node operator who selects and indexes subgraphs based on Curator signals. Currently, a minimum of 100,000 GRT must be staked to act as an indexer, and this stake serves as a form of deposit, which can be slashed if the indexer acts maliciously.
Indexers receive rewards for indexing in the form of about 3% of protocol inflation (FY2023: 2.7%) and GRT fees for the queries they process. To receive the protocol inflation, indexers generate a Proof of Indexing (POI) as evidence that they are indexing properly.
To prevent indexers from generating POI despite returning incorrect data or not indexing, The Graph implements a dispute system. Anyone in the network can dispute the data returned by an indexer for a query within 7 epochs (7 days) and the indexer’s POI within 28 epochs (28 days). The person initiating the dispute is known as a Fisherman. The dispute process follows these steps:
- Fisherman submits a dispute over an incorrect query or POI, locking up 10,000 GRT.
- If it turns out that the indexer did nothing wrong, the Fisherman’s locked GRT is completely burned.
- If the indexer is found to be at fault, they are slashed, and the Fisherman is entitled to half of the slashed GRT.
This mechanism is very similar to the challenge system used in Optimistic Rollup, assuming the indexer’s correct behavior and adopting an optimistic approach.
2.3. Curator
(Note: The Graph ecosystem is actively working on reforming the Curation mechanism. Please follow the forum posts for the latest updates.)
Since anyone can create a subgraph without restrictions, there is a potential risk of useless subgraph creation, which could harm indexers. To overcome this flaw and establish a trustless environment between dApps and indexers, The Graph network introduced an additional type of participant: the Curator.
Curators evaluate the quality of subgraphs and transmit their assessment as a signal to indexers. The quality of a subgraph is deemed higher when it meets the following criteria:
- Subgraphs with a high frequency of queries (generating significant income).
- Subgraphs that do not encounter errors during database formation (no code errors).
- Subgraphs officially created by the protocol.
Once a subgraph is deployed in the network, curators assess these factors and signal GRT on good subgraphs. This process is referred to as "signaling.” By doing so, curators play a crucial role in guiding indexers to valuable and reliable subgraphs, ensuring the overall integrity and efficiency of The Graph network.
The amount of signals sent, that is, the extent of GRT staked on a specific subgraph, enables indexers to determine which subgraphs to index, thus identifying and incentivizing useful subgraphs. Additionally, two mechanisms are in place within the network to encourage curators to quickly and accurately verify subgraphs:
- GRT Incentives:
- Curators receive 10% (subject to change through governance) of the query fees generated from the subgraph they curate as a reward. Each curator's reward is proportional to their share of the subgraph.
- If a subgraph encounters issues and needs to be redeployed, a migration fee is deducted from the GRT staked by the curator.
- These factors motivate curators to stake GRT and send signals to subgraphs that generate many queries and have no quality issues.
- Graph Curation Shares:
- When a curator stakes GRT to send a signal, they receive shares in that subgraph, represented as Graph Curation Shares (GCS), an ERC-20 token.
- Since The Graph protocol currently exists on both L1 (Ethereum) and L2 (Arbitrum), the curation mechanism works differently on these two layers.
- On L1, the price of GCS increases proportionally to the amount of GRT staked on the respective subgraph, and this price graph is implemented using Bancor's bonding curve.
- On L2, the bonding curve is flat (in other words, there is no exponential increase in share price).
- While there is no slashing risk for curators, a 1% deposit fee is charged when staking GRT to discourage improper evaluation of subgraphs.
- Curators can burn their GCS to reclaim GRT, with the amount of GRT returned determined by the position on the bonding curve.
Through these mechanisms, curators are incentivized to quickly identify and staking on high-quality subgraphs. This also incentivizes the creation of useful subgraphs, thereby contributing to a trustless environment between dApps and indexers. These measures ensure efficient and reliable resource allocation within the network.
2.4. Delegators
Delegators are network participants who delegate their GRT to indexers, contributing to network security without directly operating a Graph node. This system, resembling a Delegated Proof of Stake (DPoS) structure, allows individuals who do not operate nodes to delegate their GRT to indexers and earn a portion of query fees and rewards. This setup enables ordinary users without specialized knowledge in indexing to participate as delegators and generate income through the Graph network.
The amount of queries an indexer can process is proportional to the total of their own staked GRT and the GRT delegated to them. Furthermore, multiple indexers can index the same subgraph. Through the rebate mechanism, indexers are incentivized to hold stake and delegation proportionally to the amount of queries they intend to serve.
2.4.1. How to Delegate
You can become a delegator by following these simple steps to delegate your GRT to an indexer:
- Access the Graph Explorer, the official explorer of The Graph, under the Participants tab (link).
- Click the ‘Connect’ button to link your wallet, such as MetaMask (image part ①).
- Find the indexer you want to delegate your GRT to and click the ‘Delegate’ button to proceed with the delegation (image parts ② and ③).
While delegating GRT does not involve slashing risk for delegators in the current protocol setup, be aware that a 0.5% tax is applied at the time of delegation, and there is a 28-day undelegation period to withdraw the delegated tokens.
2.4.2. How to Choose Indexers
The profitability for delegators who delegate their GRT to a specific indexer is determined by the parameters set by that indexer. Therefore, it is important to thoughtfully evaluate and select indexers who not only offer promising profitability but also demonstrate stability. In this context, let's identify the key factors that should guide the decision-making process when choosing indexers for delegating GRT.
The above image, as of January 16th, shows the dashboard of p2p.org's indexer, which has the largest GRT staking volume on the Arbitrum chain. Key areas of this dashboard to pay attention to have been marked as ①, ②, and ③.
[ ① Stake ]
In area ①, which shows the staking status, each indicator means the following:
- Owned: The amount of GRT the indexer has staked themselves. A minimum of 100,000 GRT is required for active indexing.
- Delegated: The amount of GRT delegated to the indexer by delegators.
- Allocated/Unallocated: Indicates how much of the indexer's GRT stake is allocated to subgraphs.
- Chart: Shows the trend of GRT staking volume.
In the example, the indexer has directly staked 29.1M GRT and received 270.4M GRT in delegation. Out of a total of 299.5M GRT, 298.23M is allocated to subgraphs for revenue generation, and 1.28M remains unallocated.
[ ② Delegation ]
Area ② can be divided into the "Delegation" section, showing the delegation status, and the "Delegation parameters" section, important for assessing profitability. The meanings of the indicators in the Delegation section are:
- Delegation Received: The amount of GRT already delegated to the indexer.
- Max Capacity: The maximum amount of GRT the indexer can manage. Currently, indexers can manage up to 16 times the GRT they have staked (Owned).
- Delegation Available: The amount of additional GRT the indexer can currently receive in delegation.
The formula:
(Max Capacity) - (Delegation Received) = (Delegation Available)
applies here. The 'Delegation Available' figure can be negative, indicating over-delegation beyond the indexer's capacity. This situation can negatively impact profitability, as it often results in a portion of the delegated GRT not being allocated for indexing.
The meanings of the indicators in the Delegation parameters are:
- Indexing Reward Cut: This represents the portion of the rewards that the Indexer receives
- Query Fee Cut: This is the proportion of the query fee rebates that the indexer receives
- Cooldown Remaining (being deprecated): This indicates the remaining time before the indexer can change their delegation parameters again. They must wait for a specified period after any modification, and can only make changes once the Cooldown Remaining hits “0 Days.”
- Effective Reward Cut: The percentage of indexing rewards generated by delegated GRT that the indexer takes. If this indicator is negative, it is equivalent to the indexer providing incentives to the delegators.
For example, if the daily indexing reward is 100 GRT, and the indexer's stake is 200 GRT with 800 GRT delegated (a 2:8 ratio), then 20 GRT of the reward is generated by the indexer's stake, and 80 GRT by the delegated stake. If the Indexing Reward Cut is set at 10%, the indexer actually receives 10 GRT, and the remaining 90 GRT goes to delegators.
Delegators receive more than the rewards generated by their stake; in this case, it's 112.5% (90/80), or an extra 12.5%. From the indexer's perspective, they are giving away 12.5% of the rewards generated by the delegated stake, so the "Effective Reward Cut" is -12.5%.
Thus, if the Effective Reward Cut is positive, the indexer takes some rewards generated by the delegated stake, and if negative, the indexer is paying a portion of the rewards generated by their own stake as incentives to delegators. For a more detailed explanation, please refer to The Graph Academy's related explanation.
In the example, the indexer takes 89% of the total query fees and 20% of the total indexing rewards, indicating that they are taking 11.39% of the rewards generated by the delegated GRT stake.
[ ③ Income ]
Area ③ covers the rewards earned by the indexer. Each indicator represents the following:
- Indexing Rewards: The amount of GRT the indexer receives from the total indexing rewards.
- Delegator Rewards: The amount of GRT delegators receive from the total indexing rewards.
- Indexing Rewards (Bold): The total amount of indexing rewards.
- Indexer Query Fees: The amount of GRT the indexer receives from the total query fees.
- Delegator Query Fees: The amount of GRT delegators receive from the total query fees.
- Query Fees: The total amount of query fee rewards.
From the example, the indexer has received a total of 9.65M GRT in indexing rewards and 1.21K GRT in query fee rewards, amounting to a total reward of 9.7M GRT.
Graph Explorer provides an overall view of these indicators and shows the Estimated APR (Annual Percentage Rate) for users when delegating GRT. Although this APR is based on indexing rewards and excludes query fee rewards, it's a reliable indicator considering that most rewards in The Graph network come from indexing. However, it's important to note that this indicator is based on daily data and subject to fluctuation. Therefore, it's advisable to choose an indexer by considering various factors such as the total stake size and delegation ratio of the indexer, among others.
3. The Graph Growth Metrics
3.1. Overview
A primary use case of The Graph is providing metrics for decentralized applications (dApps) to users. For instance, when information about the liquidity of Uniswap V3 pools is needed, calls are made to subgraphs deployed on The Graph to retrieve this data.
Notable dApps that have deployed subgraphs on The Graph include Vela Exchange, Ether.fi, Snapshot, Dolomite and so on. Here's a brief description of them.
- Vela Exchange: A decentralized perpetuals trading platform that uses The Graph for indexing and query data about trade activities like open interests, deposits, withdrawals and so on.
- Ether.fi: A decentralized liquid staking platform that uses The Graph for tracking events from protocol’s contract and making them queryable.
- Snapshot: A decentralized voting and governance tool that uses The Graph for accessing voting data and proposals.
- Dolomite: A decentralized money market and DEX protocol that uses The Graph for indexing the state of the protocol.
The Graph's services are also utilized by various dashboards, with a significant example being DefiLlama, a prominent DeFi dashboard service. Many dApps provide their TVL/volume information in subgraph form to DefiLlama.
The Graph has established itself as a reliable data indexing platform based on such technology. To date, it has successfully handled over one trillion queries. As of January 2024, approximately 1,700 subgraphs are actively generating queries on the platform. This ongoing engagement and utilization highlight The Graph's significant role in the decentralized ecosystem, providing essential data services to a wide range of applications and platforms.
The number of delegations in The Graph has seen a significant increase starting from the third quarter of 2023. According to a tweet from The Graph, this surge is largely attributed to a GRT delegation campaign conducted through Coinbase Wallet. This campaign successfully integrated over 30,000 new delegators into The Graph network. The fact that the total number of weekly delegations on the network has maintained a certain level even after the campaign suggests a meaningful increase in the number of network participants. This growth trend can be observed in more detail in The Graph Quarterly Reports Q3 2023 published by Messari.
While Curators saw a moderate growth of 5%, the number of Delegators jumped by 247% in Q3’23. This increase in the number of Delegators from 11,500 in Q2’23 to nearly 40,000 in Q3’23 was driven by a Coinbase Earn campaign. Before the end of Q3'23, approximately 25,000 new Delegators originated from participation in the Coinbase Earn campaign. These new participants added ~6.2 million GRT in delegation through the end of Q3’23 and were paid out ~4.3 million GRT through the campaign. While there were 114 Delegators on Arbitrum in Q2’23, Q3’23 saw a massive increase to over 28,000 Delegators on Arbitrum, with a total stake of over 800 million GRT. Simultaneously, Delegators on Ethereum remained stable at 11,500 in Q3’23, with a total stake of 1.1 billion GRT. — “Mihai Grigore, The Graph Quarterly Reports Q3 2023, Messari”
3.2. Expansion to Arbitrum
Originally based on the Ethereum network, The Graph faced challenges due to increased network congestion and surging transaction fees, which could lead to inefficiencies in The Graph network. To address these issues, The Graph initiated an expansion to Arbitrum, a Layer 2 scaling solution for Ethereum. In April 2023, The Graph allocated 5% of the network's indexing rewards to the Arbitrum chain (related tweet).
Subsequently, a proposal GIP-0052 was made to increase the portion of indexing rewards allocated to the Arbitrum chain to up to 95% (it will eventually move to 100%). This proposal was discussed within the community and went through three rounds of governance council votes, resulting in a phased increase in the allocation of indexing rewards to the Arbitrum chain. This strategic move aimed to leverage Arbitrum's efficient and cost-effective transaction processing capabilities, thereby enhancing the overall functionality and performance of The Graph network.
- Details of GIP-0052
- GGP-0029: Increase L2 Rewards to 25%
- GGP-0030: Increase L2 Rewards to 50%
- GGP-0033: Increase L2 rewards to 95%
The aforementioned allocation of indexing rewards to Arbitrum was implemented at intervals. In September 2023, the allocation was adjusted to 25% and 50%, and in December 2023, following a council vote, it further increased to 95%. As can be seen from the provided graph, the indexing rewards distributed to delegators on the Arbitrum chain began to increase significantly starting from September, showing a continuing upward trend. This has led to a considerable number of indexers, curators, and delegators migrating to the Arbitrum chain. As of now, the distribution of network participation between Ethereum and Arbitrum within The Graph network is illustrated in the following table.
4. In Conclusion
The Graph is a decentralized network protocol consisting of indexers, curators, and delegators, enabling the secure and accurate retrieval of blockchain data. It has established itself as the primary resource for decentralized applications (dApps) requiring data indexing, successfully processing over one trillion queries. Furthermore, it has positioned itself as a leading data infrastructure protocol in the blockchain ecosystem, demonstrating stability while continuously evolving to enhance scalability
With the recent trend towards modular chain launches, there's been a surge in the emergence of new networks and blockchain products. This naturally leads to an expectation of increased demand for the data indexing services provided by The Graph.
In response to evolving circumstances and with the aim of offering higher performance indexing services while expanding accessibility to blockchain data, The Graph unveiled its latest roadmap in November 2023, following last year's expansion to Arbitrum. This announcement has sparked interest in the community, raising questions about the details of The Graph's new direction. Our forthcoming article will provide an in-depth look at this roadmap and discuss its potential implications for the future of The Graph.
<References>
- The Graph Docs
- Graph Explorer
- Juan Defago, Evaluating an Indexers Effective Cut, The Graph Academy
- Mannan Inandar, The Graph Ecosystem Overview
- Mihai Grigore, The Graph Quarterly Reports Q3 2023, Messari
- Pablo, GIP-0052
- pcarranzav, gips/0052-timeline-and-requirements-for-l2-rewards.md
- The Graph Council snapshot
- Realchoubey, Graph Network - Revenue Dashboard
- The Graph tweet
