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

## 1. Overview

Active EigenLayer operators measures the daily count of distinct operators that are both registered with Actively Validated Services (AVS) and maintain positive stake shares in qualifying strategies. This metric tracks operator participation in the EigenLayer restaking ecosystem, focusing on operators with meaningful economic participation through ETH or EIGEN token staking. The calculation identifies operators who are actively registered and have positive balances in relevant restaking strategies.

## 2. Data sources

The calculation relies on several core blockchain data sources:
- **EigenLayer DelegationManager contract events**: Parsed `OperatorSharesIncreased` and `OperatorSharesDecreased` events from Ethereum that track changes in operator stake positions across different restaking strategies
- **EigenLayer AVSDirectory contract events**: Parsed `OperatorAVSRegistrationStatusUpdated` events from Ethereum that record operator registration and deregistration with Actively Validated Services
- **Strategy asset mappings**: EigenLayer strategy contract data that maps each strategy address to its underlying token assets
- **Token metadata**: Token information including symbols and chain identifiers used to classify strategies as ETH or EIGEN-related

## 3. Step-by-step calculation

### Component A: Operator share tracking
- **Purpose**: Tracks cumulative stake balances for each operator across all EigenLayer strategies over time
- **Logic**: Processes daily aggregated `OperatorSharesIncreased` and `OperatorSharesDecreased` events from the DelegationManager contract. Share increases are added as positive values while decreases are subtracted. The system calculates running cumulative totals partitioned by `operator` address and `strategy` address, ordered by timestamp. Fill-forward logic maintains continuous daily time series data, carrying forward the last known share balance for each operator-strategy pair
- **Key fields**: `operator` (operator address), `strategy` (strategy contract address), `shares` (cumulative share balance), `timestamp` (daily granularity)

### Component B: Operator registration status tracking  
- **Purpose**: Tracks which operators are currently registered with Actively Validated Services
- **Logic**: Processes `OperatorAVSRegistrationStatusUpdated` events from the AVSDirectory contract, taking only the latest status update per day for each operator-AVS pair. Uses fill-forward logic to maintain continuous status history. Status value of 1 indicates active registration while other values indicate deregistration
- **Key fields**: `operator` (operator address), `avs` (AVS service address), `status` (registration status integer), `timestamp` (daily granularity)

### Component C: Strategy qualification and filtering
- **Purpose**: Identifies which strategies count toward active operator status based on underlying assets
- **Logic**: Maps strategy addresses to their underlying token assets and filters for strategies containing ETH or EIGEN-related tokens. Uses pattern matching on token symbols to identify qualifying strategies (symbols containing 'ETH' or 'EIGEN'). Excludes a predefined denylist of strategies that shouldn't count despite matching the token filter. The beacon strategy address `0xbeac0eeeeeeeeeeeeeeeeeeeeeeeeeeeeeebeac0` receives special handling and is processed separately
- **Key fields**: `strategy` (strategy address), `token_address` (underlying asset), `symbol` (token symbol)

### Component D: Active operator identification
- **Purpose**: Combines registration status and stake positions to identify active operators
- **Logic**: Joins operators with active registration status (status = 1) with operators having positive share balances in qualifying strategies. For regular strategies, requires positive shares in strategies with ETH or EIGEN underlying assets, excluding denylisted addresses. For the beacon strategy, only requires positive share balance without additional token filtering. Takes distinct operator addresses per day to avoid double-counting operators active in multiple strategies or AVS services
- **Key fields**: `operator` (operator address), `timestamp` (daily granularity)

### Final aggregation
- **Combining components**: Creates three dimensional views of the active operator count: by project (project_dbt_tag), by chain (ethereum), and by product_id, each counting distinct operators from the active operator identification step
- **Currency conversion**: Not applicable - this is a count metric without currency values
- **Time aggregation**: Daily boundaries based on blockchain timestamp truncation to day level
- **Final calculation**: Counts distinct `operator` addresses per day across the different dimensional groupings, applies the finalize_metric macro with zero-filling strategy to ensure continuous time series, and applies chain availability filtering to the final results

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

Unique operator addresses actively registered to at least one AVS with positive qualifying stake.

EigenCloudEIGEN

Active Eigenlayer operators

Active Eigenlayer operators

Competitive landscape