Stakers deposit funds into Jito and receive a return on investment in the form of staking rewards (supply-side revenue). Note: fee, revenue and supply-side fees currently only include validator tips.

Jito is a non-custodial liquid staking protocol built on Solana. Jito was founded by Zano Sherwani and Lucas Bruder and launched in 2022.

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

github

twitter

discord

website

Liquid staking

Jito

# Jito Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Jito measures the approximate count of unique users who interacted with Jito's products within a rolling 30-day window. The metric captures user activity across two main Jito products: liquid staking (JitoSOL) and MEV tips. The calculation uses HyperLogLog probabilistic data structures for efficient approximate distinct counting across large datasets and provides dimensional breakdowns by project, chain, user type, and product.

## 2. Data sources

The calculation relies on the following raw Solana blockchain data sources:

- **Solana native token transfers**: SOL transfers to specific Jito fee recipient accounts to identify MEV tip activity
- **Solana token mint transactions**: JitoSOL token mint events representing liquid staking deposits  
- **Solana token burn transactions**: JitoSOL token burn events representing liquid staking withdrawals
- **Jito fee accounts**: A predefined list of 8 Solana addresses that receive MEV tips and protocol fees
- **JitoSOL token contract**: The J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn token address for liquid staking operations

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify and classify user interactions with Jito products from raw Solana transactions
- **Logic**: Extract transaction signers from three types of Solana blockchain events. For liquid staking activity, capture JitoSOL token mint transactions (deposits) and token burn transactions (withdrawals), classifying signers as "Depositor" or "Withdrawer" user types respectively and assigning them to the "liquidstaking" product. For MEV tip activity, capture native SOL transfers to the 8 predefined Jito fee recipient accounts, classifying signers as "Tipper" user type and assigning them to the "mevtips" product. Filter out transactions where the signer is one of the Jito fee accounts themselves to avoid counting internal protocol operations as user activity.
- **Key fields**: `transaction_signer` or `signer` (user address), `block_timestamp` (transaction time), `transaction_id` (unique transaction identifier), `token_address` (for token operations), `to_address` (for transfer destinations)

### Component B: Daily user aggregation  
- **Purpose**: Aggregate unique users by day across different dimensions while preparing for efficient monthly rollups
- **Logic**: Group user activity by daily timestamp boundaries, chain (always "solana" for Jito), user type ("Depositor", "Withdrawer", "Tipper"), and product ("liquidstaking", "mevtips"). Use distinct selection on user addresses to ensure each user is counted only once per day per dimension combination. Initialize HyperLogLog sketches for each daily aggregation to enable efficient approximate distinct counting when rolling up to monthly windows. Apply chain availability filtering to ensure data quality.
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain` (always "day"), `chain` (blockchain identifier), `user_type` (user classification), `product_id` (product identifier), `user_dau` (unique user address)

### Component C: Rolling window construction
- **Purpose**: Create a 30-day rolling window framework to calculate monthly active users for each day
- **Logic**: Generate a complete datespine covering all days from the earliest available data to the current date minus one day. For each day in the datespine, create a 30-day lookback window by generating timestamps for the previous 29 days plus the current day. Join this window structure with the daily HLL user data to create a comprehensive dataset where each row represents one day's contribution to a specific target date's MAU calculation. This ensures complete time coverage without gaps even when no user activity occurred on certain days.
- **Key fields**: `timestamp` (target date for MAU calculation), `joinday` (contributing day within the 30-day window), `hll` (HyperLogLog sketch for unique user counting)

### Component D: Dimensional MAU breakdowns
- **Purpose**: Calculate monthly active users across four different dimensional cuts for analytical flexibility
- **Logic**: Merge HyperLogLog sketches across the 30-day window for each dimensional breakdown. Create four separate aggregations: project-level MAU (combining all dimensions with no filters), chain-level MAU (grouped by chain), user type-level MAU (grouped by user type like "Depositor", "Withdrawer", "Tipper"), and product-level MAU (grouped by product like "liquidstaking", "mevtips"). For each breakdown, use HyperLogLog merge and extract functions to calculate the approximate distinct user count. Set unused dimension fields to null for each breakdown type to maintain consistent schema structure.
- **Key fields**: `dimensions` (breakdown type identifier), `chain_id` (for chain-level breakdown), `user_type` (for user type breakdown), `product_id` (for product breakdown), `user_mau` (final MAU count)

### Final aggregation
- **Combining components**: Union all four dimensional breakdown results into a single dataset with consistent schema structure, where each row represents a MAU value for a specific date and dimensional cut
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 30-day windows calculated for each day, with monthly partitioning for efficient data management and incremental processing
- **Final calculation**: Apply the finalize_metric_user_mau macro to standardize the output schema, add metadata fields like data_id ("jito"), and implement the fill_zeros strategy to ensure continuous time series data even for periods with no user activity

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

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

JitoJTO

Active users (monthly)

Active users (monthly)

Competitive landscape