Stakers deposit funds into StakeStone and receive a return on investment in the form of staking rewards (supply-side fees). StakeStone then deploys the staked capital to Lido.

StakeStone is an omni-chain LST (Liquid Staking Token) protocol aiming to bring native staking yields and liquidity to Layer 2s. StakeStone was founded by a anonymous team and launched in 2023.

StakeStone team controls the protocol. They do not currently take a cut of the total staking rewards earned by the protocol (revenue).

github

twitter

discord

website

Liquid staking

StakeStone

# StakeStone Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with StakeStone's liquid staking protocol within any 7-day period. This metric provides insight into user engagement and adoption trends for StakeStone's liquid staking services. The calculation uses a rolling 7-day window approach with HyperLogLog data structures to efficiently count unique users across multiple time windows and dimensions.

## 2. Data sources

- **Ethereum transaction traces**: Function call data from StakeStone v1 AssetVault contract withdraw operations, capturing users who withdraw their staked assets
- **Ethereum event logs**: `Deposit` events from StakeStone v1 StoneVault contract, capturing users who deposit ETH for liquid staking
- **Transaction metadata**: Block timestamps for daily aggregation and transaction success status to filter completed operations
- **Blockchain event data**: Raw event logs and function call traces from Ethereum mainnet containing user addresses and interaction details

## 3. Step-by-step calculation

### Component A: User interaction capture
- **Purpose**: Identify all user addresses that interact with StakeStone protocol through deposits and withdrawals
- **Logic**: Combine two types of user interactions from Ethereum. First, capture withdrawers from AssetVault withdraw function calls using the `to` parameter, filtering only successful transactions with status true. Second, capture depositors from StoneVault `Deposit` events using the `account` parameter. All interactions are classified under liquid staking market and business segments with stakestonev1 product identifier
- **Key fields**: `user_address` from either `to` parameter or `account` parameter, `block_timestamp` for timing, `transaction_hash` for deduplication, `user_type` as either Depositor or Withdrawer

### Component B: Daily active users aggregation
- **Purpose**: Calculate daily unique user counts from the raw interaction data
- **Logic**: Group user interactions by truncated daily timestamps and count distinct user addresses. Apply chain availability filtering to ensure data quality. Group results by chain, user type, and product identifier to maintain dimensional breakdowns for downstream processing
- **Key fields**: `timestamp` truncated to day granularity, `user_dau` containing unique user addresses, dimension fields including `chain`, `user_type`, and `product_id`

### Component C: HyperLogLog initialization and datespine
- **Purpose**: Prepare daily user data for efficient 7-day window calculations and ensure complete date coverage
- **Logic**: Convert daily active user counts into HyperLogLog data structures using `hll_count.init` with 15-bit precision for memory-efficient unique counting across time windows. Create a complete datespine by generating daily timestamps from the earliest available data to yesterday, ensuring no gaps in the time series that could affect rolling window calculations
- **Key fields**: `hll` containing encoded user sets, `timestamp` for each calendar day, dimensional grouping fields preserved from daily aggregation

### Component D: Rolling window construction
- **Purpose**: Create 7-day rolling windows for each day to capture weekly active users
- **Logic**: For each day in the datespine, generate a 7-day lookback period including the current day plus the previous 6 days. Join this expanded date range with the daily HLL data to create window boundaries. This ensures each day has access to user activity from its 7-day window for WAU calculation
- **Key fields**: `timestamp` as the reference date, `joinday` representing each day within the 7-day window, `hll` data for user counting within windows

### Component E: Multi-dimensional WAU calculation
- **Purpose**: Calculate WAU across different business dimensions for comprehensive reporting
- **Logic**: Aggregate HLL data within 7-day windows across four distinct dimensions. First, project-level WAU by merging all HLL structures regardless of other dimensions. Second, chain-level WAU grouped by blockchain. Third, user-type WAU grouped by Depositor or Withdrawer classification. Fourth, product-level WAU grouped by product identifier. Use `hll_count.merge_partial` to combine HLL structures and `hll_count.extract` to get final unique counts
- **Key fields**: `user_wau` containing unique user count for each dimension, `dimensions` indicating the breakdown type, relevant dimension fields like `chain_id`, `user_type`, `product_id`

### Final aggregation
- **Combining components**: Union all dimensional WAU calculations using UNION ALL operations to create a single result set with multiple perspective breakdowns of the same underlying user activity
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily boundary logic with 7-day rolling windows, using timestamp truncation to day granularity and incremental processing with monthly partitions for efficiency
- **Final calculation**: Apply the `finalize_metric_user_wau` macro to standardize the output schema, implement zero-filling strategy for days with no activity, and add metadata fields required for the Token Terminal platform including data source identifiers and metric classifications

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

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

StakeStoneSTO

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown