Stakers use Liquid Collective to deposit funds into Ethereum’s deposit contract and mint a liquid staking token, LsETH. In return stakers receive staking rewards (supply-side fees).

Liquid Collective is a non-custodial staking protocol launched on Ethereum. Liquid Collective is built and run by a collective of leading web3 teams. The protocol was initially launched in 2023.

Liquid Collective is stewarded by an independent industry consortium, with initial members that include The Liquid Foundation, Alluvial, Kiln, Figment, Coinbase, Coinbase Cloud, Kraken, Staked, and other web3 participants. Liquid Collective will be governed in a decentralized manner by a broad and dispersed community of industry participants.

github

twitter

etherscan

website

Liquid staking

Liquid Collective

# Liquid Collective Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who have interacted with the LiquidCollective liquid staking protocol within a 30-day rolling window. This metric captures both depositors (users staking ETH) and withdrawers (users requesting redemptions) to provide a comprehensive view of protocol engagement. The calculation uses HyperLogLog data structures to efficiently count distinct users across multiple dimensions while maintaining accuracy.

## 2. Data sources

The MAU calculation relies on the following data sources:

- **LiquidCollective protocol events**: Parsed Ethereum blockchain events from the LiquidCollective smart contracts, specifically `UserDeposit` events from the RiverV1 contract and `RequestedRedeem` events from the RedeemManagerV1 contract
- **Ethereum transaction data**: Block timestamps and transaction hashes from Ethereum blockchain transactions containing the relevant events
- **Event parameters**: User addresses extracted from event parameters (`depositor` field from `UserDeposit` events and `owner` field from `RequestedRedeem` events)

## 3. Step-by-step calculation

### Component A: User event extraction
- **Purpose**: Identifies all user interactions with the LiquidCollective protocol
- **Logic**: Extracts user addresses from two types of blockchain events. `UserDeposit` events identify users making deposits (staking ETH), while `RequestedRedeem` events identify users requesting withdrawals. Each interaction captures the user address, block timestamp, transaction hash, and chain information. Users are classified as either "Depositor" or "Withdrawer" based on the event type.
- **Key fields**: `user_address` (extracted from `depositor` or `owner` parameters), `block_timestamp`, `transaction_hash`, `chain`, `user_type`

### Component B: Daily active user calculation  
- **Purpose**: Aggregates unique users per day across different dimensions
- **Logic**: Groups user interactions by day using timestamp truncation to daily granularity. Counts distinct user addresses within each day, broken down by chain, user type, market sector, business segment, and product. All users are classified under the 'liquid_staking' market sector and business segment. Chain availability filters ensure data quality by excluding periods when chain data may be incomplete.
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain`, `chain`, `user_type`, `product_id`, `user_dau`

### Component C: HyperLogLog conversion
- **Purpose**: Converts daily active users to HyperLogLog sketches for efficient distinct counting
- **Logic**: Takes the daily active user data and creates HyperLogLog sketches for each combination of day, chain, user type, and product. HyperLogLog is a probabilistic data structure that allows efficient estimation of distinct counts while using minimal memory, enabling accurate aggregation across the 30-day windows.
- **Key fields**: `hll` (HyperLogLog sketch of users), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Rolling window creation
- **Purpose**: Creates 30-day rolling windows for MAU calculation
- **Logic**: Generates a date spine covering all days in the analysis period, then creates join relationships between each day and the previous 29 days. This creates overlapping 30-day windows where each day serves as the end date for a monthly period. The window includes the current day plus the 29 preceding days.
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within the window)

### Component E: Window aggregation
- **Purpose**: Merges daily HyperLogLog sketches within each 30-day window
- **Logic**: For each 30-day window, collects all HyperLogLog sketches from the constituent days and merges them using HyperLogLog merge operations. This combines all unique users who were active within the 30-day period while avoiding double-counting users who were active on multiple days.
- **Key fields**: Merged `hll` sketches containing all unique users in the 30-day window

### Component F: Dimensional breakdowns
- **Purpose**: Creates MAU metrics across different analytical dimensions
- **Logic**: Extracts distinct user counts from the merged HyperLogLog sketches and creates separate breakdowns for project-level (overall protocol), chain-level, user type-level (depositor vs withdrawer), and product-level analysis. Each breakdown aggregates the appropriate HyperLogLog sketches and extracts the final distinct count using HyperLogLog extract functions.
- **Key fields**: `user_mau` (final distinct user count), `dimensions` (breakdown type), dimension-specific fields

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a single table with multiple rows per day representing different analytical cuts of the same underlying MAU data
- **Time aggregation**: Each day represents the end date of a 30-day rolling window, providing continuous MAU measurements without gaps
- **Final calculation**: The MAU value for each day and dimension combination represents the count of distinct users who were active within the 30-day window ending on that date, extracted from merged HyperLogLog sketches and standardized using the finalize metric macro with zero-filling for missing days

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

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

Liquid Collective

Active users (monthly)

Active users (monthly)

Competitive landscape