Lenders deposit assets into HyperLend and earn interest paid by borrowers (supply-side fees); the protocol keeps a share of that interest as revenue, set per reserve by the reserve factor.

HyperLend is a non-custodial lending protocol on HyperEVM. Core Pools are an Aave v3.2 friendly fork (pooled lending); Isolated Pools are a FraxLend v3 fork (isolated pair markets).

HPL tokenholders own and govern HyperLend, the credit and liquidity layer for the Hyperliquid ecosystem.

twitter

website

github

discord

Lending

HyperLend

# HyperLend Revenue Methodology

## 1. Overview

The portion of fees retained by HyperLend, as determined by its protocol take rate, is measured as Revenue. Earnings generated by the protocol from borrower interest, flash loan premiums, and liquidation penalties are reflected by this metric before operating expenses are deducted. These earnings are accumulated by the HyperLend Core lending pool and are directed to the protocol treasury.

## 2. Data sources

- **Blockchain events**: `ReserveInitialized`, `ReserveFactorChanged`, and `LiquidationProtocolFeeChanged` events from `LendingPoolConfigurator` contracts, `FlashLoan`, `LiquidationCall`, and `MintedToTreasury` events from `LendingPool` contracts, ERC-20 `Transfer` events for aTokens, and treasury accrual state reads, covering HyperEVM
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Market initialization and parameter tracking

- **Purpose**: Identify active lending markets and track reserve factors and liquidation protocol fee factors over time.
- **Logic**: Active lending markets (reserves) are identified using `ReserveInitialized` events from `LendingPoolConfigurator` contracts. The reserve factor, which determines the protocol's share of borrower interest, is extracted from `ReserveFactorChanged` events from `LendingPoolConfigurator` contracts and filled forward daily. Similarly, the liquidation protocol fee factor is extracted from `LiquidationProtocolFeeChanged` events from `LendingPoolConfigurator` contracts and filled forward daily to map the protocol's share of liquidation bonuses.
- **Key fields**: `asset`, `newReserveFactor`, `newFee`

### Component B: Interest revenue calculation

- **Purpose**: Calculate the protocol's share of interest paid by borrowers.
- **Logic**: Cumulative treasury mints are aggregated from `MintedToTreasury` events from `LendingPool` contracts and filled forward daily. These cumulative mints are combined with the still-accruing treasury balance extracted from treasury accrual state reads to determine the total cumulative interest accrued to the protocol. Daily interest revenue is calculated as the day-over-day delta of this total cumulative interest.
- **Key fields**: `amountMinted`, `treasury_accruals`

### Component C: Flash loan revenue calculation

- **Purpose**: Capture the protocol's share of flash loan premiums.
- **Logic**: Flash loan premium amounts are extracted from `FlashLoan` events from `LendingPool` contracts. Protocol revenue from flash loans is calculated by multiplying the total premium amount by a hardcoded split of `0.0004`.
- **Key fields**: `premium`

### Component D: Liquidation revenue calculation

- **Purpose**: Capture the protocol's share of liquidation bonuses.
- **Logic**: Liquidation events are identified using `LiquidationCall` events from `LendingPool` contracts. The protocol's liquidation fee is captured through the tracking of ERC-20 `Transfer` events where the collateral aToken is transferred from the liquidated user's address to the protocol treasury address.
- **Key fields**: `amount`, `user`, `liquidator`

### Component E: USD conversion and aggregation

- **Purpose**: Normalize revenue values to USD and aggregate them.
- **Logic**: Daily revenue amounts from interest, flash loans, and liquidations are combined. The raw asset amounts are normalized by decimal precision using asset metadata and multiplied by end-of-day asset prices to convert them to USD. The final values are aggregated daily with UTC day boundaries.
- **Key fields**: `revenue`

*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.

HyperLendHPL

Revenue

Revenue

Competitive landscape