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

## 1. Overview

Average Revenue Per User (ARPU) measures the average revenue generated per daily active user over a given time period. For Lens protocol, ARPU is calculated by dividing total revenue by the number of daily active users. However, since Lens operates as a decentralized social protocol that doesn't retain transaction fees as protocol revenue, the ARPU consistently equals zero while maintaining proper metric structure and user counting methodology.

## 2. Data sources

- **Lens protocol events**: Parsed Polygon blockchain events from Lens v1 Hub contract including `ProfileCreated`, `Collected`, `Followed`, `PostCreated`, `CommentCreated`, and `MirrorCreated` events
- **Transaction fees**: Token payment data extracted from collect and follow module parameters within Polygon event logs
- **End-of-day token price feeds**: USD conversion rates for tokens used in Lens transactions
- **Token metadata**: Decimal precision and contract information for proper amount calculations

## 3. Step-by-step calculation

### Component A: Daily active user calculation
- **Purpose**: Count distinct users interacting with Lens protocol daily across all activity types
- **Logic**: Extract user addresses from six different Lens protocol events. For direct events (`ProfileCreated`, `Collected`, `Followed`), use the user address directly from fields like `collector`, `follower`, or profile creator address. For profile-based events (`PostCreated`, `CommentCreated`, `MirrorCreated`), map the `profileId` to the corresponding user address via the profile creation allowlist. Aggregate all user addresses by day using HyperLogLog to ensure accurate distinct counting across multiple interaction types without double-counting users who perform multiple actions.
- **Key fields**: User addresses from `collector`, `follower`, profile creator fields, and profile ID mappings for content creation events

### Component B: Revenue calculation  
- **Purpose**: Calculate total protocol revenue from user transactions
- **Logic**: For Lens protocol, revenue is explicitly set to zero across all time periods and dimensions. While the protocol processes collect and follow transactions that involve token payments (extracted from `collectModuleData` and `followModuleData` hex-encoded parameters), these fees are not retained by the protocol as revenue. The revenue component maintains the same dimensional structure as the underlying fee data but with zero values.
- **Key fields**: Revenue amount (always zero), timestamp, chain identifier, product identifier

### Component C: Fee data structure (underlying component)
- **Purpose**: Provide dimensional structure for revenue calculation based on actual transaction fees
- **Logic**: Extract token addresses and amounts from hex-encoded module data in collect and follow events. Parse the `collectModuleData` and `followModuleData` fields using substring operations to extract token addresses (characters 27-66) and amounts (characters 67-130). Convert hex-encoded amounts to decimal values and token addresses to standard format. Convert all amounts to USD using end-of-day price feeds and apply decimal corrections based on token metadata. Aggregate by day and apply chain availability filters.
- **Key fields**: Token addresses, payment amounts, transaction timestamps, chain identifiers

### Final aggregation
- **Combining components**: ARPU is calculated using a macro that divides revenue by daily active users for each time period and dimensional combination (chain, product, etc.)
- **Currency conversion**: All revenue components are in USD, converted from underlying token amounts using end-of-day price feeds
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation, with gaps filled using zero values
- **Final calculation**: ARPU = Total Revenue ÷ Daily Active Users = $0 ÷ DAU = $0 for all periods, maintaining proper metric structure despite zero revenue values

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

Lens

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape