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

Swell is a non-custodial liquid staking protocol built on Ethereum. Swell was founded by Daniel Dizon and launched in 2023.

SWELL tokenholders own and govern the protocol. They currently don’t take a cut of the total return on investment (revenue).

governance

github

twitter

discord

website

Liquid staking

Swell

# Swell Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Swell measures the count of unique user addresses that have interacted with the Swell liquid staking protocol within any 30-day rolling window. This metric tracks user engagement with Swell's liquid staking services by counting unique depositors over monthly periods. The calculation uses HyperLogLog data structures for efficient unique user counting across time windows and provides multiple dimensional breakdowns including overall project level, by blockchain, by user type, and by product.

## 2. Data sources

- **Ethereum blockchain event logs**: Parsed `ETHDepositReceived` events from Swell protocol smart contracts, including both v1 and v2 contract versions
- **Transaction metadata**: Ethereum transaction records containing block timestamps, transaction hashes, and log indices for event ordering and temporal analysis
- **Chain availability data**: Configuration data that determines valid time periods and blockchain networks for analysis
- **Protocol contract events**: Specifically `swETH_ETHDepositReceived_event` and `swETHV2_ETHDepositReceived_event` from the Swell liquid staking protocol

## 3. Step-by-step calculation

### Component A: User activity identification
- **Purpose**: Identify all user interactions with the Swell protocol by extracting user addresses from deposit events
- **Logic**: The system monitors Ethereum blockchain event logs for specific Swell protocol events, focusing on `ETHDepositReceived` events from both version 1 and version 2 smart contracts. From each event, the user address is extracted from the `from` parameter, representing the depositor initiating the liquid staking transaction. Each interaction is timestamped using the block timestamp and includes transaction metadata such as `transaction_hash` and `log_index` for precise event identification. All users are classified as 'Depositor' type and categorized under the 'liquid_staking' market sector and business segment.
- **Key fields**: `block_timestamp` for temporal analysis, `from` parameter containing user addresses, `transaction_hash` for transaction identification, `chain` identifier, `user_type` classification

### Component B: Daily active user aggregation
- **Purpose**: Convert raw user interactions into daily active user counts while preserving dimensional attributes
- **Logic**: User interactions are grouped by day using truncated block timestamps to create daily boundaries. The system creates distinct counts of active users for each day, maintaining dimensional breakdowns including blockchain network, user type, market sector, business segment, and product identifier. This creates a foundation dataset where each record represents the set of unique users active on a specific day with their associated attributes.
- **Key fields**: `timestamp` truncated to day granularity, `chain` network identifier, `user_type` classification, `product_id` for product-level analysis, `user_address` for unique user identification

### Component C: HyperLogLog preparation
- **Purpose**: Convert daily user lists into efficient data structures for unique counting across time windows
- **Logic**: Daily active user data is transformed into HyperLogLog data structures using BigQuery's `hll_count.init` function with a precision of 15. This allows for memory-efficient storage and computation of unique user counts when combining multiple days. The HLL structures preserve the ability to merge and count unique users across different time periods without storing individual user addresses.
- **Key fields**: `hll` containing the HyperLogLog representation of daily active users, dimensional attributes preserved for grouping

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for each date to calculate monthly active user metrics
- **Logic**: A datespine is generated covering the complete time range from the first recorded user activity to the previous day. For each date in this spine, a 30-day lookback window is constructed that includes the current date plus the 29 preceding days. This is accomplished through cross-join operations that generate arrays of dates for each rolling window period. The system ensures no dates are skipped even if no user activity occurred on specific days.
- **Key fields**: `timestamp` representing the end date of each 30-day window, `joinday` representing each day within the rolling window period

### Component E: Window aggregation and unique user counting
- **Purpose**: Calculate unique user counts over each 30-day rolling window using HyperLogLog merge operations
- **Logic**: The rolling window framework is joined with the daily HLL data to associate each day's user activity with all relevant 30-day windows. For each window period, HLL structures from constituent days are merged using `hll_count.merge_partial` and then extracted using `hll_count.extract` to produce final unique user counts. This process efficiently handles overlapping time windows and ensures accurate unique user counting without double-counting users who were active on multiple days within the same 30-day period.
- **Key fields**: `timestamp` for the window end date, `hll` structures merged across the 30-day period, dimensional attributes for grouping

### Final aggregation
- **Combining components**: Multiple dimensional breakdowns are calculated in parallel, including project-level totals (all dimensions null), chain-level breakdowns, user type breakdowns, and product-level breakdowns. Each breakdown applies the same HLL merging and extraction logic but groups by different dimensional combinations.
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 30-day rolling windows where each date represents the count of unique users active in the 30 days ending on that date, providing smooth trending without traditional monthly boundary effects
- **Final calculation**: The final MAU value for any given date represents the distinct count of user addresses that had at least one interaction with the Swell protocol during the 30-day period ending on that date. Multiple dimensional views are combined using UNION ALL operations and processed through the `finalize_metric_user_mau` macro for standardized formatting and schema compliance.

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

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

SwellSWELL

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown