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 (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Lido measures the number of unique users who interacted with the Lido liquid staking protocol within a rolling 30-day window. This metric tracks user engagement across staking (depositing ETH to receive stETH) and withdrawal activities. The calculation uses HyperLogLog probabilistic counting to efficiently handle large user sets and provides dimensional breakdowns by project level, blockchain, user type, and product.

## 2. Data sources

- **Lido protocol events**: Parsed Ethereum event logs from Lido's smart contracts, specifically `Submitted` events from the stETH contract and `WithdrawalRequested` events from the WithdrawalQueue contract
- **Blockchain transaction data**: Ethereum transaction timestamps and hashes for contextual information
- **Chain availability data**: Configuration data determining which blockchain networks are included in the analysis

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identify all user interactions with the Lido protocol from raw blockchain events
- **Logic**: Extract user addresses and timestamps from two key Lido protocol events. From `Submitted` events (when users deposit ETH to receive stETH tokens), capture the `sender` address and classify as "Depositor" user type. From `WithdrawalRequested` events (when users request to withdraw their staked ETH), capture the `requestor` address and classify as "Withdrawer" user type. Each interaction includes the transaction timestamp, hash, blockchain identifier, and user address
- **Key fields**: `sender` and `requestor` addresses become `user_address`, `block_timestamp` for timing, `user_type` classification, and `chain` identifier

### Component B: Daily active user calculation  
- **Purpose**: Aggregate unique user addresses to daily active user counts
- **Logic**: Group all user interactions by day using timestamp truncation to daily granularity. Count distinct user addresses per day, maintaining segmentation by blockchain, user type, and product. This creates a base dataset of daily active users that serves as input for the monthly calculation
- **Key fields**: `timestamp` truncated to day, distinct count of `user_address` as `user_dau`, maintained dimensions for `chain`, `user_type`, and `product_id`

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user counts into probabilistic data structures for efficient monthly aggregation
- **Logic**: Initialize HyperLogLog sketches from the daily active user data with precision parameter 15. HyperLogLog enables efficient counting of unique users across multiple days without storing individual user addresses, making the 30-day window calculation computationally efficient even with large user sets
- **Key fields**: `hll` sketches initialized from `user_dau` counts, grouped by timestamp and all dimension combinations

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for each date to calculate monthly active users
- **Logic**: Generate a datespine covering all dates from the earliest available data to yesterday. For each date in the datespine, create associations with the 29 preceding days to form 30-day windows. Join these date ranges with the HyperLogLog daily data to collect all user activity within each 30-day period
- **Key fields**: `timestamp` as the target date, `joinday` representing each day within the 30-day window, maintained HyperLogLog sketches for each window

### Component E: Monthly unique user calculation
- **Purpose**: Count unique users across each 30-day window using probabilistic methods
- **Logic**: Merge HyperLogLog sketches across all days within each 30-day window using `hll_count.merge_partial()` function. Extract the final unique user count using `hll_count.extract()`. This approach efficiently handles overlapping users across multiple days within the monthly window without double-counting
- **Key fields**: Merged `hll` sketches producing `user_mau` counts for each 30-day window and dimension combination

### Final aggregation
- **Combining components**: Create multiple dimensional views of the MAU data including project-level totals, chain-specific breakdowns, user type segmentation, and product-level analysis. Each breakdown aggregates the HyperLogLog sketches appropriately while nullifying non-relevant dimension fields
- **Time aggregation**: Apply daily granularity with each date representing a 30-day trailing window ending on that date
- **Final calculation**: Extract unique user counts from merged HyperLogLog sketches, apply standardized metric finalization including schema normalization and zero-filling for missing dates, filter results to the appropriate time range for incremental updates

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

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

Lido FinanceLDO

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown