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 Liquidation volume Methodology

## 1. Overview

Liquidation volume is defined as the total USD value of debt covered in liquidations across all lending markets on HyperLend. This metric is utilized to assess the risk management, health, and solvency of the lending protocol, as well as the activity level of liquidators by whom the platform is secured during market downturns. Liquidation events occurring within the HyperLend Core lending pool are captured. The volume is calculated based on the value of the debt assets repaid by liquidators to close undercollateralized positions.

## 2. Data sources

- **Blockchain events**: `ReserveInitialized` events from `LendingPoolConfigurator` contracts and `LiquidationCall` events from `LendingPool` contracts, covering HyperEVM
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Market identification

- **Purpose**: Active lending markets (reserves) and their associated asset addresses are identified.
- **Logic**: `ReserveInitialized` events from `LendingPoolConfigurator` contracts are parsed to map underlying assets to their corresponding interest-bearing asset (aToken) and debt asset (vToken) addresses. This mapping is established to define the universe of active lending markets for the protocol.
- **Key fields**: `asset`, `aToken`, and `variableDebtToken` representing the underlying asset and its corresponding interest-bearing and debt assets.

### Component B: Liquidation event extraction

- **Purpose**: Raw liquidation transactions and the amount of debt covered are captured.
- **Logic**: `LiquidationCall` events from `LendingPool` contracts are parsed to identify liquidation transactions. These events are joined with the identified lending markets to verify the collateral and debt assets. The debt amount repaid by the liquidator is extracted from the event payload.
- **Key fields**: `debtToCover` (representing the amount of debt repaid), `debtAsset` (representing the debt asset address), `collateralAsset` (representing the collateral asset address), and `block_timestamp`.

### Component C: Decimal normalization and USD conversion

- **Purpose**: Debt amounts are normalized by asset decimals and converted to USD.
- **Logic**: The raw debt amounts are normalized by the decimal precision of the respective debt assets using asset metadata. The normalized debt amounts are then multiplied by the end-of-day price of the debt asset to determine the USD value of the liquidation volume.
- **Key fields**: `debt_to_cover` (normalized) and `price_usd` (from end-of-day price feeds).

### Component D: Daily aggregation

- **Purpose**: Liquidation volume is aggregated to a daily granularity.
- **Logic**: The USD-denominated liquidation values are summed by day, chain, and asset. Missing days are filled with zeros to ensure a continuous time series.
- **Key fields**: `timestamp` and `liquidation_volume`.

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

USD value of debt covered or positions force-closed in liquidations.

HyperLendHPL

Liquidation volume

Liquidation volume

Competitive landscape