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 Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the total fees paid by users for social actions on the Lens Protocol. This metric captures the monetary value of user interactions including content collection and profile following. The calculation treats all user payments for these social actions as supply-side fees, with the underlying assumption that these payments flow entirely to content creators and the protocol (supply side) rather than being retained by intermediaries.

## 2. Data sources

The calculation uses the following raw data sources:
- **Lens protocol events**: Parsed `Collected` and `Followed` events from the Lens Protocol smart contracts on Polygon blockchain
- **Event data parsing**: Encoded module data within these events containing payment token addresses and amounts
- **Token metadata**: Token decimal specifications for proper amount calculations
- **End-of-day price feeds**: Daily token prices for USD conversion

## 3. Step-by-step calculation

### Component A: Lens collect events processing
- **Purpose**: Extract payment data from content collection activities
- **Logic**: Process Lens `Collected` events from Polygon blockchain. Parse the `collectModuleData` field using hex string manipulation to extract payment information. Extract token addresses from bytes 26-66 by taking a 40-character substring and prepending '0x'. Extract payment amounts from bytes 67-130 by taking a 64-character substring, prepending '0x', and converting from hexadecimal to decimal. Classify actions as 'Collect' when `rootPubId` equals `pubId`, otherwise classify as 'Mirror'. Handle cases where amount parsing fails by defaulting to zero.
- **Key fields**: `block_timestamp` for timing, `token_address` for payment currency, `amount` for payment value, `action_type` for classification

### Component B: Lens follow events processing  
- **Purpose**: Extract payment data from profile following activities
- **Logic**: Process Lens `Followed` events from Polygon blockchain. Parse the `followModuleDatas` field using the same hex string manipulation approach as collect events. Extract token addresses from bytes 26-66 and payment amounts from bytes 67-130. All actions are classified as 'Follow' type. Apply the same error handling for amount parsing failures.
- **Key fields**: `block_timestamp` for timing, `token_address` for payment currency, `amount` for payment value, `action_type` set to 'Follow'

### Component C: Trading volume aggregation
- **Purpose**: Combine all social action payments into daily trading volume totals
- **Logic**: Union the processed collect and follow events into a single dataset. Truncate timestamps to daily boundaries for aggregation. Set chain as 'polygon', market sector as 'social', and business segment as 'social' for all records. Leave `product_id` as null since this represents protocol-wide activity rather than specific product usage.
- **Key fields**: `timestamp` truncated to day, `trading_volume` containing payment amounts, `token_address` for currency identification

### Component D: USD conversion and decimal correction
- **Purpose**: Standardize all payment amounts to USD values with proper decimal handling
- **Logic**: Apply the standard USD conversion process using end-of-day token prices. Correct for token-specific decimal places to ensure accurate amount calculations. This handles the fact that different ERC-20 tokens use different decimal specifications (e.g., USDC uses 6 decimals, WETH uses 18 decimals).
- **Key fields**: Converted `trading_volume` values in USD with proper decimal adjustment

### Final aggregation
- **Combining components**: The trading volume data (representing all user payments for social actions) flows directly into fees calculation
- **Fees calculation**: Apply a 1:1 mapping where trading volume equals fees, based on the assumption that all user payments for Lens social actions represent fees paid to the supply side
- **Supply-side fees extraction**: Extract the calculated fees directly as supply-side fees without any additional processing, representing the complete flow of user payments to content creators and the protocol
- **Currency conversion**: All amounts are converted to USD using end-of-day token prices with proper decimal correction
- **Time aggregation**: Data is aggregated to daily boundaries with day-level timestamp grain
- **Final calculation**: Supply-side fees equal the total USD value of all payments made for Lens Protocol social interactions (collects and follows) on each day

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

Portion of fees distributed to service providers or supply-side participants.

Lens

Supply-side fees

Supply-side fees

Competitive landscape