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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active user of The Graph protocol. The metric is calculated by dividing total daily revenue by the number of daily active users. This provides insight into monetization efficiency and revenue concentration across The Graph's decentralized data indexing network. The calculation tracks users across four distinct roles (Delegators, Curators, Disputors, and Queriers) and captures revenue from multiple fee streams within the protocol ecosystem.

## 2. Data sources

The ARPU calculation relies on the following raw blockchain data sources:

- **Smart contract events**: Parsed events from The Graph protocol contracts across Ethereum, Arbitrum, and Polygon networks
- **Staking events**: `StakeDelegated` events from staking contracts on Ethereum and Arbitrum
- **Curation events**: `Signalled` events from curation contracts on Ethereum and Arbitrum  
- **Dispute events**: `DisputeAccepted` and `DisputeRejected` events from dispute manager contracts on Ethereum and Arbitrum
- **Slashing events**: `StakeSlashed` events from staking contracts on Ethereum and Arbitrum
- **Billing events**: `TokensPulled` events from billing contracts on Arbitrum and Polygon
- **Token transfer data**: GRT token transfer events showing burns to null addresses during delegation
- **Price data**: End-of-day GRT token price feeds for USD conversion
- **Token metadata**: GRT token contract details including decimal places for proper conversion

## 3. Step-by-step calculation

### Component A: Daily active user identification

- **Purpose**: Identifies and counts unique users interacting with The Graph protocol daily
- **Logic**: Tracks user addresses across four distinct interaction types on Ethereum, Arbitrum, and Polygon. Delegators are identified from `StakeDelegated` events using the `delegator` field. Curators are captured from `Signalled` events using the `curator` field. Disputors are identified from both `DisputeAccepted` and `DisputeRejected` events using the `fisherman` field. Queriers are tracked through `TokensPulled` billing events using the `user` field. Each interaction creates a daily user record with the user address, interaction timestamp, chain, and user type classification.
- **Key fields**: `block_timestamp` for daily aggregation, `user_address` for unique user identification, `user_type` for classification, `chain` for network tracking

### Component B: User aggregation with HyperLogLog

- **Purpose**: Aggregates unique daily users while handling overlaps between user types and chains
- **Logic**: Uses HyperLogLog sketches to count distinct user addresses per day, accounting for users who may interact in multiple capacities or across multiple chains. Creates breakdowns by total project users, by individual chain, by user type, and by product. The HyperLogLog approach ensures accurate deduplication when the same address appears in multiple interaction categories on the same day.
- **Key fields**: `timestamp` truncated to day boundaries, `user_dau` containing HyperLogLog sketch data, dimension fields for different aggregation levels

### Component C: Query fee calculation

- **Purpose**: Captures revenue from data query billing on Arbitrum and Polygon networks
- **Logic**: Extracts query fees from `TokensPulled` billing events where users pay for data queries. Uses the `amount` field from billing events as the fee amount in GRT tokens. Excludes transactions on the migration date (2022-12-13) when user balances were transferred to Arbitrum, then manually adds the migration date query fees totaling 44,191.57 GRT. Associates fees with billing contract addresses and timestamps.
- **Key fields**: `amount` containing GRT fee amounts, `token_address` for GRT contract identification, `action_type` set to "Querying"

### Component D: Curation fee calculation  

- **Purpose**: Captures revenue from curation tax on signal deposits
- **Logic**: Extracts curation taxes from `Signalled` events on Ethereum and Arbitrum where curators signal on subgraphs. Uses the `curationTax` field from signaling events as the tax amount in GRT tokens. Only includes events where `removed` is false to exclude reversed transactions. Associates fees with the curation contract address and the curator's action timestamp.
- **Key fields**: `curationTax` containing GRT tax amounts, `token_address` for GRT contract identification, `action_type` set to "Curation taxes"

### Component E: Delegation fee calculation

- **Purpose**: Captures revenue from delegation taxes during stake delegation
- **Logic**: Identifies delegation tax by matching `StakeDelegated` events with corresponding GRT token burns to null addresses in the same transaction. First collects all delegation events with delegated token amounts. Then identifies GRT transfers to burn addresses (null address or dead address) from the same delegator addresses within delegation transactions. Matches delegation events with token burns using transaction hash and action sequence to determine the tax amount burned during delegation.
- **Key fields**: `tokens` from delegation events, `value` from burn transfers, matching on `transaction_hash` and action sequence, `action_type` set to "Delegation taxes"

### Component F: Dispute fee calculation

- **Purpose**: Captures revenue from dispute resolution through slashing and rejected dispute deposits
- **Logic**: Handles two dispute fee types differently. For accepted disputes (slashing), matches `DisputeAccepted` events with `StakeSlashed` events in the same transaction, calculating the net slashing amount as slashed tokens minus rewards paid to disputors. For rejected disputes, uses the full deposit amount from `DisputeRejected` events as protocol revenue. Matches events using transaction hash, indexer address, and disputor address to ensure proper association.
- **Key fields**: `tokens` from dispute events, `slashed_amount` and `reward_amount` from slashing events, `deposit_amount` from rejected disputes

### Component G: Revenue aggregation and conversion

- **Purpose**: Combines all fee streams, converts to USD, and aggregates by day
- **Logic**: Unions query fees, curation fees, delegation fees, and dispute fees into a single revenue stream. Truncates timestamps to daily boundaries for aggregation. Applies decimal correction for GRT tokens (18 decimals) and converts amounts to USD using end-of-day GRT price feeds. Aggregates total revenue per day across all fee types and chains. Fills missing days with zero revenue values to maintain continuous time series.
- **Key fields**: `revenue` containing USD-converted daily totals, `timestamp` at daily granularity, dimension fields for breakdowns

### Final aggregation

- **Combining components**: Daily revenue totals are matched with daily active user counts by date. Both components use the same daily timestamp boundaries to ensure proper alignment. The user counts represent unique addresses interacting with the protocol, while revenue represents the sum of all fees generated on that day.
- **Currency conversion**: All GRT-denominated fees are converted to USD using end-of-day price feeds applied at the daily aggregation level. Token amounts are corrected for 18-decimal precision before conversion.
- **Time aggregation**: Both user and revenue data use daily boundaries created by truncating blockchain event timestamps to the day level in UTC.
- **Final calculation**: ARPU is calculated by dividing the total daily revenue (in USD) by the count of daily active users for each day. Days with zero users receive zero ARPU values. The result represents the average revenue generated per user on each given day across The Graph protocol.

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

The GraphGRT

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape