The Graph provides blockchain data and receives query fees from demand-side users. Supply-side users also pay fees for delegating to a node, curating subgraphs, disputes and when slashing occurs (revenue). Indexers, delegators and curators perform indexing services for which they are compensated by The Graph (expenses).

The Graph is an indexing protocol built on Ethereum and other blockchains. The Graph was founded by Brandon Ramirez, Jannis Pohlmann, Yaniv Tal and launched in 2018.

GRT tokenholders own and govern the protocol. They currently take all of the total fees (revenue). The Graph’s investors include Multicoin Capital, Coinbase Ventures, Framework ventures, etc.

governance

github

twitter

discord

etherscan

website

Infrastructure

The Graph

# The Graph Revenue Methodology

## 1. Overview

The Graph revenue represents the total protocol fees collected across The Graph network's decentralized indexing and querying infrastructure. This metric captures revenue from four primary sources: query fees paid by API consumers, curation taxes from subgraph signaling, delegation taxes from staking activities, and dispute resolution fees. The calculation aggregates these revenue streams across Ethereum, Arbitrum, and Polygon networks on a daily basis, converted to USD values.

## 2. Data sources

- **Smart contract events**: Parsed events from The Graph protocol contracts including billing events (`Billing_TokensPulled_event`), curation signals (`Curation_Signalled_event`), delegation stakes (`Staking_StakeDelegated_event`), and dispute resolution events (`DisputeManager_DisputeAccepted_event`, `DisputeManager_DisputeRejected_event`, `Staking_StakeSlashed_event`)
- **Token transfer data**: GRT token transfer records from Ethereum and Arbitrum to track fee burns and payments
- **External data**: End-of-day price feeds for GRT token USD conversion and token metadata for decimal precision handling
- **Blockchain networks**: Event logs and transaction data from Ethereum, Arbitrum, and Polygon networks

## 3. Step-by-step calculation

### Component A: Query fees
- **Purpose**: Captures revenue from API query usage fees
- **Logic**: Extracts billing events where GRT tokens are pulled from user accounts when they pay for GraphQL API queries. Includes data from Arbitrum and Polygon networks. Special handling for the migration date (2022-12-13) where Polygon fees are excluded from normal extraction and a manual adjustment of 44,191.57 GRT is added to account for the balance migration to Arbitrum
- **Key fields**: Uses `amount` field from billing events, with `account_address` identifying the billing contract and `token_address` specifying the GRT token contract

### Component B: Curation fees  
- **Purpose**: Captures protocol taxes from subgraph curation activities
- **Logic**: Extracts curation tax amounts from signaling events when curators stake GRT tokens to signal the quality and relevance of subgraphs. Data sourced from Ethereum and Arbitrum curation contracts
- **Key fields**: Uses `curationTax` field from curation signaling events, representing the protocol fee portion of curation stakes

### Component C: Delegation fees
- **Purpose**: Captures protocol taxes from delegation staking activities  
- **Logic**: Employs a two-step matching process: first identifies delegation events where users stake GRT with indexers, then matches these with corresponding GRT token burns to null addresses (`0x0000000000000000000000000000000000000000`) or dead addresses (`0x000000000000000000000000000000000000dead`) within the same transactions. The burned token amount represents the delegation tax collected by the protocol
- **Key fields**: Matches delegation events by `transaction_hash` and action sequence with token burns, using the burned `amount` as the fee value

### Component D: Dispute fees
- **Purpose**: Captures revenue from dispute resolution mechanisms
- **Logic**: Combines two types of dispute-related fees: For accepted disputes (slashing), calculates protocol fee as the difference between `slashed_amount` and `reward_amount` from matched dispute and slashing events. For rejected disputes, uses the full `deposit_amount` forfeited by unsuccessful challengers. Matching occurs by transaction hash, indexer address, and user address
- **Key fields**: Uses `slashed_amount` minus `reward_amount` for accepted disputes, and `deposit_amount` for rejected disputes

### Final aggregation  
- **Combining components**: All four revenue components are combined using union operations, with each maintaining consistent daily timestamp truncation and business line classifications
- **Currency conversion**: GRT token amounts are converted to USD using end-of-day price feeds, with automatic correction for the token's 18-decimal precision
- **Time aggregation**: All revenues are aggregated to daily boundaries using timestamp truncation, with a zero-filling strategy to ensure complete time series coverage
- **Final calculation**: The final revenue value represents the sum of all protocol fees across query usage, curation activities, delegation taxes, and dispute resolutions, standardized as daily USD amounts with proper business line categorization as "Data Provider" infrastructure revenue

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

The GraphGRT

Revenue

Revenue

Competitive landscape

Chain breakdown