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 Revenue Methodology

## 1. Overview

The Lens revenue metric measures the revenue generated by the Lens Protocol, a decentralized social media protocol on Polygon. Despite having infrastructure to calculate fees from user interactions (collects and follows), the metric is explicitly set to zero, indicating that Lens Protocol currently operates as a zero-revenue model. The calculation demonstrates how the protocol could measure revenue from its social interactions if it chose to monetize these activities.

## 2. Data sources

The calculation uses the following raw data sources:
- **Lens protocol events**: Parsed `HubEvents_Collected_event` and `HubEvents_Followed_event` logs from Lens v1 smart contracts on Polygon blockchain
- **Token payment data**: Encoded payment information within Lens event logs containing token addresses and amounts for collect and follow actions
- **Price data**: End-of-day token price feeds for USD conversion of payment amounts
- **Token metadata**: Token decimal information for proper amount scaling and normalization

## 3. Step-by-step calculation

### Component A: Lens collect events parsing
- **Purpose**: Extract payment data from content collection and mirroring activities
- **Logic**: Parse Lens `HubEvents_Collected_event` logs from Polygon blockchain, using substring operations to extract token payment information from the `collectModuleData` field. Distinguish between direct content collection (when `rootPubId` equals `pubId`) labeled as 'Collect' versus content mirroring (when they differ) labeled as 'Mirror'. Extract token addresses from character positions 27-40 and payment amounts from positions 67-64 of the encoded data, converting hex strings to numeric values.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `token_address`, `amount`, `action_type`

### Component B: Lens follow events parsing  
- **Purpose**: Extract payment data from user following activities
- **Logic**: Parse Lens `HubEvents_Followed_event` logs from Polygon blockchain, using similar substring operations to extract payment information from the `followModuleDatas` field. All events are labeled as 'Follow' actions. Apply the same hex parsing logic to extract token addresses and amounts from the encoded payment data.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `token_address`, `amount`, `action_type`

### Component C: Trading volume aggregation
- **Purpose**: Combine all Lens social interactions with associated payments into daily trading volume metrics
- **Logic**: Union collect and follow event data, truncate timestamps to daily boundaries, and categorize all activity under 'social' market sector and business segment with null product identifiers. Convert token amounts to USD using end-of-day price feeds and apply decimal corrections based on token metadata to ensure proper scaling.
- **Key fields**: `timestamp`, `chain_id`, `token_address`, `trading_volume` (in USD)

### Component D: Fees calculation
- **Purpose**: Transform trading volume data into fees metrics
- **Logic**: Take the daily trading volume amounts and rename them as fees without any mathematical transformation. This represents the potential fee revenue if the protocol chose to capture a portion of the trading activity.
- **Key fields**: `timestamp`, `timestamp_grain`, `product_id`, `chain_id`, `fees`

### Final aggregation
- **Combining components**: Use the fees data structure but override all fee values
- **Revenue assignment**: Explicitly set revenue to zero for all time periods and products, regardless of underlying fee activity
- **Currency conversion**: All underlying amounts are converted to USD using end-of-day price feeds
- **Time aggregation**: Data is aggregated to daily boundaries with proper metric finalization
- **Final calculation**: Revenue = 0 for all records, creating a zero-revenue metric that maintains the data structure for potential future monetization while reflecting the current business model

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

Lens

Revenue

Revenue

Competitive landscape