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 revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) for Stader measures the daily average revenue generated per active user across Stader's liquid staking protocol. This metric is calculated by dividing the total daily revenue by the number of daily active users (DAU), providing insight into the revenue efficiency and user monetization of the liquid staking service across multiple blockchain networks.

## 2. Data sources

The calculation relies on several types of raw blockchain and external data:

**Blockchain events**:
- Parsed Ethereum `Submit` events from MaticX contracts (MATIC deposits)
- Parsed Ethereum `ClaimWithdrawal` events from MaticX contracts (MATIC withdrawals)
- Parsed Ethereum `Deposited` events from StaderStakePoolsManager contracts (ETH deposits)
- Parsed Ethereum `DistributeFees` events from MaticX contracts (protocol fee distributions)

**Transaction data**:
- Ethereum function call traces for `finalizeUserWithdrawalRequest` (ETH withdrawals)
- BSC function call traces for `deposit` functions (BNB deposits)
- BSC function call traces for `completeUndelegation` (BNB withdrawals)
- BSC function call traces for `addRestakingRewards` (BNB yield distributions)

**External data**:
- End-of-day token price feeds for USD conversion
- Token metadata for decimal place corrections
- Chain availability data for filtering active blockchain networks

## 3. Step-by-step calculation

### Component A: Daily active user tracking

**Purpose**: Identify and count distinct users interacting with Stader's liquid staking protocol daily across multiple chains and activity types.

**Logic**: The system processes blockchain interactions from Ethereum and BSC networks, extracting user addresses from various liquid staking activities. On Ethereum, it captures MATIC staking through `Submit` events, MATIC unstaking through `ClaimWithdrawal` events, ETH staking through `Deposited` events, and ETH withdrawals through `finalizeUserWithdrawalRequest` function calls. On BSC, it tracks BNB deposits through `deposit` function calls and BNB withdrawals through `completeUndelegation` function calls. Each interaction is classified by user type such as 'MATIC Depositor', 'MATIC Withdrawer', 'ETH Depositor', 'ETH Withdrawer', 'BNB Depositor', or 'BNB Withdrawer'. Only successful transactions are included, filtered by transaction status being true for function calls and removed being false for events.

**Key fields**: User addresses are extracted from fields like `from`, `owner`, and `from_address` depending on the event or function call type. Each record includes `block_timestamp` for daily grouping, `user_address` for distinct counting, `chain` for network identification, and `user_type` for categorization.

### Component B: Daily active user aggregation

**Purpose**: Aggregate individual user interactions into daily distinct user counts using efficient probabilistic counting methods.

**Logic**: Individual user interactions are grouped by day using timestamp truncation to day boundaries. The system applies HyperLogLog probabilistic counting to efficiently calculate distinct users while supporting multiple dimensional breakdowns. It creates separate aggregations for project-level totals, chain-level breakdowns (Ethereum vs BSC), user-type breakdowns (depositors vs withdrawers by token), and product-level breakdowns. The HyperLogLog method enables accurate distinct counting even with large user volumes while maintaining reasonable computational requirements.

**Key fields**: The aggregation produces `timestamp` (daily boundaries), `user_dau` (distinct user count), and various dimension fields like `chain_id`, `user_type`, and `product_id` for different breakdown levels.

### Component C: Revenue collection and processing

**Purpose**: Calculate protocol revenue from liquid staking operations across BNB and MATIC tokens.

**Logic**: Revenue is collected from two main sources representing different aspects of Stader's business model. For BNB on BSC, revenue comes from `addRestakingRewards` function calls which represent staking rewards added to the protocol. These amounts are subject to a special business rule where, starting from February 1, 2023, the raw reward amount is divided by 9 to reflect the protocol's share of the total yield (representing approximately 11% protocol fee). For MATIC on Ethereum, revenue is derived from `DistributeFees` events which directly represent protocol fees collected from MATIC staking operations. All revenue events are filtered to include only successful transactions and non-removed events.

**Key fields**: Revenue records include `amount` (native token amounts), `token_address` for currency identification, `block_timestamp` for daily aggregation, and `chain` for network tracking.

### Component D: Revenue USD conversion

**Purpose**: Convert native token revenues to USD values using appropriate decimal corrections and exchange rates.

**Logic**: Native token amounts are processed through a standardized conversion pipeline that first corrects for token decimal places using token metadata, then converts to USD using end-of-day price feeds. The decimal correction ensures that raw blockchain amounts (typically stored as integers representing the smallest token unit) are converted to human-readable amounts. USD conversion uses end-of-day exchange rates to provide consistent daily pricing across all tokens and chains.

**Key fields**: The conversion produces `revenue` amounts in USD, maintaining timestamp and dimensional information for aggregation.

### Final aggregation

**Combining components**: Daily revenue totals are calculated by summing all USD-converted revenue across both BNB and MATIC sources for each day. Daily active user counts are extracted from the HyperLogLog aggregations at the project level to get total distinct users across all chains and activity types.

**Currency conversion**: All revenue is expressed in USD using end-of-day exchange rates, ensuring consistent measurement across different native tokens and blockchain networks.

**Time aggregation**: Both revenue and user metrics use day-boundary truncation of block timestamps, ensuring aligned daily periods for the division calculation.

**Final calculation**: ARPU is computed by dividing total daily revenue (in USD) by the total daily active user count. Days with zero active users result in zero ARPU values. The time series is completed by filling any missing dates with zero values to ensure continuous daily coverage across the measurement period.

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

StaderSD

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape