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 Active Eigenlayer AVSs Methodology

## 1. Overview

Active EigenLayer AVSs measures the number of Actively Validated Services (AVSs) that have at least one active EigenLayer operator providing validation services on any given day. This metric reflects the breadth of the EigenLayer ecosystem by counting how many different services are actively being validated by operators who have meaningful stake in ETH or EIGEN tokens. The calculation identifies operators with actual economic stake in EigenLayer-related assets and then counts the distinct AVSs that these qualified operators are actively serving.

## 2. Data sources

The calculation relies on several key data sources from the EigenLayer protocol on Ethereum:

- **Operator share events**: `DelegationManager_OperatorSharesIncreased` and `DelegationManager_OperatorSharesDecreased` events that track changes in operator stake across different strategies
- **Registration status events**: `AVSDirectory_OperatorAVSRegistrationStatusUpdated` events that track when operators register or deregister with specific AVSs
- **Strategy metadata**: Information mapping EigenLayer strategies to their underlying token assets
- **Token metadata**: Symbol and contract information for tokens to identify ETH and EIGEN-related strategies
- **EigenLayer protocol configuration**: Strategy addresses including the beacon chain strategy and denylisted strategies

## 3. Step-by-step calculation

### Component A: Operator share tracking
- **Purpose**: Track the cumulative stake (shares) each operator holds in each EigenLayer strategy over time
- **Logic**: Daily aggregation of operator share increase and decrease events to calculate net daily changes. Running cumulative totals are maintained for each operator-strategy combination using window functions ordered by timestamp. The cumulative shares are then forward-filled to provide daily snapshots, ensuring every day shows the most recent share balance for each operator-strategy pair
- **Key fields**: `operator` address, `strategy` address, cumulative `shares` balance, daily `timestamp`

### Component B: Operator-AVS registration status tracking
- **Purpose**: Track which operators are registered to provide validation services for which AVSs on each day
- **Logic**: Daily capture of the latest registration status update event for each operator-AVS pair. Only the most recent status update within each day is retained using row number ranking. Status values are forward-filled to subsequent days until a new status update occurs, maintaining a complete daily status history
- **Key fields**: `operator` address, `avs` address, registration `status` (1 for active, 0 for inactive), daily `timestamp`

### Component C: Active eigenLayer operator identification
- **Purpose**: Identify operators that qualify as "active EigenLayer operators" based on their stake and registration status
- **Logic**: An operator qualifies as an active EigenLayer operator if they meet two criteria: (1) have active registration status (status = 1) with at least one AVS, and (2) hold positive shares in qualifying strategies. Qualifying strategies include those backed by tokens with symbols containing "ETH" or "EIGEN", plus the special beacon chain strategy. The beacon chain strategy is handled separately since it functions differently from other strategies. Specific denylisted strategy addresses are excluded to remove governance tokens that shouldn't qualify operators
- **Key fields**: `operator` address, daily `timestamp`

### Component D: Active AVS determination
- **Purpose**: Identify which AVSs are considered "active" based on having qualified operator support
- **Logic**: An AVS is considered active on a given day if it has at least one active EigenLayer operator registered with it (registration status = 1). This combines the operator registration status data with the list of qualified active EigenLayer operators to determine which AVSs have meaningful validation support
- **Key fields**: `avs` address, daily `timestamp`

### Final aggregation
- **Combining components**: The final calculation counts the distinct number of active AVS addresses per day across different dimensional breakdowns including project-level, chain-level (Ethereum), and product-level aggregations
- **Currency conversion**: Not applicable - this is a count-based metric
- **Time aggregation**: Daily grain with timestamp truncation to day boundaries
- **Final calculation**: Distinct count of `avs` addresses that meet the active criteria, aggregated by day and presented across multiple dimensional views (project, chain, product) with appropriate null handling for dimensional fields not applicable to each view

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

Unique AVSs with at least one active EigenLayer operator.

EigenCloudEIGEN

Active Eigenlayer AVSs

Active Eigenlayer AVSs

Competitive landscape