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 Revenue Methodology

## 1. Overview

The Jito revenue metric calculates the daily revenue earned by Jito from MEV (Maximum Extractable Value) tips and validator rewards on Solana. This metric represents 3% of total fees collected by Jito, which is a governance-decided revenue share that was fully implemented starting March 10th, 2025. The metric answers the business question: "How much revenue does Jito generate daily from its MEV infrastructure services?"

## 2. Data sources

The calculation relies on multiple raw data sources:

- **Solana blockchain events**: Native SOL token transfer events from the Solana blockchain, specifically transfers directed to Jito's designated fee collection addresses
- **External MEV data**: Historical MEV tip data collected through Jito's scraper system, containing validator tips, Jito tips, tip counts, and tipper information
- **Price feeds**: End-of-day SOL token price feeds for USD conversion
- **Token metadata**: Solana (SOL) token specifications including decimal precision and contract addresses

## 3. Step-by-step calculation

### Component A: Historical fee collection (pre-2025)
- **Purpose**: Captures MEV tips and validator rewards from Jito's scraper system for historical periods
- **Logic**: Extract daily MEV tip data from the Jito scraper, which tracks `validator_tips` and `jito_tips` amounts. Combine these two components to calculate total daily fees. Filter to only include data before January 1st, 2025, and deduplicate records by selecting the most recent insertion for each day to handle any scraper updates or corrections
- **Key fields**: `validator_tips` (rewards paid to validators), `jito_tips` (tips collected by Jito), `daily_timestamp` (aggregation date), `count_mev_tips` (number of tip transactions), `tippers` (unique tippers count)

### Component B: Current fee collection (2025 onwards)
- **Purpose**: Tracks on-chain fee collection through direct blockchain monitoring of native transfers to Jito fee addresses
- **Logic**: Monitor Solana native token transfers where the recipient address matches any of eight specific Jito fee collection addresses. Filter transfers to only include those occurring on or after January 1st, 2025. Convert amounts from lamports (Solana's smallest unit) to SOL by dividing by 1e9. Aggregate transfers daily by summing all amounts received by the fee addresses within each day
- **Key fields**: `amount` (transfer amount in lamports), `to_address` (recipient fee collection address), `block_timestamp` (transaction timestamp), `transaction_signer` (sender address)

### Component C: Fee aggregation and standardization
- **Purpose**: Combines historical and current fee data into a unified dataset with consistent schema
- **Logic**: Union the historical scraped data with the current on-chain transfer data. Both sources are normalized to daily granularity with consistent field names including `timestamp`, `chain_id` (set to 'solana'), `product_id` (set to 'mevtips'), `token_address` (SOL contract address), and `fees` (daily fee amount in SOL). Apply incremental processing logic to handle data updates efficiently
- **Key fields**: `fees` (total daily fees in SOL), `timestamp_grain` (set to 'day'), `chain_id`, `product_id`, `token_address`

### Component D: USD conversion
- **Purpose**: Converts SOL-denominated fees to USD values for standardized reporting
- **Logic**: Join the fee data with end-of-day SOL price feeds using the daily timestamp. Multiply the SOL fee amounts by the corresponding USD price to get USD-denominated fee values. The conversion uses end-of-day prices to ensure consistency with other Token Terminal metrics
- **Key fields**: `fees` (now in USD), price data from external feeds

### Component E: Revenue calculation
- **Purpose**: Applies the governance-decided revenue share percentage to calculate Jito's actual revenue
- **Logic**: Multiply the USD fee amounts by 0.03 (3%) to calculate Jito's revenue share. Apply a date filter to only include data from March 10th, 2025 onwards, which represents when the revenue sharing mechanism was fully implemented. Earlier fee data exists but revenue sharing was not consistently applied
- **Key fields**: `revenue` (fees × 0.03), date filter for implementation cutoff

### Final aggregation
- **Combining components**: The revenue calculation flows sequentially through fee aggregation, USD conversion, and revenue percentage application. No additional joining is required as each step processes the same daily records
- **Currency conversion**: USD conversion occurs before revenue calculation using end-of-day SOL prices matched to the daily timestamp of each fee record
- **Time aggregation**: All data is aggregated to daily boundaries using timestamp truncation to day precision. Time zones are handled consistently across all data sources
- **Final calculation**: Final revenue = (Total daily fees in SOL × End-of-day SOL price × 0.03) for dates >= March 10th, 2025. Missing days are filled with zero values to ensure complete time series coverage

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

JitoJTO

Revenue

Revenue

Competitive landscape