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


Frax Ether is a liquid staking derivative product created by the Frax Finance protocol. Frax Finance was founded by Sam Kazemian, Stephen Moore, Jason Huoan & Travis Moore and launched in 2019.


FRAX tokenholders own and govern the Frax Finance protocol, including the Frax Ether business line. They currently take a cut of the total staking rewards earned by the protocol (revenue). Frax’s investors include Crypto.com Capital & Ascensive Assets.


github

twitter

discord

etherscan

website

Liquid staking

Frax Ether

# Frax Ether Active users (monthly) Methodology

## 1. Overview

FRAX Monthly Active Users (MAU) measures the number of unique users who interacted with the FRAX liquid staking protocol within a rolling 30-day window. The metric uses HyperLogLog approximate counting to efficiently calculate distinct users across multiple dimensional breakdowns including project-level aggregates, individual chains, user types, and product categories. This metric answers the question: "How many unique users engaged with FRAX liquid staking services in the past 30 days?"

## 2. Data sources

The FRAX MAU calculation is built from the following raw data sources:

- **Ethereum event logs**: Parsed `ETHSubmitted` events from the FRAX FrxETHMinter contract, which capture user deposits into the liquid staking protocol
- **Transaction data**: Ethereum transaction records providing block timestamps, transaction hashes, and log indexes for event ordering and temporal analysis
- **Blockchain metadata**: Block timestamp data used to establish daily and monthly time boundaries for user activity aggregation

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identifies all relevant user interactions with the FRAX protocol from blockchain events
- **Logic**: Extracts user addresses from Ethereum `ETHSubmitted` events on the FrxETHMinter contract. Each event represents a user depositing ETH into the FRAX liquid staking system. Users are classified as "Depositor" type and categorized under the "liquid_staking" market sector and business segment. The system captures the user address from the `sender` parameter of each event along with transaction metadata including block timestamp, transaction hash, and log index for precise event tracking.
- **Key fields**: `sender` (user address), `block_timestamp`, `transaction_hash`, `log_index`, with users classified as "Depositor" type under "liquid_staking" category

### Component B: Daily active users calculation  
- **Purpose**: Transforms raw user interactions into daily distinct user counts
- **Logic**: Truncates event timestamps to daily boundaries and creates distinct counts of user addresses per day. Maintains dimensional attributes including chain identifier, user type classification, market sector, business segment, and product identifier. Applies chain availability filtering to ensure data quality and completeness. Creates the foundation dataset of daily unique users that will be aggregated into monthly windows.
- **Key fields**: `timestamp` (daily), `chain`, `user_type`, `product_id`, `user_address` (distinct per day)

### Component C: HyperLogLog sketch creation
- **Purpose**: Creates memory-efficient approximate distinct count structures for daily user data
- **Logic**: Converts daily user lists into HyperLogLog sketches with 15-bit precision, enabling efficient approximate counting when merging across time windows. Groups daily data by timestamp, chain, user type, and product dimensions while creating HLL sketches for each user set. This approach allows for scalable distinct counting across large datasets without storing individual user identifiers.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for each day to capture monthly active users
- **Logic**: Generates a datespine covering all days from the first recorded user activity to the present. For each day in the datespine, creates a window spanning that day and the previous 29 days (total 30 days). Uses a self-join approach where each target day is joined with all days in its 30-day lookback period. This ensures every day has a complete 30-day window even if some days had no user activity.
- **Key fields**: `timestamp` (target day), `joinday` (days within the 30-day window)

### Component E: Dimensional breakdowns
- **Purpose**: Calculates MAU across different dimensional views for comprehensive analysis
- **Logic**: Creates four separate dimensional breakdowns from the windowed data. Project-level breakdown merges all HLL sketches regardless of dimensions to show overall FRAX MAU. Chain-level breakdown maintains chain separation to show MAU per blockchain. User-type breakdown groups by user classification to show MAU by user category. Product-level breakdown separates by product identifier to show MAU per product offering. Each breakdown nullifies non-relevant dimensional fields and merges HLL sketches within the remaining dimensions.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id` (contextual based on breakdown), `user_mau` (extracted from merged HLL)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with multiple analytical views. Each record represents the MAU count for a specific day, dimension type, and dimensional values.
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily boundary logic based on block timestamps truncated to day level. Monthly partitioning for efficient incremental processing with 30-day rolling windows calculated for each day.
- **Final calculation**: Final MAU values are extracted from merged HyperLogLog sketches using approximate distinct counting. The `finalize_metric_user_mau` macro applies standard formatting, fills missing days with zeros to maintain continuous time series, and applies project-specific metadata. Incremental processing includes safety margins and lookback periods to handle late-arriving data and ensure calculation accuracy.

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

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

Frax Ether

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown