Stakers deposit funds into Stader and receive a return on investment in the form of staking rewards (supply-side revenue). Fantom fees and revenues are not included. 

Stader is a non-custodial liquid staking protocol built on Ethereum and other blockchains. Stader was founded by Amitej Gajjala, Dheeraj Borra & Sidhartha Doddipalli and launched in 2021.

SD tokenholders own and govern the protocol. They currently take a cut of the total return on investment (revenue). Stader’s investors include GoldenTree Asset Management, Blockchain.com, Pantera Capital etc.

governance

github

twitter

discord

etherscan

website

Liquid staking

Stader

# Stader Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for Stader measures the number of unique users who interacted with Stader's liquid staking protocol within a rolling 7-day window. This metric captures user engagement across Stader's liquid staking products on Ethereum and BSC networks, counting both deposit and withdrawal activities. The calculation uses HyperLogLog sketches for efficient distinct user counting across the rolling time window.

## 2. Data sources

The calculation relies on the following raw blockchain data sources:

- **Ethereum event logs**: Parsed `Submit` events from MaticX contracts capturing MATIC deposits, `ClaimWithdrawal` events for MATIC withdrawals, and `Deposited` events from StaderStakePoolsManager for ETH deposits
- **Ethereum transaction traces**: Function calls to `finalizeUserWithdrawalRequest` on UserWithdrawalManager contracts for ETH withdrawals
- **BSC transaction traces**: Function calls to `deposit` and `completeUndelegation` on StakeManager contracts for BNB deposits and withdrawals respectively
- **Chain availability data**: Data quality filters to ensure reliable blockchain data coverage

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identify all user addresses that interact with Stader's liquid staking protocol
- **Logic**: Extract user addresses from blockchain events and successful function calls across Ethereum and BSC networks. Events capture the `from` address or `owner` parameter depending on the event type. Function calls extract the `from_address` of the transaction. Each interaction is classified by user type as either "Depositor" (for deposit events/calls) or "Withdrawer" (for withdrawal events/calls). All interactions are categorized under the liquid staking business segment and tagged with the appropriate chain identifier
- **Key fields**: `user_address` extracted from event parameters, `user_type` classification, `chain` identifier, `block_timestamp` for temporal analysis, `transaction_hash` for deduplication

### Component B: Daily active users aggregation  
- **Purpose**: Calculate daily distinct active users from the user interaction data
- **Logic**: Group user interactions by day using timestamp truncation to day granularity. For each day, count distinct user addresses grouped by chain, user type, market sector, business segment, and product identifiers. Apply chain availability filtering to ensure data quality and exclude periods with incomplete blockchain data coverage
- **Key fields**: `timestamp` truncated to day, `user_dau` containing unique user addresses, dimensional grouping fields including `chain`, `user_type`, and `product_id`

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily active user data into HyperLogLog sketches for efficient distinct counting
- **Logic**: Transform each day's user address list into HyperLogLog sketches using BigQuery's `hll_count.init()` function with 15-bit precision. This allows efficient merging and distinct counting across the 7-day rolling window without storing individual user addresses
- **Key fields**: `hll` sketches containing compressed user address sets, dimensional breakdowns maintained for grouping

### Component D: Rolling window construction
- **Purpose**: Create 7-day rolling windows for WAU calculation
- **Logic**: Generate a complete datespine covering all dates from the earliest DAU data to present. For each date in the spine, create join relationships to the current day and the previous 6 days using array generation. This creates a 7-day sliding window that captures all user activity within each weekly period, ensuring no gaps in the time series even for days without activity
- **Key fields**: `timestamp` for the window end date, `joinday` for each day within the 7-day window

### Component E: Multi-dimensional breakdowns
- **Purpose**: Calculate WAU across different analytical dimensions
- **Logic**: Create separate breakdowns for project-level (overall Stader), chain-level (Ethereum/BSC), user-type-level (Depositors/Withdrawers), and product-level analysis. For each breakdown, merge the HyperLogLog sketches from all days within each 7-day window using `hll_count.merge_partial()`, then extract the final distinct count with `hll_count.extract()`. Null values are used for non-applicable dimensions in each breakdown
- **Key fields**: `dimensions` identifier, `user_wau` final count, dimensional fields set to null where not applicable

### Final aggregation
- **Combining components**: The different dimensional breakdowns are combined using UNION ALL operations to create a single result set with multiple analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily timestamps with 7-day rolling window logic, using month-level partitioning for efficient querying
- **Final calculation**: The final WAU value is the distinct count extracted from merged HyperLogLog sketches across the 7-day window, providing an accurate count of unique users who were active within any day of that week

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

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

StaderSD

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown