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 Supply-side fees Methodology

## 1. Overview

Supply-side fees measures the portion of interest paid by borrowers that is distributed to liquidity providers within Jupiter Lend. This metric reflects the primary earnings generated by users who supply capital to the lending pools, representing the yield earned for providing liquidity to the protocol. It specifically captures the interest remaining after the protocol's fee share has been deducted.

## 2. Data sources

- **Blockchain events**: `UpdateTokenConfig`, `UpdateRateDataV1`, `UpdateRateDataV2`, and `Operate` instructions from the `Liquidity` program on Solana
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Jupiter Lend asset balance tracking

- **Purpose**: Track the volume of assets supplied and borrowed to establish the basis for interest accrual.
- **Logic**: `Operate` instructions from the `Liquidity` program are parsed to extract borrow and supply amounts for specific assets. Running balances for total supply and active loans are maintained by aggregating these operations chronologically for each account and asset.
- **Key fields**: `borrow_amount`, `supply_amount`, `mint` (asset identification)

### Component B: Jupiter Lend interest rate and utilization modeling

- **Purpose**: Determine the applicable interest rate based on market demand and protocol configuration.
- **Logic**: Utilization is calculated as the ratio of active loan balances to total supply balances. Interest rate curve parameters, including kink points and rate values at various utilization levels, are extracted from `UpdateRateDataV1` and `UpdateRateDataV2` instructions. The specific interest rate is then derived by applying the current utilization rate to the active rate model (single-kink or two-kink).
- **Key fields**: `kink`, `rate_at_utilization_kink`, `rate_at_utilization_max`, `rate_at_utilization_zero`

### Component C: Jupiter Lend interest accrual and supply-side allocation

- **Purpose**: Calculate the specific value of interest earned by liquidity providers.
- **Logic**: Compound interest is accrued between operations based on the calculated interest rate and the time elapsed since the previous event. The protocol's fee percentage is identified from `UpdateTokenConfig` instructions. Supply-side fees are calculated by multiplying the total interest accrued during the period by the supply-side share (calculated as 1 minus the protocol fee percentage).
- **Key fields**: `interest_accrued_this_period`, `fee` (protocol fee rate)

### Component D: USD conversion and aggregation

- **Purpose**: Normalize calculated fees into a common currency for reporting.
- **Logic**: Calculated asset amounts are normalized by decimal precision. These normalized values are then multiplied by end-of-day price feeds to determine the USD equivalent. All values are aggregated to a daily grain using UTC day boundaries.

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

Portion of fees distributed to service providers or supply-side participants.

JupiterJUP

Supply-side fees

Supply-side fees

Competitive landscape