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 Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average daily fees generated per active user on Stader's liquid staking protocol. This metric answers how much fee revenue the protocol generates per user engagement and is calculated by dividing total daily fees by the number of daily active users. The calculation combines protocol revenue and supply-side fees from liquid staking operations across Ethereum (MATIC staking) and BSC (BNB staking) networks.

## 2. Data sources

The AFPU calculation uses several types of raw blockchain data:

**Blockchain events:**
- Parsed Ethereum `DistributeFees` events from the MaticX contract capturing protocol fee distributions
- Parsed Ethereum `Submit` events from the MaticX contract for MATIC deposits
- Parsed Ethereum `Deposited` events from the StaderStakePoolsManager contract for ETH deposits
- Parsed Ethereum `ClaimWithdrawal` events from the MaticX contract for MATIC withdrawals

**Transaction data:**
- Parsed Ethereum function call traces from UserWithdrawalManager `finalizeUserWithdrawalRequest` calls for ETH withdrawals
- Parsed BSC function call traces from StakeManager `addRestakingRewards` calls for BNB yield distributions
- Parsed BSC function call traces from StakeManager `deposit` calls for BNB deposits  
- Parsed BSC function call traces from StakeManager `completeUndelegation` calls for BNB withdrawals

**External data:**
- End-of-day price feeds for MATIC and BNB tokens for USD conversion
- Token metadata including decimal places for proper amount calculations

## 3. Step-by-step calculation

### Component A: User activity tracking
- **Purpose**: Identifies daily active users across all liquid staking operations
- **Logic**: Collects user addresses from deposit and withdrawal interactions across Ethereum and BSC networks. For Ethereum, captures users from MATIC deposit (`Submit` events), MATIC withdrawal (`ClaimWithdrawal` events), ETH deposit (`Deposited` events), and ETH withdrawal (`finalizeUserWithdrawalRequest` function calls). For BSC, captures users from BNB deposit (`deposit` function calls) and BNB withdrawal (`completeUndelegation` function calls). Each interaction is classified by user type (Depositor/Withdrawer) and token type (MATIC/ETH/BNB). Only successful transactions are included based on status flags and removed event filters.
- **Key fields**: `user_address` from various interaction types, `block_timestamp` for daily aggregation, `user_type` classification, `chain` identification

### Component B: Daily active user aggregation  
- **Purpose**: Counts distinct daily users efficiently across multiple dimensions
- **Logic**: Aggregates user interactions into daily distinct counts using HyperLogLog sketches for memory-efficient processing. Groups users by timestamp (truncated to daily), chain, user type, and product dimensions. Creates multiple aggregation levels: project-level (all users), chain-level breakdown, user-type breakdown (depositors vs withdrawers), and product-level breakdown. Uses HyperLogLog merge operations to combine sketches and extract final distinct counts.
- **Key fields**: Daily `timestamp`, `user_dau` counts, dimensional breakdowns for `chain_id`, `user_type`, `product_id`

### Component C: BNB fee calculation
- **Purpose**: Calculates fees from BNB liquid staking operations
- **Logic**: Uses `addRestakingRewards` function call data from BSC StakeManager contract to capture BNB yield distributions. For revenue calculation, takes 1/9th of the yield amount as protocol revenue (only for dates after February 1, 2023, otherwise zero). For supply-side fees, takes the full yield amount as fees paid to users. Both calculations use the `amount` field from successful function calls only.
- **Key fields**: `amount` from restaking rewards, `block_timestamp` for daily aggregation, BNB token address `0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c`

### Component D: MATIC fee calculation
- **Purpose**: Calculates fees from MATIC liquid staking operations  
- **Logic**: Uses `DistributeFees` events from Ethereum MaticX contract to capture protocol fee distributions. For revenue calculation, takes the full event `amount` as protocol revenue. For supply-side fees, multiplies the event `amount` by 9 to represent the total yield before protocol fee extraction. Only processes non-removed events from successful transactions.
- **Key fields**: `amount` from distribution events, `block_timestamp` for daily aggregation, MATIC token address `0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0`

### Component E: USD conversion and aggregation
- **Purpose**: Converts all fee amounts to USD and prepares for final calculation
- **Logic**: Applies decimal correction based on token metadata (18 decimals for both MATIC and BNB). Converts amounts to USD using end-of-day price feeds matched by date and token address. Aggregates all revenue sources (BNB protocol share + MATIC distributions) and all supply-side fee sources (BNB full yields + MATIC calculated yields) into daily totals by chain and product dimensions.
- **Key fields**: USD-converted `revenue` and `fees_supply_side`, daily `timestamp`, `chain_id` breakdowns

### Final aggregation
- **Combining components**: Sums revenue and supply-side fees into total daily fees, then divides by daily active user counts using the calculate_arpu macro
- **Currency conversion**: All amounts converted to USD using end-of-day token prices with proper decimal adjustment
- **Time aggregation**: All data aggregated to daily boundaries using timestamp truncation to day level
- **Final calculation**: AFPU = Total Daily Fees (USD) ÷ Daily Active Users, with zero-fill strategy applied for days with no activity to maintain continuous time series

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

StaderSD

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape