Stakers deposit funds into Lido and receive a return on investment in the form of staking rewards (supply-side fees).

Lido is a non-custodial staking protocol built on Ethereum and other blockchains. Lido was founded by a pseudo-anonymous team and launched in 2020.

LDO tokenholders own and govern the protocol. They currently take a cut of the total staking rewards earned by the protocol (revenue). Lido’s investors include ParaFi Capital, Bitscale Capital, KR1, etc.

governance

github

twitter

discord

etherscan

website

Liquid staking

Lido Finance

# Lido Finance Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for Lido measures the distinct number of unique addresses that have interacted with Lido's liquid staking protocol within any 7-day rolling window. This metric captures user engagement across both staking (depositing ETH) and unstaking (requesting withdrawals) activities. The calculation uses HyperLogLog data structures to efficiently count distinct users across the rolling time window while providing dimensional breakdowns by chain, user type, and product.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Ethereum smart contract events**: Parsed `stETH_Submitted_event` from Lido V1 contracts capturing ETH deposits and stETH minting
- **Ethereum smart contract events**: Parsed `WithdrawalQueueERC721_WithdrawalRequested_event` from Lido V2 contracts capturing withdrawal requests
- **Blockchain transaction data**: Ethereum transaction timestamps and hashes for temporal ordering and deduplication

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identifies all user addresses that interact with Lido's staking protocol through deposits or withdrawal requests
- **Logic**: Extracts user addresses from two types of Ethereum smart contract events. For staking activity, captures the `sender` address from `stETH_Submitted_event` events and classifies them as "Depositor" user types. For unstaking activity, captures the `requestor` address from `WithdrawalQueueERC721_WithdrawalRequested_event` events and classifies them as "Withdrawer" user types. Each interaction includes the block timestamp, transaction hash, chain identifier, and user address
- **Key fields**: `sender` and `requestor` addresses become `user_address`, `block_timestamp` for temporal analysis, `transaction_hash` for deduplication, and `user_type` classification as either "Depositor" or "Withdrawer"

### Component B: Daily active users aggregation  
- **Purpose**: Aggregates user interactions to count distinct active users per day while maintaining dimensional attributes
- **Logic**: Groups user interactions by truncating timestamps to daily granularity using day-level time truncation. Creates distinct combinations of date, chain, user type, product, and user address to ensure each user is counted only once per day regardless of multiple interactions. Maintains dimensional attributes including chain, user type, market sector, business segment, and product identifiers for downstream analysis
- **Key fields**: `timestamp` truncated to day level, `chain` identifier, `user_type` classification, `product_id` for product-level analysis, and `user_address` for distinct counting

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily active user data into HyperLogLog data structures for efficient distinct counting across rolling windows
- **Logic**: Takes the daily active users and initializes HyperLogLog sketches with 15-bit precision for each combination of timestamp, chain, user type, and product. Groups the data by these dimensions and creates HLL structures that can be efficiently merged to count distinct users across multiple days
- **Key fields**: HyperLogLog `hll` structures initialized from `user_dau` addresses, maintaining `timestamp`, `chain_id`, `user_type`, and `product_id` grouping dimensions

### Component D: Rolling window creation
- **Purpose**: Creates a complete 7-day rolling window framework that ensures no gaps in the time series
- **Logic**: Generates a complete date spine covering the full range of available data to prevent missing days from affecting the rolling window calculation. For each day in the spine, creates join relationships with the 6 preceding days to form 7-day windows. Uses date arithmetic to generate timestamp arrays spanning from 6 days prior to each target date, creating the foundation for rolling window aggregations
- **Key fields**: `timestamp` as the target date, `joinday` representing each day within the 7-day window for that timestamp

### Component E: Weekly active user calculation
- **Purpose**: Merges HyperLogLog structures across 7-day windows to count distinct users active within each weekly period
- **Logic**: Joins the rolling window framework with the HyperLogLog daily data, matching each window day with its corresponding daily user data. For each 7-day window, merges the HyperLogLog structures from all days within that window to produce a count of distinct users who were active at least once during the 7-day period. This approach efficiently handles users who were active on multiple days within the window, counting them only once
- **Key fields**: Merged `hll` structures representing distinct users across the 7-day window, with dimensions preserved for downstream breakdowns

### Final aggregation
- **Combining components**: The final aggregation creates four distinct dimensional breakdowns from the weekly active user data. Each breakdown aggregates the merged HyperLogLog structures but groups by different dimensional combinations: project-level (no dimensional filtering), chain-level (grouped by chain), user-type level (grouped by depositor vs withdrawer classification), and product-level (grouped by product identifier)
- **Currency conversion**: No currency conversion is required as this metric counts user addresses rather than monetary values
- **Time aggregation**: Uses daily timestamps as the base granularity with 7-day rolling windows. Each day represents the count of distinct users active in the 7-day period ending on that day
- **Final calculation**: Extracts the final distinct user count from the merged HyperLogLog structures using the extract function, applies standardized metric formatting through the finalize macro, and fills any missing days with zero values to maintain complete time series continuity

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

Unique revenue-generating users over a rolling 7-day window.

Lido FinanceLDO

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown