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 Active loans Methodology

## 1. Overview

Active loans measures the value of user deposits that are lent out to borrowers within Jupiter Lend. It tracks the portion of deposits that are actively accruing interest, serving as a primary indicator of the protocol's capital utilization. This metric is critical for assessing the lending platform's ability to generate revenue, as interest payments from these loans constitute the core income for both the protocol and the supply-side participants.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: Loan and supply activity extraction

- **Purpose**: Capture all fundamental changes to the lending pool state.
- **Logic**: `Operate` instructions are parsed from the `Liquidity` program to extract borrow and supply amounts for each asset. These instructions identify specific token accounts and represent the raw transactional data required to build a ledger of outstanding balances.
- **Key fields**: `timestamp`, `token_address`, `borrow_amount`, and `supply_amount`.

### Component B: Interest rate parameter tracking

- **Purpose**: Maintain the historical record of interest rate curves for each asset.
- **Logic**: `UpdateRateDataV1` and `UpdateRateDataV2` instructions are parsed to identify the interest rate model parameters. This includes tracking utilization kinks and the specific interest rates defined at zero utilization, at the kinks, and at maximum utilization. These parameters are used to dynamically calculate the cost of borrowing between any two operations.
- **Key fields**: `kink`, `rate_at_utilization_kink`, `rate_at_utilization_max`, and `rate_at_utilization_zero`.

### Component C: Interest accrual and balance calculation

- **Purpose**: Calculate the continuous growth of outstanding debt through compound interest.
- **Logic**: All instructions are ordered chronologically per asset. For the interval between any two instructions, a utilization rate is calculated as the ratio of total borrowed assets to total supplied assets. The appropriate interest rate is derived from the active rate curve. Compound interest is then accrued to the outstanding loan balance based on the time delta between instructions. This ensures that active loans reflect both the principal borrowed and the interest owed.
- **Key fields**: `active_loan_balance`, `interest_accrued`, and `utilization`.

### Component D: USD conversion and daily aggregation

- **Purpose**: Standardize the active loan values into a common currency for reporting.
- **Logic**: The final active loan balance for each token is captured at the end of each day. These values are normalized by the decimal precision of the respective asset. The normalized amounts are then multiplied by end-of-day price feeds to determine the total USD value of all active loans.
- **Key fields**: `timestamp`, `token_address`, and `active_loans` (in USD).

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

Value of loans currently outstanding to borrowers.

JupiterJUP

Active loans

Active loans

Competitive landscape