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

## 1. Overview

The Stader monthly active users (MAU) metric measures the number of unique users who have interacted with Stader's liquid staking protocol within a rolling 30-day window. This metric tracks user engagement across Stader's multi-chain liquid staking platform, which enables users to stake MATIC, ETH, and BNB while maintaining liquidity. The calculation uses HyperLogLog probabilistic data structures to efficiently count distinct users across time periods without double-counting users who are active on multiple days within the 30-day window.

## 2. Data sources

- **Ethereum parsed events**: Stader protocol event logs including `MaticX_Submit_event` (MATIC deposits), `MaticX_ClaimWithdrawal_event` (MATIC withdrawals), and `StaderStakePoolsManager_Deposited_event` (ETH deposits)
- **Ethereum parsed function calls**: Successful transaction executions including `UserWithdrawalManager_finalizeUserWithdrawalRequest_function` (ETH withdrawals)  
- **BSC parsed function calls**: Successful transaction executions including `StakeManager_deposit_function` (BNB deposits) and `StakeManager_completeUndelegation_function` (BNB withdrawals)
- **Blockchain transaction metadata**: Block timestamps, transaction hashes, and user addresses from Ethereum and BSC networks
- **Chain availability data**: Data quality filters to ensure consistent cross-chain coverage

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identifies all user interactions with Stader's liquid staking protocol across supported chains and categorizes users by interaction type
- **Logic**: Extracts user addresses from parsed blockchain events and function calls, focusing on liquid staking operations. For Ethereum, captures MATIC deposits via `MaticX_Submit_event` with `from` addresses classified as 'MATIC Depositor', MATIC withdrawals via `MaticX_ClaimWithdrawal_event` with `from` addresses as 'MATIC Withdrawer', ETH deposits via `StaderStakePoolsManager_Deposited_event` with `owner` addresses as 'ETH Depositor', and ETH withdrawals via `UserWithdrawalManager_finalizeUserWithdrawalRequest_function` calls with `from_address` as 'ETH Withdrawer'. For BSC, captures BNB deposits via `StakeManager_deposit_function` calls with `from_address` as 'BNB Depositor' and BNB withdrawals via `StakeManager_completeUndelegation_function` calls with `from_address` as 'BNB Withdrawer'. Only includes successful function calls where `status` is true
- **Key fields**: `block_timestamp`, `transaction_hash`, `chain`, `user_type` (categorizing deposit/withdrawal actions), `user_address`, with all interactions tagged under 'liquid_staking' market sector

### Component B: Daily active user aggregation  
- **Purpose**: Aggregates user interactions into daily active user counts using probabilistic counting structures
- **Logic**: Groups user interactions by day using `timestamp_trunc` on `block_timestamp` to create daily boundaries. Creates distinct user sets per day while maintaining dimensional breakdowns by `chain`, `user_type`, and `product_id`. Converts daily user address lists into HyperLogLog sketches using `hll_count.init` with 15-bit precision for efficient distinct user counting across time windows. Applies chain availability filters to ensure data quality and consistency
- **Key fields**: `timestamp` (daily grain), `timestamp_grain`, `chain`, `user_type`, `product_id`, `user_dau` (individual user addresses converted to HLL sketches)

### Component C: MAU window creation
- **Purpose**: Creates 30-day rolling windows for each date to capture all user activity within the monthly timeframe
- **Logic**: Generates a complete datespine covering all dates from the earliest DAU data to yesterday using `generate_timestamp_array` with daily intervals to prevent missing timestamps. For each date in the datespine, creates a 30-day lookback window by generating timestamps from 29 days prior through the current date using `generate_timestamp_array` with the formula timestamp_sub(current_date, interval 29 day) to current_date. Joins this window structure with the daily HLL data to collect all relevant user activity within each 30-day period, ensuring complete coverage even when specific days have no activity
- **Key fields**: `timestamp` (current date), `joinday` (dates within the 30-day window), `hll` (HyperLogLog sketches from daily user activity)

### Component D: Dimensional MAU calculations
- **Purpose**: Calculates monthly active users across different dimensional breakdowns while avoiding double-counting users active on multiple days
- **Logic**: Merges HyperLogLog sketches across the 30-day windows using `hll_count.merge_partial` to combine daily user sets, then extracts the final distinct user count using `hll_count.extract` for accurate unique user counting. Creates four dimensional breakdowns: project-level MAU aggregating all users regardless of chain or user type, chain-level MAU grouping by individual blockchain networks, user-type-level MAU segmenting by interaction type (depositors vs withdrawers), and product-level MAU grouping by specific product offerings. Uses `safe_cast(null as string)` to set non-relevant dimensions to null for each breakdown type
- **Key fields**: `timestamp`, `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_mau` (final distinct user count)

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns using `union all` to create a comprehensive dataset with MAU calculated across project, chain, user type, and product dimensions in a single table
- **Currency conversion**: Not applicable as this metric counts users rather than financial values
- **Time aggregation**: Uses daily timestamp boundaries with 30-day rolling windows, where each day represents MAU for that date and the preceding 29 days. The rolling window approach ensures smooth time series without month-boundary artifacts
- **Final calculation**: Applies the `finalize_metric_user_mau` macro with 'stader' data identifier and 'fill_zeros' strategy to standardize the metric schema and fill any missing days with zero values. Implements incremental processing with configurable lookback periods to handle late-arriving data and ensure data consistency during updates

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

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

StaderSD

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown