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 Active users (weekly) Methodology

## 1. Overview

Active users (weekly) is measured as the number of unique addresses that perform a lending action on HyperLend. This metric is utilized to evaluate user engagement and protocol adoption. Interactions with HyperLend are captured across various lending activities, including asset deposits, borrowing, repayments, withdrawals, flash loans, and liquidations. To prevent the misattribution of activity to intermediary router or aggregator contracts, the transaction signer is resolved as the active user. Active users (weekly) are calculated over a 7-day rolling window.

## 2. Data sources

- **Blockchain events**: `Supply`, `Borrow`, `Repay`, `Withdraw`, `FlashLoan`, and `LiquidationCall` events from `LendingPool` contracts, and transaction sender data on HyperEVM

## 3. Step-by-step calculation

### Component A: Lending event extraction

- **Purpose**: To extract all relevant lending interactions and their associated transaction hashes.
- **Logic**: `Supply`, `Borrow`, `Repay`, `Withdraw`, `FlashLoan`, and `LiquidationCall` events are parsed from `LendingPool` contracts. For each event, the block timestamp, transaction hash, and user role (such as depositor, borrower, repayer, withdrawer, or liquidator) are extracted.
- **Key fields**: `block_timestamp`, `transaction_hash`

### Component B: Transaction signer resolution

- **Purpose**: To identify the true active user by resolving the transaction signer.
- **Logic**: Extracted lending actions are joined with transaction records on HyperEVM using the transaction hash and block timestamp. The transaction signer address, represented by the transaction sender field, is resolved as the true active user address. This step is performed to filter out intermediary router, aggregator, or settlement contracts that may trigger the underlying smart contract events. Liquidations are specifically attributed to the liquidator by whom the transaction was signed.
- **Key fields**: `user_address`, `transaction_hash`, `block_timestamp`

### Component C: Weekly aggregation and deduplication

- **Purpose**: To calculate the weekly count of unique active users.
- **Logic**: User addresses are aggregated over a 7-day rolling window using UTC boundaries. Distinct user addresses are counted for each 7-day window, chain, and user type. Chain availability filters are applied to ensure only approved and active chain data is included in the final output.
- **Key fields**: `block_timestamp`, `user_address`

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

Unique revenue-generating users over a rolling 7-day window.

HyperLendHPL

Active users (weekly)

Active users (weekly)

Competitive landscape