AVSs (Autonomous Verifiable Services) reward stakers and operators in exchange for security for third party services (supply-side fees).

EigenCloud is a marketplace connecting stakers and operators with applications that need active security. EigenCloud was founded by Sreeram Kannan and launched in 2023.

EigenCloud team and investors own and govern the protocol. They do not currently take a cut of the total rewards paid by AVSs (revenue). EigenCloud's investors include Blockchain Capital, Polychain Capital, Coinbase Ventures, etc.

governance

github

twitter

discord

website

Liquid staking

EigenCloud

# EigenCloud Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) for EigenLayer measures the daily revenue generated per active user on the platform. This metric is calculated by dividing total daily revenue by the number of daily active users (DAU). Currently, EigenLayer's revenue is set to zero, making the ARPU effectively zero, but the methodology tracks user activity from liquid staking operations including deposits, withdrawals, and delegation activities.

## 2. Data sources

- **EigenLayer smart contract events**: Parsed Ethereum events from EigenLayer's core contracts including `StrategyManager` deposit and withdrawal events, and `DelegationManager` operator delegation events
- **Reward claim events**: Parsed `RewardsClaimed` events from EigenLayer's `RewardsCoordinator` contract containing reward distribution data
- **Token metadata**: Token contract information including decimal precision for amount normalization
- **End-of-day price feeds**: Daily token price data for USD conversion of reward amounts
- **Transaction data**: Ethereum transaction timestamps and identifiers for event context

## 3. Step-by-step calculation

### Component A: User activity identification
- **Purpose**: Identifies and classifies daily active users based on EigenLayer interactions
- **Logic**: Extracts user addresses from four types of EigenLayer contract events on Ethereum. `StrategyManager` `Deposit` events identify users as 'Depositor' type, while `WithdrawalCompleted` events mark users as 'Withdrawer' type. `DelegationManager` events track delegation changes, with `OperatorSharesIncreased` events marking users as 'Depositor' type and `OperatorSharesDecreased` events as 'Withdrawer' type. Each interaction is timestamped and linked to specific user addresses.
- **Key fields**: `block_timestamp` for daily aggregation, user addresses (`depositor`, `withdrawer`, `staker`), `transaction_hash` and `log_index` for event uniqueness, and `user_type` classification

### Component B: Daily active user aggregation
- **Purpose**: Counts distinct active users per day using efficient aggregation methods
- **Logic**: Groups user interactions by day using timestamp truncation to daily boundaries. Applies HyperLogLog (HLL) data structure for memory-efficient distinct user counting. Aggregates users across multiple dimensions including overall project level, by chain, by user type ('Depositor' vs 'Withdrawer'), and by product. Uses HLL merge operations to combine user sets without double-counting users who perform multiple activities in a day.
- **Key fields**: `timestamp` truncated to day, `user_address` for distinct counting, `chain` for multi-chain support, `user_type` for user classification, `product_id` for product-level breakdowns

### Component C: Fee and revenue processing
- **Purpose**: Processes reward claim events and converts to USD values, though currently not used for revenue
- **Logic**: Extracts reward claim amounts from `RewardsCoordinator` `RewardsClaimed` events. Converts token amounts to USD using end-of-day price feeds and corrects for token decimal precision. Groups by daily timestamps and aggregates total fee amounts. However, the revenue component explicitly sets all revenue values to zero, indicating EigenLayer currently has no tracked revenue stream.
- **Key fields**: `claimedAmount` for reward values, `token` address for price lookup, `block_timestamp` for daily aggregation, `earner`, `claimer`, and `recipient` addresses for reward distribution tracking

### Final aggregation
- **Combining components**: The ARPU calculation uses the `calculate_arpu` macro which divides revenue metrics by user DAU metrics on a daily basis. Both components are joined by timestamp, chain, and product dimensions to ensure proper alignment.
- **Currency conversion**: All monetary values are converted to USD using end-of-day price feeds, with token decimal adjustments applied to ensure accurate value representation.
- **Time aggregation**: Daily boundaries are consistently applied across all components, with timestamp truncation to day level ensuring alignment between user activity and revenue data.
- **Final calculation**: Daily ARPU equals daily revenue divided by daily active users. Given that revenue is currently set to zero for EigenLayer, the resulting ARPU is zero. The methodology includes zero-filling for missing days to maintain complete time series data, ensuring consistent reporting even when no user activity or revenue occurs on specific days.

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

EigenCloudEIGEN

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape