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

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with the Liquid Collective protocol within any 7-day rolling window. This metric provides insight into user engagement and adoption by tracking both depositors (users staking ETH) and withdrawers (users requesting redemptions) across the protocol. The calculation uses HyperLogLog probabilistic counting to efficiently handle large user sets and provides dimensional breakdowns by chain, user type, and product.

## 2. Data sources

- **Ethereum blockchain events**: Parsed smart contract events from the Liquid Collective protocol on Ethereum, specifically `RiverV1_UserDeposit_event` and `RedeemManagerV1_RequestedRedeem_event`
- **Transaction data**: Ethereum transaction records providing timestamps and transaction context for user interactions
- **User addresses**: Ethereum addresses extracted from deposit and withdrawal events, representing users interacting with the liquid staking protocol

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identify and classify all user interactions with the Liquid Collective protocol
- **Logic**: Extract user addresses from two types of Ethereum smart contract events. From `RiverV1_UserDeposit_event`, capture the `depositor` address and classify as 'Depositor' user type. From `RedeemManagerV1_RequestedRedeem_event`, capture the `owner` address and classify as 'Withdrawer' user type. Each interaction includes the block timestamp, transaction hash, chain identifier, and user address.
- **Key fields**: `user_address` from event parameters, `block_timestamp` for timing, `user_type` classification ('Depositor' or 'Withdrawer'), `chain` identifier, and static values for `market_sector_id` and `business_segment_id` set to 'liquid_staking'

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily unique active users from the identified interactions
- **Logic**: Group user interactions by day using timestamp truncation to daily boundaries. Within each day, deduplicate user addresses to count each user only once regardless of how many transactions they performed. Preserve dimensional attributes including chain, user type, market sector, business segment, and product identifiers.
- **Key fields**: `timestamp` truncated to day level, `timestamp_grain` set to 'day', `user_dau` containing the unique user address, and dimensional fields for breakdowns

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user sets into probabilistic counting structures for efficient computation
- **Logic**: Transform the daily active user data into HyperLogLog sketches using 15-bit precision. Group by timestamp, timestamp grain, chain, user type, and product to create separate HLL sketches for each dimensional combination. This enables efficient counting of unique users across time windows without storing complete user address lists.
- **Key fields**: `hll` containing the HyperLogLog sketch of daily users, along with all dimensional grouping fields

### Component D: Seven-day rolling window construction
- **Purpose**: Create a framework for calculating 7-day rolling windows of user activity
- **Logic**: Generate a complete datespine covering every day from the first available DAU record to yesterday. For each day in the datespine, create associations with that day and the 6 preceding days to form 7-day windows. This ensures no days are skipped in the rolling calculation, even if there were no user interactions on certain days.
- **Key fields**: `timestamp` for the window end date and `joinday` for each of the 7 days included in that window

### Component E: Window-based HLL aggregation  
- **Purpose**: Collect and merge HLL sketches across each 7-day window
- **Logic**: For each day's 7-day window, join with the daily HLL sketches to collect the user data from all 7 days. This creates multiple rows per final timestamp, with each row representing one day's contribution to that window. Preserve all dimensional attributes to enable breakdowns in the final aggregation.
- **Key fields**: Window `timestamp`, daily `hll` sketches, and dimensional fields (`chain_id`, `user_type`, `product_id`)

### Component F: Dimensional breakdown calculation
- **Purpose**: Calculate WAU across different analytical dimensions
- **Logic**: Perform separate aggregations for four dimensional breakdowns. For project-level WAU, merge all HLL sketches regardless of other dimensions. For chain-level WAU, group by chain and merge sketches within each chain. For user-type WAU, group by user type and merge sketches for depositors and withdrawers separately. For product-level WAU, group by product and merge sketches within each product. Each breakdown nulls out unused dimensional fields.
- **Key fields**: `dimensions` indicating the breakdown type, dimensional identifier fields (with unused ones set to null), and `user_wau` containing the extracted unique user count

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, with each row representing a different analytical slice of the same time window
- **HLL processing**: Extract the final unique user count from merged HLL sketches using `hll_count.extract` function, which provides the probabilistic estimate of distinct users
- **Time boundaries**: Use daily timestamps as window endpoints, with each timestamp representing the count of unique users active in the 7-day period ending on that date
- **Final calculation**: The `user_wau` value represents the estimated number of unique Ethereum addresses that interacted with Liquid Collective (through deposits or withdrawal requests) within the 7-day rolling window ending on the specified timestamp

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

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

Liquid Collective

Active users (weekly)

Active users (weekly)

Competitive landscape