Overcollateralized borrowers deposit funds into Liquity and receive LUSD stablecoin.

Liquity is a non-custodial stablecoin protocol built on Ethereum. Liquity was founded by Robert Lauko & Rick Pardoe and launched in 2020.

LQTY tokenholders own & govern the protocol. They currently take all of the total borrow & redemption fees paid by borrowers (revenue). Liquity’s investors include Lemniscap, Polychain, Alameda Research, etc.

github

twitter

discord

etherscan

website

Stablecoin issuers

Liquity

# Liquity Average fees per user (AFPU) Methodology

## 1. Overview

The Average Fees Per User (AFPU) metric measures the average daily fee revenue generated per active borrower in the Liquity protocol. This metric provides insight into user monetization efficiency by dividing total daily fee revenue by the number of unique active borrowers. The calculation combines two types of fees (borrowing and redemption) and tracks user activity through borrowing operations to compute a daily average.

## 2. Data sources

The AFPU calculation relies on several key data sources:

- **Ethereum smart contract events**: Parsed `LUSDBorrowingFeePaid` events from the Liquity v1 BorrowerOperations contract and `Redemption` events from the TroveManager contract
- **Transaction metadata**: Ethereum transaction timestamps, hashes, and log indices for event ordering and deduplication
- **Token data**: LUSD token contract address (`0x5f98805a4e8be255a32880fdec7f6728c6568ba0`) and WETH contract address (`0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`)
- **External price data**: End-of-day price feeds for LUSD and WETH tokens to enable USD conversion
- **Token metadata**: Decimal precision information for proper unit conversion from wei to standard token amounts

## 3. Step-by-step calculation

### Component A: Borrowing fee collection
- **Purpose**: Captures fees paid by borrowers when taking out LUSD loans
- **Logic**: Extracts borrowing fee data from `LUSDBorrowingFeePaid` events emitted by the BorrowerOperations contract. Each event contains the borrower address and the fee amount paid in LUSD. The data is filtered to distinct events using block timestamp, transaction hash, and log index to prevent duplicates. Events are timestamped to daily grain and associated with the LUSD token address and categorized as "Interest" business line fees.
- **Key fields**: `borrower` (fee payer address), `LUSDFee` (fee amount in LUSD wei), `block_timestamp` (event timing)

### Component B: Redemption fee collection  
- **Purpose**: Captures fees paid during LUSD redemption operations for ETH
- **Logic**: Extracts redemption fee data from `Redemption` events emitted by the TroveManager contract. Each event represents a redemption where LUSD holders exchange their tokens for ETH, paying a fee in ETH. The ETH fee amounts are captured and timestamped to daily grain, associated with the WETH token address and categorized as "Interest" business line fees.
- **Key fields**: `ETHFee` (fee amount in ETH wei), `block_timestamp` (event timing)

### Component C: Fee USD conversion and aggregation
- **Purpose**: Converts all fees to USD and aggregates them daily
- **Logic**: Both LUSD and ETH fee amounts are converted from wei to standard token units using decimal correction. The amounts are then converted to USD using end-of-day price feeds. All fee types are combined and aggregated by day to produce total daily fee revenue across the protocol.
- **Key fields**: `amount` (fee amount in USD), `timestamp` (daily aggregation boundary)

### Component D: Daily active user tracking
- **Purpose**: Identifies and counts unique active borrowers per day
- **Logic**: Uses the same `LUSDBorrowingFeePaid` events to identify borrower addresses as active users. Each borrower address that pays a fee on a given day is considered an active user. Users are classified as "Borrower" type and associated with the "lusd" product. Daily unique counts are calculated using HyperLogLog sketches for efficient distinct counting across different dimensional breakdowns.
- **Key fields**: `borrower` (user address), `user_type` (set to "Borrower"), `timestamp` (daily grain)

### Component E: User aggregation with HLL
- **Purpose**: Efficiently counts distinct users across multiple dimensions
- **Logic**: Applies HyperLogLog sketching to enable scalable distinct user counting. Creates separate aggregations for project-level, chain-level, user-type-level, and product-level breakdowns. Each breakdown maintains separate HLL sketches that can be merged to provide accurate distinct counts across different analytical dimensions.
- **Key fields**: `user_dau` (distinct user count), `dimensions` (aggregation level), `hll` (HyperLogLog sketch)

### Final aggregation
- **Combining components**: The fees component provides total daily fee revenue in USD, while the user component provides daily active user counts. These are joined by date using the `calculate_arpu` macro which performs the division calculation.
- **Currency conversion**: All fees are converted to USD using end-of-day price feeds at the time of the fee payment, ensuring consistent currency representation across different fee types (LUSD and ETH).
- **Time aggregation**: Both fees and users are aggregated to daily boundaries using timestamp truncation to day grain, ensuring alignment for the division calculation.
- **Final calculation**: AFPU is calculated as total daily fees (in USD) divided by the number of daily active users (unique borrowers). The result represents the average fee revenue generated per active borrower on each day. Gap-filling logic ensures continuous time series data with zero values for days with no activity.

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

LiquityLQTY

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape