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 revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the daily revenue generated per active user on the Liquity protocol. This metric is calculated by dividing daily revenue by daily active users (DAU). Revenue comes from two fee types: borrowing fees charged when users open or adjust loans, and redemption fees charged when users redeem LUSD stablecoin for ETH. Active users are identified as addresses that interact with the borrowing functionality. This metric helps assess the protocol's monetization efficiency and user engagement value.

## 2. Data sources

The calculation relies on these underlying data sources:
- **Ethereum smart contract events**: Parsed `LUSDBorrowingFeePaid` events from the Liquity BorrowerOperations contract capturing loan origination and adjustment fees
- **Ethereum smart contract events**: Parsed `Redemption` events from the Liquity TroveManager contract capturing fees from LUSD-to-ETH redemptions
- **Token price data**: End-of-day price feeds for LUSD (0x5f98805a4e8be255a32880fdec7f6728c6568ba0) and WETH (0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) tokens
- **Token metadata**: Token decimal information for proper amount normalization

## 3. Step-by-step calculation

### Component A: Borrowing fee collection
- **Purpose**: Captures fees paid by users when opening new loans or adjusting existing positions
- **Logic**: Extracts fee data from Ethereum `LUSDBorrowingFeePaid` events emitted by the BorrowerOperations contract. Each event contains the borrower address and fee amount paid in LUSD. Events are filtered and standardized with metadata including chain (ethereum), business classification (stablecoin issuer), and version (v1). The `LUSDFee` field provides the fee amount in LUSD tokens.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for uniqueness, `borrower` address for user identification, `LUSDFee` amount in LUSD tokens

### Component B: Redemption fee collection  
- **Purpose**: Captures fees paid when users redeem LUSD tokens for ETH through the protocol's redemption mechanism
- **Logic**: Extracts fee data from Ethereum `Redemption` events emitted by the TroveManager contract. Each redemption transaction includes a fee paid in WETH tokens. Events are standardized with the same metadata structure as borrowing fees but tagged as redemption fees. The `ETHFee` field contains the fee amount in WETH.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for uniqueness, `ETHFee` amount in WETH tokens

### Component C: Revenue calculation
- **Purpose**: Converts and aggregates all fee types into daily USD revenue totals
- **Logic**: Combines borrowing fees (LUSD) and redemption fees (WETH) into a unified fee stream. Applies token decimal correction to normalize amounts to proper units. Converts token amounts to USD using end-of-day price feeds matched by date and token address. Groups fees by day using timestamp truncation to create daily revenue aggregates. Applies zero-filling for days without fee activity to maintain continuous time series.
- **Key fields**: Daily `timestamp`, `fees` amount in USD after conversion and decimal correction

### Component D: User identification
- **Purpose**: Identifies and counts unique active users interacting with the protocol daily
- **Logic**: Extracts user addresses from the `borrower` parameter in `LUSDBorrowingFeePaid` events, representing users who actively engage with the borrowing functionality. Users are classified as "Borrower" type and associated with the LUSD product. Daily distinct user counting uses HyperLogLog algorithm for efficient aggregation across multiple dimensions including project-level, chain-level, user-type, and product-level breakdowns.
- **Key fields**: `user_address` from borrower parameter, `block_timestamp` for daily grouping, classification metadata

### Final aggregation
- **Combining components**: Daily revenue totals from Component C are joined with daily active user counts from Component D by matching timestamp and dimensional attributes
- **Currency conversion**: All revenue is expressed in USD using end-of-day exchange rates applied during the fee processing stage
- **Time aggregation**: Both revenue and user metrics use daily timestamp truncation with consistent day boundary definitions
- **Final calculation**: ARPU is computed by dividing daily revenue by daily active users for each day. Days with zero users result in null ARPU values. Missing days are filled with zero values to maintain complete time series continuity. The result represents the average USD revenue generated per active user per day.

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

LiquityLQTY

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape