Stakers deposit funds into StakeWise and receive a return on investment in the form of staking rewards (supply-side fees).

StakeWise is a non-custodial staking protocol built on Ethereum. StakeWise was founded by Dmitri Tsumak & Kirill Kutakov and launched in 2021.

SWISE tokenholders own and govern the protocol. They currently take a cut of the total return on investment (revenue). StakeWise’s investors include Blockdaemon, Boldstart Ventures, Collider, etc.

github

twitter

discord

etherscan

website

Liquid staking

StakeWise

# StakeWise Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for StakeWise measures the number of unique users who interacted with the StakeWise liquid staking protocol within rolling 30-day periods. This metric answers the business question "How many distinct users are actively engaging with StakeWise's staking products each month?" The calculation uses a probabilistic HyperLogLog approach to efficiently aggregate daily active users over rolling windows while maintaining accuracy for large user sets. The metric provides breakdowns by chain, user type, and product to enable detailed analysis of user engagement patterns.

## 2. Data sources

The calculation draws from multiple blockchain data sources to comprehensively identify StakeWise user activity:

- **Ethereum beacon chain events**: Parsed `DepositEvent` logs from the beacon deposit contract to identify validator deposits and staking participants
- **Ethereum transaction data**: Transaction traces that link deposit amounts to depositor addresses for validator identification
- **Ethereum block data**: Block-level withdrawal records from the beacon chain containing validator exit and partial withdrawal information
- **StakeWise smart contract events**: Parsed events from both v1 and v3 protocol contracts including `DepositAdded`, `Deposited`, `ExitQueueEntered`, and `Migrated` events across solo and pool staking products
- **Token transfer events**: ERC20 transfer logs for StakeWise liquid staking tokens (sETH2 on Ethereum, sGNO on Gnosis) to capture v1 pool user activity through mint and burn events
- **Multi-chain event logs**: Event data from both Ethereum mainnet and Gnosis chain to capture cross-chain protocol usage

## 3. Step-by-step calculation

### Component A: User identification and classification

- **Purpose**: Identify all unique addresses that interact with StakeWise protocol and classify them by user type and product
- **Logic**: The system parses multiple event sources to capture different types of user activity. For solo staking, it extracts user addresses from StakeWise v1 `DepositAdded` events (marking them as Depositors) and identifies withdrawers from beacon chain withdrawal data where StakeWise validators receive funds. For pool staking, it captures user addresses from v3 `Deposited` and `ExitQueueEntered` events across different vault types. Additionally, for v1 pool users, it identifies participants through token transfer events where sETH2 or sGNO tokens are minted (deposits) or burned (withdrawals), while excluding migration transactions to prevent double-counting. Each user interaction is timestamped and classified by chain, product type (solostaking or poolstaking), and user type (Depositor or Withdrawer)
- **Key fields**: `user_address` (the wallet address), `user_type` (Depositor or Withdrawer), `product_id` (solostaking or poolstaking), `chain` (ethereum or gnosis), `block_timestamp` (interaction timestamp)

### Component B: Daily user aggregation  

- **Purpose**: Aggregate identified users into daily active user counts while preserving dimensional attributes
- **Logic**: The system takes all user interactions and groups them by calendar day using timestamp truncation to day boundaries. For each day, it creates distinct combinations of user address, chain, user type, and product ID to ensure each user is counted only once per day per dimension, even if they had multiple transactions. This creates a base layer of daily unique active users with all necessary dimensional attributes preserved for downstream aggregation
- **Key fields**: `timestamp` (day-truncated date), `chain` (blockchain identifier), `user_type` (user classification), `product_id` (product identifier), `user_dau` (unique user address for that day)

### Component C: HyperLogLog initialization

- **Purpose**: Convert daily user counts into probabilistic data structures for efficient aggregation
- **Logic**: For each daily user count by dimensional combination, the system initializes HyperLogLog sketches with precision 15. HyperLogLog is a probabilistic algorithm that enables efficient counting of distinct elements (users) while using minimal memory. Each daily combination of timestamp, chain, user type, and product gets its own HLL sketch containing the distinct user addresses for that day and dimension
- **Key fields**: `hll` (HyperLogLog sketch containing user addresses), dimensional keys preserved from daily aggregation

### Component D: Rolling window construction

- **Purpose**: Create 30-day rolling windows for each date to calculate monthly active users
- **Logic**: The system generates a complete datespine covering all dates from the earliest user activity to yesterday. For each date in this spine, it creates a cross-join with the previous 30 days (including the current day) to form rolling windows. This approach uses unnested timestamp arrays to generate date ranges efficiently. The cross-join produces combinations of each target date with each of its preceding 29 days plus itself, creating the foundation for 30-day rolling aggregations
- **Key fields**: `timestamp` (target date for MAU calculation), `joinday` (each day within the 30-day window)

### Component E: Window aggregation with HyperLogLog merging

- **Purpose**: Aggregate daily HLL sketches within each 30-day window to calculate unique users
- **Logic**: For each 30-day window created in the previous step, the system joins with the daily HLL data to collect all relevant sketches. It then merges HLL sketches from all days within each window using `hll_count.merge_partial()` which combines multiple HLL sketches while maintaining uniqueness properties. Finally, it extracts the estimated distinct count using `hll_count.extract()` to produce the final MAU value for each dimensional combination and time window
- **Key fields**: `user_mau` (estimated unique user count for the 30-day period), dimensional attributes (chain, user type, product ID)

### Final aggregation

- **Combining components**: The system creates multiple dimensional views of the same underlying data: project-level aggregation (all dimensions combined), chain-level breakdown, user type breakdown, and product-level breakdown. Each breakdown nullifies non-relevant dimensional fields while preserving the specific dimension being analyzed. All breakdowns are combined using UNION ALL operations to create a comprehensive dataset
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 30-day windows where each day represents the count of unique users who were active in that day plus the preceding 29 days, providing a smooth trend of monthly engagement without the abrupt changes that would occur with calendar month boundaries  
- **Final calculation**: The metric applies a finalization macro that standardizes the output format, ensures consistent schema, handles missing data by filling with zeros where appropriate, and applies incremental processing logic for efficient updates. The final MAU value represents the estimated number of distinct user addresses that interacted with StakeWise protocol within each rolling 30-day period

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

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

StakeWiseSWISE

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown