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

## 1. Overview

Daily Active Users (DAU) for Stader measures the number of unique wallet addresses that interact with Stader's liquid staking protocol on any given day. This metric captures user engagement across Stader's multi-chain liquid staking ecosystem, including MATIC staking on Ethereum, ETH staking on Ethereum, and BNB staking on BSC. The calculation identifies users performing deposit or withdrawal actions and counts distinct addresses per day, providing insight into the protocol's daily user adoption and activity levels.

## 2. Data sources

- **Ethereum blockchain event logs**: Parsed events from Stader's MaticX contracts including `Submit` and `ClaimWithdrawal` events, and `Deposited` events from StaderStakePoolsManager contracts
- **Ethereum blockchain transaction traces**: Function call traces for UserWithdrawalManager `finalizeUserWithdrawalRequest` function calls  
- **BSC blockchain transaction traces**: Function call traces for StakeManager `deposit` and `completeUndelegation` function calls
- **Blockchain transaction metadata**: Block timestamps, transaction hashes, and transaction status information for filtering successful interactions

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identify all user interactions with Stader's liquid staking protocol across supported chains
- **Logic**: Extract user addresses from two types of blockchain data sources. First, parse event logs from Stader contracts to capture deposit and withdrawal events, extracting user addresses from event parameters like `from` and `owner` fields. Second, analyze function call traces to identify direct contract interactions for staking and withdrawal operations. Each interaction is classified by the type of action (deposit or withdrawal) and the underlying asset (MATIC, ETH, or BNB). Only successful transactions are included by filtering function calls where `status` equals true
- **Key fields**: `user_address` (extracted from various event parameters), `user_type` (classified as depositor or withdrawer), `chain` (Ethereum or BSC), `block_timestamp` (for temporal analysis)

### Component B: User type classification  
- **Purpose**: Categorize users based on their specific interaction type and asset
- **Logic**: Apply predefined classification rules to assign user types based on the specific event or function call. MATIC-related interactions on Ethereum are classified as either "MATIC Depositor" for `Submit` events or "MATIC Withdrawer" for `ClaimWithdrawal` events. ETH-related interactions on Ethereum are classified as "ETH Depositor" for `Deposited` events or "ETH Withdrawer" for `finalizeUserWithdrawalRequest` function calls. BNB-related interactions on BSC are classified as "BNB Depositor" for `deposit` function calls or "BNB Withdrawer" for `completeUndelegation` function calls
- **Key fields**: `user_type` (specific depositor/withdrawer classification), `market_sector_id` and `business_segment_id` (both set to "liquid_staking"), `product_id` (null for Stader)

### Final aggregation
- **Combining components**: Union all user interactions from both event logs and function call traces across Ethereum and BSC chains
- **Time aggregation**: Truncate `block_timestamp` to day granularity using timestamp truncation, creating daily boundaries for user activity measurement
- **Distinct user counting**: Count distinct `user_address` values per day to eliminate multiple interactions by the same user within a single day, ensuring each unique wallet address is counted only once per day regardless of interaction frequency
- **Chain filtering**: Apply chain availability filtering to ensure data completeness and exclude periods where chain data may be incomplete or unavailable
- **Final calculation**: The final DAU value represents the count of unique wallet addresses that performed at least one staking or withdrawal interaction with Stader's protocol on each specific day, aggregated across all supported chains and asset types

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

Unique revenue-generating users over a fixed 24-hour window.

StaderSD

Active users (daily)

Active users (daily)

Competitive landscape

Chain breakdown