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

StaFi is a non-custodial liquid staking protocol built on Ethereum and other blockchains. StaFi was co-founded by Liam Young and launched in 2020.

FIS tokenholders own and govern the protocol. They currently take a cut of the total staking rewards earned by the protocol (revenue). StaFi’s investors include Focus Labs, Spark Digital Capital & a number of angel investors.

governance

github

twitter

discord

website

Liquid staking

StaFi

# StaFi Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the count of unique users who interacted with the StaFi liquid staking protocol within any 30-day rolling window. This metric tracks user engagement and protocol adoption by counting distinct addresses that performed staking or unstaking activities. The calculation uses probabilistic HyperLogLog counting to efficiently handle large user sets while maintaining accuracy, and provides dimensional breakdowns by project level, blockchain, user type, and product.

## 2. Data sources

- **Ethereum event logs**: Parsed `TokensMinted` events from the StaFi RETHToken contract capturing staking/deposit activities
- **Ethereum event logs**: Parsed `Unstake` events from the StaFi StafiWithdraw contract capturing withdrawal/unstaking activities  
- **Transaction metadata**: Block timestamps, transaction hashes, and log indices associated with each event
- **Event parameters**: User addresses extracted from event parameters (`to` field for deposits, `from` field for withdrawals)

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identifies all users who interacted with StaFi protocol through staking or unstaking activities
- **Logic**: Extracts user addresses from StaFi smart contract events on Ethereum. `TokensMinted` events identify users making deposits or stakes, while `Unstake` events identify users making withdrawals. Each user address is classified as either "Depositor" or "Withdrawer" based on the event type. The component captures transaction metadata including block timestamp, transaction hash, and log index for each interaction.
- **Key fields**: User addresses from `to` parameter (depositors) and `from` parameter (withdrawers), block timestamps for timing, transaction hashes for deduplication

### Component B: Daily active user calculation
- **Purpose**: Aggregates user interactions into daily unique active user counts
- **Logic**: Groups user interactions by day using timestamp truncation to daily boundaries. Deduplicates user addresses within each day to count unique daily active users. Preserves dimensional information including chain, user type (Depositor/Withdrawer), market sector, business segment, and product identifiers. Applies chain availability filters to ensure data quality.
- **Key fields**: Daily timestamp boundaries, unique `user_address` per day, `chain` identifier, `user_type` classification

### Component C: HyperLogLog sketch creation  
- **Purpose**: Creates memory-efficient probabilistic sketches of daily user sets for scalable unique counting
- **Logic**: Converts daily active user lists into HyperLogLog sketches using 15-bit precision. Groups data by timestamp, chain, user type, and product dimensions. HyperLogLog sketches allow efficient merging across time periods while maintaining cardinality estimates for unique user counts.
- **Key fields**: Daily HyperLogLog sketches (`hll`), timestamp groupings, dimensional breakdowns

### Component D: Date spine and rolling window construction
- **Purpose**: Ensures complete time series coverage and creates 30-day rolling windows for MAU calculation
- **Logic**: Generates a complete date spine covering the analysis period from the earliest user interaction to the current date. For each day in the spine, creates a 30-day rolling window by generating timestamps for the current day plus the previous 29 days. Joins the rolling window dates with the daily HyperLogLog sketches to collect user data across each 30-day period.
- **Key fields**: Date spine timestamps, 30-day window boundaries (`joinday`), joined HyperLogLog sketches

### Final aggregation
- **Combining components**: Merges HyperLogLog sketches across each 30-day rolling window using HyperLogLog merge operations. Extracts the final cardinality estimate to get the count of unique users within each 30-day period
- **Dimensional breakdowns**: Creates separate MAU calculations for four different dimensional views: project-level (overall), chain-level, user-type-level (Depositor vs Withdrawer), and product-level. Each breakdown groups and merges HyperLogLog sketches accordingly while nullifying unused dimensions
- **Time aggregation**: Maintains daily timestamp granularity where each day represents the MAU for the 30-day window ending on that date. Uses monthly partitioning for efficient incremental processing
- **Final calculation**: The MAU value represents the estimated count of unique user addresses that performed any staking or unstaking activity within the 30-day rolling window ending on each date, calculated using probabilistic HyperLogLog cardinality estimation

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

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

StaFiFIS

Active users (monthly)

Active users (monthly)

Competitive landscape