Liquidity providers (LPs) deposit funds into Convex Finance and receive a return on investment (supply-side fees).

Convex Finance is an asset management and staking protocol built on Ethereum. Convex Finance launched in May 2021.

CVX tokenholders own and govern the protocol. They currently take a cut of the total yield generated (revenue).

governance

github

twitter

discord

etherscan

website

Asset management

Convex Finance

# Convex Finance Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average amount of fees earned per daily active user on the Convex Finance platform. This metric answers the business question "How much fee revenue does each active user generate on average?" and is calculated by dividing total daily fees by the number of daily active users. Convex Finance is a yield optimization platform built on top of Curve Finance, allowing users to earn enhanced rewards on their Curve LP tokens.

## 2. Data sources

- **Token transfer events**: Parsed `Transfer` events from Ethereum, Arbitrum, and Polygon networks to track user deposits and yield distributions
- **End-of-day token price feeds**: USD price data for various reward tokens including CRV, FPIS, FXS, and 3CRV tokens
- **Token metadata**: Decimal precision information for proper token amount calculations across different ERC-20 tokens

## 3. Step-by-step calculation

### Component A: User identification and daily active users

- **Purpose**: Identify Convex Finance users and calculate daily active user counts
- **Logic**: Users are identified through token transfer events where tokens are sent TO Convex's main deposit account address `0x989aeb4d175e16225e39e87d0d97a3360524ad80`. The `from_address` in these transfers represents user addresses making deposits. All identified users are classified as "Depositor" type in the asset management sector and yield aggregator business segment. Daily active users are calculated by counting distinct user addresses per day using timestamp truncation to day-level granularity. The system uses HyperLogLog approximation with 15-bit precision for efficient distinct counting across multiple dimensions including project-level, chain-level, user-type-level, and product-level breakdowns.
- **Key fields**: `block_timestamp` (truncated to day), `from_address` as `user_address`, `to_address` (filtered to deposit account), `user_type` (always "Depositor")

### Component B: Fee collection from multiple yield sources

- **Purpose**: Track and aggregate all fee/yield sources earned by the Convex protocol
- **Logic**: Fees are collected from multiple yield streams tracked through token transfer events between specific Convex contract addresses. The main sources include: Curve incentives on Ethereum (CRV tokens transferred from voter proxy `0x989aeb4d175e16225e39e87d0d97a3360524ad80` to booster `0xf403c135812408bfbe8713b5a23a04b3d48aae31`), Curve trading fees on Ethereum (3CRV tokens from booster to reward pool `0x7091dbb7fcba54569ef1387ac89eb2a5c9f6d2ea`), Curve incentives on Arbitrum and Polygon (CRV tokens from Curve accounts to voter proxy addresses), Frax FPIS incentives (FPIS tokens to fee deposit accounts), and Frax FXS incentives with special handling where the protocol yield is divided by 0.17 to calculate total yield. Each yield stream has specific start dates and uses predefined contract addresses for filtering.
- **Key fields**: `block_timestamp`, `value` as `amount`, `token_address`, `account_name` (yield source description), `from_address` and `to_address` (contract addresses)

### Component C: Fee processing and USD conversion

- **Purpose**: Standardize fee amounts and convert to USD for consistent calculation
- **Logic**: Raw token amounts are processed through decimal correction to account for different token precision levels, then converted to USD using end-of-day price feeds. The conversion process matches token addresses with price feed data to get appropriate exchange rates. Timestamps are truncated to day-level granularity to align with the daily calculation period. Zero-filling is applied for days with no fee activity to maintain complete time series data.
- **Key fields**: `timestamp` (day-level), `fees` (USD-converted amounts), `token_address`, `chain_id`

### Final aggregation

- **Combining components**: Daily active user counts and daily fee totals are joined by timestamp and relevant dimensional attributes (chain, product, user type). The system ensures both metrics use the same day-level timestamp truncation for proper alignment.
- **Currency conversion**: All fee amounts are converted to USD using end-of-day token price feeds, with proper decimal adjustment based on each token's precision (typically 18 decimals for most ERC-20 tokens).
- **Time aggregation**: Both user and fee data use day-level boundaries determined by truncating block timestamps to the day level in UTC timezone.
- **Final calculation**: AFPU is calculated as the quotient of total daily fees in USD divided by the count of daily active users, using the `calculate_arpu` macro which handles the division logic and manages edge cases like zero users. The result represents the average fee revenue generated per active user on each day.

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

Convex FinanceCVX

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape