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 Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for The Graph protocol measures the number of unique users who interacted with The Graph's decentralized indexing and querying infrastructure over rolling 30-day periods. This metric captures engagement across different user types (Delegators, Curators, Disputors, and Queriers) and provides breakdowns by blockchain network, user type, and product. The calculation uses HyperLogLog data structures for efficient approximate counting of unique users across large datasets and time windows.

## 2. Data sources

The calculation relies on the following raw blockchain data sources:

- **Ethereum blockchain event logs**: Parsed smart contract events from The Graph v1 protocol on Ethereum, including staking delegation events (`Staking_StakeDelegated`), curation signaling events (`Curation_Signalled`), and dispute resolution events (`DisputeManager_DisputeAccepted`, `DisputeManager_DisputeRejected`)

- **Arbitrum blockchain event logs**: Parsed smart contract events from The Graph v1 protocol on Arbitrum, including billing token pull events (`Billing_TokensPulled`), staking delegation events, curation signaling events, and dispute resolution events

- **Polygon blockchain event logs**: Parsed smart contract events from The Graph v1 protocol on Polygon, specifically billing token pull events for query fee payments

- **Event metadata**: Transaction timestamps, transaction hashes, log indices, and block information associated with each blockchain event

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identifies and classifies all user interactions with The Graph protocol across multiple blockchain networks
- **Logic**: The system processes parsed blockchain events from Ethereum, Arbitrum, and Polygon networks. For each event type, it extracts the relevant user address parameter and assigns a user classification. On Ethereum, `Staking_StakeDelegated` events identify Delegators from the `delegator` parameter, `Curation_Signalled` events identify Curators from the `curator` parameter, and dispute events identify Disputors from the `fisherman` parameter. On Arbitrum, the same event types are processed plus `Billing_TokensPulled` events which identify Queriers from the `user` parameter. On Polygon, only billing events are processed to identify Queriers. Each interaction record includes the blockchain network, transaction timestamp, and user type classification.
- **Key fields**: `block_timestamp` for timing, `user_address` for user identification, `chain` for network classification, `user_type` for role classification (Delegator, Curator, Disputor, or Querier)

### Component B: Daily active users aggregation
- **Purpose**: Aggregates user interactions into daily unique user counts while maintaining dimensional breakdowns
- **Logic**: The system processes all identified user interactions and truncates timestamps to daily granularity using timestamp truncation. For each day, it identifies unique user addresses by chain, user type, and product. The deduplication ensures that if a user performs multiple interactions of the same type on the same day, they are only counted once. Chain availability filters are applied to ensure data quality and completeness. The result is a daily table where each row represents a unique user's activity on a specific day with their associated dimensions.
- **Key fields**: `timestamp` (daily truncated), `chain`, `user_type`, `product_id`, `user_dau` (unique user address)

### Component C: HyperLogLog conversion for efficient counting
- **Purpose**: Converts daily user sets into HyperLogLog sketches for memory-efficient approximate distinct counting across time windows
- **Logic**: The system takes the daily active user records and initializes HyperLogLog sketches for each combination of day, chain, user type, and product. HyperLogLog is a probabilistic data structure that provides approximate distinct counts with high accuracy while using minimal memory. This conversion is essential for efficiently calculating rolling window metrics without storing or processing massive amounts of duplicate user data across overlapping time periods.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for each day to support MAU calculation
- **Logic**: The system generates a complete datespine covering all days from the earliest DAU record to the most recent complete day. For each day in the datespine, it creates a 30-day lookback window by generating an array of the 30 days ending on that date (including the target date itself). This creates a cross-join structure where each target date is associated with all days in its 30-day window. The system then joins this window structure with the daily HLL sketches to create a comprehensive dataset where each row represents one day's contribution to a specific target date's 30-day window.
- **Key fields**: `timestamp` (target date), `joinday` (contributing day within the window), dimensional fields from HLL sketches

### Component E: MAU calculation by dimension
- **Purpose**: Calculates unique user counts over 30-day windows for different analytical dimensions
- **Logic**: The system processes the rolling window data by merging HyperLogLog sketches across each 30-day period. For each target date and dimensional combination, it uses HLL merge operations to combine all contributing daily sketches, then extracts the final approximate distinct count. The calculation produces separate breakdowns: project-level MAU (aggregated across all dimensions), chain-level MAU (unique users per blockchain network), user-type-level MAU (unique users per role), and product-level MAU (unique users per product). Each breakdown aggregates the appropriate dimensions while preserving others as null values for consistent schema structure.
- **Key fields**: `user_mau` (30-day unique user count), `dimensions` (breakdown type), dimension-specific fields (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: The different dimensional breakdowns (project-level, chain-level, user-type-level, and product-level) are combined using UNION ALL operations to create a single comprehensive dataset with consistent schema structure
- **Time aggregation**: Each MAU value represents a rolling 30-day window ending on the specified date, providing daily MAU measurements that capture monthly engagement patterns
- **Final calculation**: The system applies the `finalize_metric_user_mau` macro to standardize the output format, including filling missing days with zeros where appropriate and ensuring consistent metadata fields across all records. The final metric value in the `user_mau` field represents the approximate count of unique users who were active within the 30-day period ending on each date

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

Unique revenue-generating users over a rolling 30-day window.

The GraphGRT

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown