Validators process transactions and receive transactions fees (supply-side fees).

Injective is a smart contract platform for decentralized finance applications (a blockchain) and an orderbook exchange protocol. Injective was founded by Eric Chen, Albert Chon etc. and launched in 2020. Note that this dashboard only tracks Injective's blockchain business.

INJ holders own and govern the protocol. They currently take a cut of the total transaction fees paid by users (revenue) via Burn Auctions. Injective's investors include Binance, Jump Crypto, Mark Cuban, etc.

github

twitter

discord

website

Blockchains (L1)

Injective

# Injective Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Injective measures the number of unique addresses that have initiated transactions on either the Injective EVM or Injective Cosmos chains within a rolling 30-day window. This metric provides insight into user engagement and adoption across Injective's dual-chain architecture. The calculation uses a rolling 30-day window approach, counting distinct users who have been active on any day within the past 30 days for each date.

## 2. Data sources

- **Injective EVM transaction records**: Transaction data from the Injective EVM chain containing sender addresses (`from_address`) and block timestamps
- **Injective Cosmos message events**: Message event logs from the Injective Cosmos chain containing sender information in event attributes and block timestamps
- **Chain availability metadata**: Data quality filters to ensure consistent chain data availability

## 3. Step-by-step calculation

### Component A: Injective EVM user identification
- **Purpose**: Identifies daily active users from Injective EVM transaction activity
- **Logic**: Extracts unique transaction sender addresses from Injective EVM transaction records. Each transaction's `from_address` represents a user who initiated on-chain activity. Data is aggregated by day using timestamp truncation to day granularity. Users are classified as "Transaction sender" type and associated with the 'Injective EVM' product and chain identifiers.
- **Key fields**: `block_timestamp` for temporal aggregation, `from_address` as the unique user identifier, `transaction_hash` for transaction reference

### Component B: Injective cosmos user identification  
- **Purpose**: Identifies daily active users from Injective Cosmos message activity
- **Logic**: Extracts unique sender addresses from Cosmos message events where the `event_type` equals 'message'. The sender address is extracted from the `event_attributes` JSON field using the `sender` key. Similar to EVM users, data is aggregated by day and users are classified as "Transaction sender" type, associated with the 'injective' chain and 'Injective Cosmos' product.
- **Key fields**: `block_timestamp` for temporal aggregation, `event_attributes.sender` as the unique user identifier, `event_type` for filtering to message events

### Component C: Daily active user aggregation
- **Purpose**: Combines EVM and Cosmos users into unified daily active user counts
- **Logic**: Unions the user data from both chains and creates distinct user counts per day, broken down by chain, user type, and product dimensions. Uses HyperLogLog sketches for memory-efficient distinct counting, initializing with precision parameter 15. Chain availability filters are applied to ensure data quality.
- **Key fields**: `timestamp` truncated to day, `chain` identifier, `user_type` classification, `product_id` for product categorization, `user_dau` containing the unique user address

### Component D: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for MAU calculation
- **Logic**: Generates a complete datespine covering all days from the earliest available data to yesterday. For each day in the datespine, creates a 30-day lookback window by generating timestamps for the current day and the previous 29 days. This ensures no gaps in the time series and enables consistent rolling window calculations.
- **Key fields**: `timestamp` as the reference date, `joinday` representing each day within the 30-day window

### Component E: Window-based user aggregation
- **Purpose**: Aggregates unique users within each 30-day rolling window
- **Logic**: Joins the daily HLL sketches with the rolling window structure, matching each day's user data with all relevant 30-day windows that include that day. This creates overlapping windows where each day's users contribute to multiple MAU calculations.
- **Key fields**: `timestamp` as the window end date, `hll` sketches containing user data for each day within the window

### Component F: Dimensional breakdowns
- **Purpose**: Creates MAU metrics across different analytical dimensions
- **Logic**: Merges HLL sketches within each 30-day window and extracts final user counts for multiple dimensional breakdowns: project-level (overall Injective), chain-level (EVM vs Cosmos), user-type-level (transaction senders), and product-level (Injective EVM vs Injective Cosmos). Each breakdown groups and merges the appropriate HLL sketches.
- **Key fields**: `dimensions` indicating the breakdown type, dimension-specific identifiers (chain_id, product_id, user_type), `user_mau` as the final distinct user count

### Final aggregation
- **Combining components**: All dimensional breakdowns are unioned together to create a comprehensive dataset with MAU metrics across all analytical dimensions
- **Time aggregation**: Uses daily timestamps as the grain, with each date representing the end of a 30-day rolling window
- **Final calculation**: HyperLogLog sketches are merged using `hll_count.merge_partial()` and extracted using `hll_count.extract()` to produce the final distinct user count for each 30-day window. The `finalize_metric_user_mau` macro standardizes the output format and fills missing values with zeros where appropriate.

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

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

InjectiveINJ

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown