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

Rocket Pool is a non-custodial staking protocol built on Ethereum. Rocket Pool was founded by David Rugendyke and launched in 2021.

RKT token holders own and govern the protocol. They currently take a cut of the total return on investment (revenue).

governance

github

twitter

discord

etherscan

website

Liquid staking

Rocket Pool

# Rocket Pool Active users (weekly) Methodology

## 1. Overview

Weekly active users (WAU) measures the number of unique users who interact with RocketPool's liquid staking protocol within any 7-day period. This metric answers the question "How many distinct users were active with RocketPool in the past week?" and uses a rolling 7-day window calculation. The methodology employs HyperLogLog (HLL) probabilistic data structures to efficiently count distinct users across time windows, enabling scalable computation even with large user bases.

## 2. Data sources

- **Ethereum smart contract events**: Parsed event logs from RocketPool's core smart contracts, specifically `DepositReceived` events from `RocketDepositPool` and `RocketDepositPoolV2` contracts, and `TokensBurned` events from the `RocketTokenRETH` contract
- **Blockchain transaction data**: Ethereum transaction timestamps and block metadata to determine when user interactions occurred
- **Chain availability configuration**: Data quality filters that ensure metrics only include dates when blockchain data is reliably available

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identifies all meaningful user interactions with RocketPool's liquid staking protocol
- **Logic**: Extracts user addresses from three types of Ethereum contract events: `DepositReceived` events from both versions of the deposit pool contracts (identifying users who stake ETH to receive rETH), and `TokensBurned` events from the rETH token contract (identifying users who burn rETH to withdraw their staked ETH). Users are classified as either 'Depositor' or 'Withdrawer' based on the event type. Each interaction captures the `user_address`, `block_timestamp`, transaction details, and assigns the interaction to the 'liquid_staking' market sector
- **Key fields**: `user_address` from the `from` parameter of each event, `block_timestamp` for timing, `user_type` classification, and transaction identification fields like `transaction_hash` and `log_index`

### Component B: Daily active user aggregation  
- **Purpose**: Aggregates user interactions into daily unique active users and converts them to HLL data structures
- **Logic**: Groups all user interactions by day using timestamp truncation to day boundaries. For each day, creates a distinct list of user addresses who performed any interaction, then initializes this list as an HLL sketch with 15-bit precision for efficient storage and computation. The data is organized by dimensions including `chain`, `user_type`, and `product_id` to enable later breakdown analysis
- **Key fields**: `timestamp` truncated to day, `user_dau` containing unique user addresses, and dimensional grouping fields like `chain` and `user_type`

### Component C: Time series datespine creation
- **Purpose**: Creates a continuous daily time series to ensure no gaps in the final metric, even on days with no user activity
- **Logic**: Generates a complete sequence of daily timestamps from the earliest date in the user data to yesterday using timestamp array generation. This datespine serves as the foundation for creating consistent 7-day rolling windows regardless of data gaps
- **Key fields**: `timestamp` representing each calendar day in the analysis period

### Component D: Rolling window generation
- **Purpose**: Creates 7-day sliding windows for each date to enable weekly active user calculation
- **Logic**: For each date in the datespine, generates the 6 preceding days plus the current day, creating a 7-day window. This is accomplished by joining the datespine with an array of the 7 relevant dates for each target date. The result is a mapping table where each target date is associated with all dates that should be included in its WAU calculation
- **Key fields**: `timestamp` as the target date and `joinday` representing each of the 7 days to include in that date's window

### Component E: Windowed HLL aggregation
- **Purpose**: Combines daily HLL sketches across 7-day windows to count unique users active in any of those days
- **Logic**: Joins the rolling window mapping with the daily HLL data, then merges the HLL sketches for all days within each 7-day window. The HLL merge operation efficiently combines the probabilistic sketches to count users who were active on any day within the window, avoiding double-counting users who were active on multiple days
- **Key fields**: `timestamp` for the target date, dimensional breakdown fields, and merged `hll` sketches containing the combined user counts

### Component F: Dimensional breakdowns
- **Purpose**: Creates multiple views of the WAU data broken down by different business dimensions
- **Logic**: Generates four separate aggregations from the windowed data: project-level (all users combined), chain-level (grouped by blockchain), user-type-level (grouped by depositor vs withdrawer), and product-level (grouped by specific products). Each breakdown extracts the final count from the merged HLL sketches and sets non-relevant dimensional fields to null. All breakdowns are unioned together to create a comprehensive dataset
- **Key fields**: `user_wau` extracted from HLL sketches, `dimensions` indicating the breakdown type, and the relevant dimensional field (`chain_id`, `user_type`, or `product_id`) with others set to null

### Final aggregation
- **Combining components**: The dimensional breakdowns are combined using union operations to create a single table containing WAU metrics at all relevant aggregation levels
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 7-day rolling windows where each date represents the count of unique users active in that date plus the previous 6 days
- **Final calculation**: The final `user_wau` value represents the approximate distinct count of users who performed any qualifying interaction (deposit or withdrawal) with RocketPool contracts within the 7-day window ending on each date. Missing dates are filled with zeros using the finalize metric macro to ensure a complete time series.

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

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

Rocket PoolRPL

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown