The Graph (GRT): What The Graph Does and Who Uses GRT

From blockchain events to queryable data

A subgraph defines which contracts and events to follow and how their data should be transformed into a queryable schema. Indexers run infrastructure that ingests the relevant chains, executes mappings and serves queries. Applications can request structured results instead of scanning raw blockchain history themselves.

Indexing does not make source-chain data true or complete. A subgraph can lag, contain mapping errors or omit events by design. Developers should monitor indexing status, chain reorganizations and query errors, then validate high-risk decisions against underlying chain data.

GRT coordinates services

Indexers stake GRT and allocate or provision economic capacity to serve data. Delegators assign GRT to an indexer and data service under Horizon. Curators signal on useful subgraphs. These roles have different reward, lockup and risk profiles; buying GRT alone does not automatically earn query revenue.

Provisions and SubgraphService

An indexer first stakes GRT, then provisions some stake to a particular data service. SubgraphService is the first active service for decentralized subgraph indexing. Allocations are created within that service, and Proofs of Indexing support reward collection and accountability.

This means generic staked GRT is not automatically active for every service. Operators must configure current Horizon-compatible software and assign stake correctly. Developers and query users can continue using subgraphs, but infrastructure assumptions and payment paths have changed beneath the interface.

Delegation changes

Delegators now select both an indexer and a data service. The former 0.5% delegation tax was removed under Horizon. Undelegation periods, indexer reward cuts, capacity and performance still matter. Future slashability capabilities should be monitored through current protocol documentation rather than assumed active for every service.

Two assets, different costs

The wallet still needs ETH on Arbitrum One to pay gas.

Query payments and indexing rewards follow protocol mechanisms and service-specific rules. Expected returns depend on indexer behavior, allocations, delegation capacity, reward cuts, query volume and protocol changes. They are not a fixed interest rate and can be reduced by downtime, stale proofs, disputes or unbonding periods.

Proof is not perfect data

Proofs of Indexing establish that an indexer processed a subgraph deployment to a claimed state under protocol rules. They do not guarantee that the subgraph design answers the user intended question or that an upstream contract emitted correct business data.

Query and developer checks

Confirm the subgraph deployment, indexed chain, latest processed block and query endpoint. Handle stale or partial results. For financial actions, compare critical values with source-chain RPC data and do not assume two gateways serve identical indexing state at the same instant.

Delegator and operator checks

Delegators should review the indexer, selected service, reward cuts, capacity, unbonding rules and technical reputation. Indexers must protect keys, run current Horizon software, submit required proofs and understand dispute exposure. Neither role is passive or risk-free.

• Keep ETH for Arbitrum gas.
• Do not use historical delegation-tax assumptions.
• Verify the selected data service.
• Treat displayed rewards as variable protocol outcomes.

Data users and developers

Select the exact subgraph or data service, inspect indexing status and test failure handling. Use the source chain for independent verification when the decision is irreversible.

What The Graph users should verify and why this design differs

Review current Horizon documentation before staking or delegation, then keep ETH on Arbitrum for gas. The Arbitrum page explains the host-chain transaction layer, while the tools directory provides general analysis utilities.