# PrimeFi Lending Revenue Methodology

## 1. Overview

Revenue measures the portion of interest income generated by PrimeFi Lending that is retained by the protocol treasury. In this lending model, borrowers pay interest on their loans, the majority of which is distributed to lenders (supply-side participants), while a specific percentage—determined by the reserve factor—is redirected to the protocol. This metric serves as a primary indicator of the protocol's earning power from its lending services before the deduction of operating expenses or token incentives.

## 2. Data sources

- **Blockchain events**: `ReserveInitialized` and `ReserveFactorChanged` events from `LendingPoolConfigurator` contracts, and ERC-20 token transfer events on XDC
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Market identification

- **Purpose**: To identify and map the active lending markets within PrimeFi Lending.
- **Logic**: All lending markets are identified by parsing `ReserveInitialized` events from `LendingPoolConfigurator` contracts. This process establishes the relationship between underlying assets and their corresponding protocol-specific assets, including `aTokens` (interest-bearing certificates), `sTokens` (stable debt tokens), and `vTokens` (variable debt tokens).
- **Key fields**: `underlying_token_address`, `atoken_address`, `vtoken_address`, and `pool_address`.

### Component B: Reserve factor tracking

- **Purpose**: To determine the percentage of interest income allocated to the protocol treasury for each market.
- **Logic**: Protocol take rates are extracted from `ReserveFactorChanged` events emitted by `LendingPoolConfigurator` contracts. In instances where specific events are not present for a given period, a default reserve factor of 10% is applied. These values are normalized by a decimal precision of 10,000 and are filled forward to ensure a continuous daily record of fee configurations for every active market.
- **Key fields**: `reserve_factor` and `token_address`.

### Component C: Fee transfer extraction

- **Purpose**: To capture the raw amount of revenue collected by the protocol treasury.
- **Logic**: Protocol revenue is identified by monitoring ERC-20 token transfers of `aTokens` to the designated protocol treasury address. These transactions are filtered to include only "mint" operations, where the transfer originates from the null address and the recipient matches the treasury address. This mechanism follows the Aave V2 pattern, where protocol fees are realized through the continuous minting of interest-bearing tokens to the treasury.
- **Key fields**: `amount` (value), `to_address` (treasury), and `from_address` (null address).

### Component D: USD conversion and aggregation

- **Purpose**: To normalize revenue values into a common currency (USD) for reporting.
- **Logic**: Collected fee amounts are normalized by the decimal precision of the underlying asset. The resulting quantities are multiplied by end-of-day price feeds to determine the USD value. For specific assets such as `psXDC`, price data is mapped from corresponding wrapped assets (e.g., `WXDC`) to ensure accurate valuation. Data is aggregated at a daily granularity using UTC day boundaries.
- **Key fields**: `timestamp`, `token_address`, and `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.

PrimeFi Lending

Revenue

Revenue

Chain breakdown