Lens provides a full-stack platform combining Lens Chain for blockchain infrastructure and Lens Protocol for modular social primitives. Lens Chain offers instant transaction settlement with stable, low costs powered by GHO, backed by Ethereum security. Lens Protocol provides smart accounts with signless and gasless functionality, customizable usernames, graphs, feeds, and groups.

Lens is the full-stack platform for social and financial experiences, enabling developers to build SocialFi applications on-chain. The platform features Lens Chain as its blockchain infrastructure layer optimized for speed and scalability, and Lens Protocol for composable social primitives including accounts, usernames, graphs, feeds, and groups. Lens simplifies onchain adoption through portable data, simple onboarding via email or phone, and settlements in the USD-native stablecoin GHO.

Lens is built by the Aave team and is currently overseen by a multisig.

github

twitter

discord

website

Social

Lens

# Lens Active users (monthly) Methodology

## 1. Overview

The Lens Protocol Monthly Active Users (MAU) metric measures the number of unique users who have interacted with the Lens Protocol ecosystem within a rolling 30-day window. This metric captures user engagement across various activities including profile creation, social interactions (following, collecting), and content creation (posting, commenting, mirroring). The calculation uses HyperLogLog data structures to efficiently handle large-scale unique user counting across multiple time periods and dimensional breakdowns.

## 2. Data sources

The calculation is based on parsed smart contract events from the Lens Protocol Hub contract deployed on the Polygon blockchain:

- **Lens Protocol user events**: Parsed `ProfileCreated`, `Collected`, and `Followed` events that contain user wallet addresses
- **Lens Protocol content events**: Parsed `PostCreated`, `CommentCreated`, and `MirrorCreated` events that contain profile IDs for content creators
- **Profile mapping data**: `ProfileCreated` events that establish the relationship between profile IDs and wallet addresses
- **Blockchain transaction data**: Polygon transaction timestamps and hash identifiers for all Lens Protocol interactions

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Extract and classify users from various Lens Protocol interactions
- **Logic**: The system processes two types of user identification patterns. For direct user events like profile creation, collecting posts, and following other users, wallet addresses are extracted directly from the event parameters (`to`, `collector`, `follower` fields respectively). For content creation events like posting, commenting, and mirroring, the system uses profile IDs from the events and maps them to wallet addresses through an allowlist created from `ProfileCreated` events. Each interaction type creates a distinct user classification (Profile Creator, Collector, Follower, Poster, Commenter, Mirrorer).
- **Key fields**: `block_timestamp` for timing, `user_address` for unique user identification, `user_type` for interaction classification, `chain` identifier set to Polygon, and `product_id` for potential product-level breakdowns

### Component B: Daily active user aggregation
- **Purpose**: Convert event-level data into daily unique active user counts
- **Logic**: User interactions are grouped by day using timestamp truncation to daily boundaries. The system creates distinct combinations of timestamp, chain, user type, and product ID, then collects unique user addresses for each combination. This creates a daily snapshot of unique users who performed each type of activity. All users are classified under the social market sector and business segment.
- **Key fields**: `timestamp` truncated to daily granularity, `user_dau` containing unique user addresses, dimensional fields for grouping (`chain`, `user_type`, `product_id`)

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user lists into efficient probabilistic data structures for set operations
- **Logic**: Each day's unique user list is converted into a HyperLogLog (HLL) data structure with 15-bit precision. This allows for efficient storage and merging of large user sets while maintaining reasonable accuracy for cardinality estimation. The HLL structures are created for each unique combination of timestamp, chain, user type, and product ID.
- **Key fields**: `hll` structures containing compressed user set representations, maintaining all dimensional groupings from the daily aggregation

### Component D: Rolling window creation
- **Purpose**: Generate 30-day sliding windows for MAU calculation
- **Logic**: A datespine is created covering the full time range of available data, generating one record per day. For each day in the datespine, a join table is created that maps that day to each of the previous 30 days (including the current day). This creates a many-to-many relationship where each target date is associated with 30 historical dates. The HLL daily data is then joined to this structure, creating a window of 30 days' worth of HLL structures for each target date.
- **Key fields**: `timestamp` as the target MAU date, `joinday` representing each day within the 30-day window, `hll` structures from each day in the window

### Component E: MAU calculation across dimensions
- **Purpose**: Calculate unique users across 30-day windows for different dimensional breakdowns
- **Logic**: For each target date and dimensional combination, all HLL structures within the 30-day window are merged using HLL merge operations, then the final cardinality is extracted to get the unique user count. This is performed across four dimensional levels: overall project level (all dimensions collapsed), chain level (grouped by blockchain), user type level (grouped by interaction type), and product level (grouped by product ID). Each breakdown nullifies the non-relevant dimensional fields while preserving the grouping dimension.
- **Key fields**: `user_mau` containing the final unique user count, `dimensions` indicating the breakdown level, dimensional fields (`chain_id`, `user_type`, `product_id`) with relevant groupings preserved

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations, creating a single table with MAU values calculated at different granularities for the same underlying data
- **Time aggregation**: MAU is calculated for each day based on the previous 30 days (including the current day), creating a rolling 30-day window that updates daily
- **Final calculation**: The `finalize_metric_user_mau` macro applies standard schema formatting, fills missing dates with zeros, and ensures consistent metric structure. The final MAU value represents the count of unique users who performed any tracked Lens Protocol interaction within the 30-day window 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.

Lens

Active users (monthly)

Active users (monthly)

Competitive landscape