Jupiter aggregates liquidity from multiple non-custodial exchanges. Integrators set custom fees. Liquidity providers deposits funds into the perpetual exchange. Both receive fees from traders (supply-side fees).

Jupiter is a non-custodial DEX aggregator and exchange for perpetual contracts built on Solana. Jupiter was founded by an pseudonymous founder meow and launched in 2021.

JUP token holders own and govern the protocol. They currently take a cut of the total perpetual and integrator trading fees paid by traders (revenue). Jupiter's investors include White Hilt Capital, etc.


github

twitter

discord

website

DEX aggregators

Jupiter

# Jupiter Fees Methodology

## 1. Overview

Fees measures the total value paid by users to access Jupiter’s suite of decentralized finance products. This includes trading fees from the Jupiter Ultra aggregator, swap and position fees from Jupiter Perps, accrued interest and protocol fees from Jupiter Lend, execution fees from Jupiter DCA and Jupiter Limit Order, and keeper fees from Jupiter ApePro. The metric serves as a primary indicator of the economic activity and value capture generated across the Jupiter ecosystem.

## 2. Data sources

- **Blockchain events**: `FeeEvent` events from `SwapV6` programs, `AddLiquidityEvent`, `PoolSwapEvent`, `RemoveLiquidityEvent`, `LiquidateFullPositionEvent`, `DecreasePositionEvent`, and `IncreasePositionEvent` events from `Perps` programs, `UpdateTokenConfig`, `UpdateRateDataV1`, `UpdateRateDataV2`, and `Operate` instructions from `Liquidity` programs, and native or SPL token transfers on Solana
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Jupiter Ultra fee extraction

- **Purpose**: Captures fees generated by the Jupiter swap aggregator.
- **Logic**: Fees are extracted from two primary sources within the `SwapV6` program. First, `FeeEvent` events are parsed to capture direct fee amounts in the input asset. Second, `ExactOutRouteV2`, `RouteV2`, `SharedAccountsExactOutRouteV2`, and `SharedAccountsRouteV2` instructions are processed to calculate platform fees by multiplying the instruction amount by the platform fee basis points.

### Component B: Jupiter Perps fee collection

- **Purpose**: Captures fees associated with perpetual trading and liquidity provision.
- **Logic**: Multiple event types from the `Perps` program are aggregated. `AddLiquidityEvent` fees are calculated as the difference between the USD value of the deposited asset and the minted liquidity asset. `PoolSwapEvent` fees are determined by subtracting the output amount after fees from the gross output amount. `RemoveLiquidityEvent` fees are derived by applying the fee percentage (calculated from the ratio of token amounts before and after fees) to the total USD withdrawal value. Finally, position-related fees are extracted directly from `LiquidateFullPositionEvent`, `DecreasePositionEvent`, and `IncreasePositionEvent` events.

### Component C: Jupiter Lend interest and fee accrual

- **Purpose**: Measures the interest paid by borrowers and protocol-level fees within the lending market.
- **Logic**: Interest is calculated using a compound interest model based on `Operate` instructions from the `Liquidity` program. Running balances for borrowed and supplied assets are maintained to determine utilization rates. Interest rate curves are reconstructed using parameters from `UpdateRateDataV1` and `UpdateRateDataV2` instructions to determine the applicable rate at any given timestamp. Interest is accrued between operations based on the time elapsed and the calculated rate. Protocol-specific fees are further identified via `UpdateTokenConfig` instructions and applied to the interest amounts.

### Component D: Jupiter DCA and Jupiter Limit Order fee tracking

- **Purpose**: Captures execution fees for automated and conditional order types.
- **Logic**: Native SOL and SPL token transfers are monitored for specific fee recipient accounts associated with the `Jupiter DCA` and `Jupiter Limit Order` products. Transfers are filtered to exclude self-transfers where the transaction signer matches the recipient. Fees are identified by the destination account and aggregated by asset and product.

### Component E: Jupiter ApePro keeper fee calculation

- **Purpose**: Identifies fees earned by keepers within the Jupiter ApePro terminal.
- **Logic**: Account activity is monitored for the specific Jupiter ApePro keeper account. Daily fees are determined by calculating the positive change in the account balance between consecutive transactions. These balance increases represent the accumulation of fees paid to the program's automated infrastructure.

### Component F: USD conversion and final aggregation

- **Purpose**: Normalizes all collected fee components into a single USD-denominated metric.
- **Logic**: All extracted fee amounts are normalized by their respective asset decimal precision. These values are multiplied by end-of-day price feeds to determine the USD value. The resulting figures are aggregated by day, chain, and product to produce the total Fees metric.

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

Total value users pay to use a protocol (gross fees, user-paid fees).

JupiterJUP

Fees

Fees

Competitive landscape