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

## 1. Overview

Monthly active addresses measures the number of unique addresses that have sent at least one transaction on the Injective Protocol within a rolling 30-day period. This metric serves as a proxy for user engagement and adoption, capturing activity across both the Injective Cosmos chain and the Injective EVM chain. The calculation uses a rolling window approach where each day represents a 30-day lookback period, providing a smoothed view of user activity trends. For blockchain protocols, active addresses are equivalent to active users since each transaction must originate from a unique address.

## 2. Data sources

The calculation relies on two primary blockchain data sources:

- **Injective Cosmos message events**: Parsed blockchain events from the Injective Cosmos chain, specifically `message` events that contain sender address information in the event attributes
- **Injective EVM transaction records**: Standard EVM-style transaction records from the Injective EVM chain, including sender addresses (`from_address`) and transaction metadata
- **Blockchain metadata**: Chain identifiers, block timestamps, and transaction hashes for proper attribution and time-based aggregation

## 3. Step-by-step calculation

### Component A: Injective EVM user identification
- **Purpose**: Identifies unique daily active users from Injective EVM transactions
- **Logic**: Extracts all transaction sender addresses from Injective EVM transaction records. Each transaction's `from_address` field represents a user who initiated blockchain activity. The data is aggregated by day using timestamp truncation, creating distinct user-day combinations. Each user is classified as a "Transaction sender" type and attributed to the 'Injective EVM' product and 'blockchains_l1' market sector.
- **Key fields**: `block_timestamp` for daily grouping, `from_address` as the user identifier, `transaction_hash` for transaction linkage

### Component B: Injective cosmos user identification  
- **Purpose**: Identifies unique daily active users from Injective Cosmos message events
- **Logic**: Processes Injective Cosmos message events by filtering for `message` event types and extracting sender addresses from the JSON event attributes using the `$.sender` path. Similar to EVM processing, the data is aggregated daily with each sender representing an active user. Users are classified as "Transaction sender" type and attributed to the 'Injective Cosmos' product and 'blockchains_l1' market sector.
- **Key fields**: `block_timestamp` for daily grouping, `sender` from event attributes as the user identifier, `transaction_hash` for event linkage

### Component C: Daily active user aggregation
- **Purpose**: Combines users from both chains and prepares data for monthly window calculations
- **Logic**: Merges the EVM and Cosmos user data using a union operation, creating a comprehensive daily view of all Injective Protocol users. The combined dataset maintains chain-specific attribution while providing a unified user activity stream. Applies HyperLogLog initialization to each daily user set with precision 15, enabling efficient approximate counting for the subsequent rolling window calculations.
- **Key fields**: `timestamp` (daily), `user_dau` (user addresses), `chain` for source attribution, `user_type` for classification

### Component D: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for monthly active user calculation
- **Logic**: Generates a continuous datespine covering all days from the earliest available data to the current date. For each day in the datespine, creates a 30-day lookback period by generating timestamps for the current day plus the previous 29 days. This approach ensures consistent 30-day windows even when some days have no user activity. Joins the window definitions with the daily HyperLogLog user data to populate each rolling period.
- **Key fields**: `timestamp` for window endpoints, `joinday` for the rolling period dates, `hll` containing the daily user sketches

### Component E: Monthly active user aggregation
- **Purpose**: Calculates unique users within each 30-day rolling window across multiple dimensions
- **Logic**: Groups the windowed data by timestamp and selected dimensions, then merges HyperLogLog sketches within each window using partial merge operations. Extracts the final unique user count from the merged sketches, providing approximate distinct counts that handle overlapping users across the 30-day period. Creates separate breakdowns for chain-level, user type, product level, and project-level aggregations to support different analytical needs.
- **Key fields**: `user_mau` containing the unique user count, `dimensions` indicating the breakdown level, `chain_id` and other grouping fields

### Final aggregation
- **Combining components**: The various dimensional breakdowns are combined using union operations to create a comprehensive monthly active user dataset with multiple analytical perspectives
- **Schema standardization**: Applies the `finalize_metric_user_mau` macro to ensure consistent field naming, data types, and handling of missing periods through zero-filling
- **Field transformation**: Renames the `user_mau` field to `active_addresses_monthly` to align with the specific metric definition, since for blockchain protocols active users and active addresses represent the same concept
- **Final calculation**: The result provides daily time series data where each day represents the count of unique addresses that were active within the trailing 30-day period, calculated using approximate distinct counting via HyperLogLog for computational efficiency

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

Unique addresses active over a rolling 30-day window.

InjectiveINJ

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown