Lenders deposit funds into Compound and receive interest payments from borrowers (supply-side fees).

Compound is a non-custodial lending protocol built on Ethereum. Compound was founded by Robert Leshner & Geoffrey Hayes and launched in 2017.

 COMP tokenholders own and govern the protocol. They currently take a cut of the total interest paid by borrowers (revenue). Compound’s investors include a16z, Paradigm, Polychain, etc.

governance

github

twitter

discord

etherscan

website

Lending

Compound

# Compound Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) for Compound measures the average daily revenue generated per active user across the lending protocol. This metric divides total daily protocol revenue by the number of daily active users, providing insight into user monetization efficiency. The calculation combines revenue from both Compound v2 (Ethereum) and v3 (multi-chain) versions, tracking lending activities across Ethereum, Arbitrum, Base, and Polygon networks.

## 2. Data sources

- **Compound v2 Ethereum events**: Interest accrual events (`AccrueInterest`) and reserve factor updates (`NewReserveFactor`) from CEther, CErc20, and CErc20Delegator contracts
- **Compound v2 user interaction events**: Lending activity events including `Borrow`, `Mint`, `Redeem`, and `RepayBorrow` from all contract types
- **Compound v3 multi-chain events**: Comet contract events (`SupplyCollateral`, `Supply`, `WithdrawCollateral`, `Withdraw`) across Ethereum, Arbitrum, Base, and Polygon
- **Compound v3 state data**: Market parameters including supply rates, borrow rates, supply indices, borrow indices, and total supply/borrow amounts
- **Market configuration data**: Compound v2 market definitions and v3 denomination mappings linking contract addresses to underlying tokens
- **Token metadata**: Token symbols, decimal places, and contract address mappings
- **End-of-day price feeds**: USD price data for all supported tokens across relevant blockchain networks

## 3. Step-by-step calculation

### Component A: Daily active user tracking

- **Purpose**: Count unique users interacting with Compound protocols daily across all supported chains
- **Logic**: Extract user addresses from lending events across Compound v2 and v3. For v2, capture users from `Borrow`, `Mint`, `Redeem`, and `RepayBorrow` events, identifying borrowers, depositors, withdrawers, and repayers. For v3, track users from `SupplyCollateral`, `Supply`, `WithdrawCollateral`, and `Withdraw` events across Ethereum, Arbitrum, Base, and Polygon. Aggregate to daily level by truncating event timestamps to day boundaries. Use HyperLogLog algorithm for efficient unique user counting across multiple dimensions including chain, user type, and product segments.
- **Key fields**: User addresses (`borrower`, `minter`, `redeemer`, `payer`, `dst`, `src`), block timestamps, transaction hashes, chain identifiers, and user type classifications

### Component B: Compound v2 revenue calculation

- **Purpose**: Calculate protocol revenue from Compound v2 interest accruals using reserve factor splits
- **Logic**: Process `AccrueInterest` events from CEther, CErc20, and CErc20Delegator contracts to get total interest accumulated. Match these events with reserve factor updates using time-based logic to apply correct reserve factors. For each interest accrual, multiply the `interestAccumulated` amount by the applicable `reserveFactor` to determine protocol revenue share. Use temporal matching where reserve factors apply from their update timestamp until the next update or indefinitely if no subsequent update exists. Apply decimal corrections based on underlying token specifications and convert to USD using end-of-day price feeds.
- **Key fields**: Interest amounts (`interestAccumulated`), reserve factors (`newReserveFactorMantissa`), contract addresses, block timestamps, and underlying token addresses

### Component C: Compound v3 revenue calculation

- **Purpose**: Calculate protocol revenue from Compound v3 using supply/borrow rate differentials
- **Logic**: Extract market parameters from state data including `supply_rate`, `borrow_rate`, `baseSupplyIndex`, `baseBorrowIndex`, `totalSupplyBase`, and `totalBorrowBase`. Convert rates from per-second to daily by multiplying by seconds per day (86400). Calculate daily accrued interest for borrowers as `borrow_rate * baseBorrowIndex * totalBorrowBase` and for suppliers as `supply_rate * baseSupplyIndex * totalSupplyBase`. Protocol revenue equals the difference between borrow interest collected and supply interest paid out. Apply index corrections by dividing by 10^15 for proper decimal handling. Filter out negative revenue values as expenses rather than income.
- **Key fields**: Supply and borrow rates, supply and borrow indices, total base amounts, and market denomination addresses

### Component D: Revenue aggregation and normalization

- **Purpose**: Combine v2 and v3 revenues into standardized USD amounts
- **Logic**: Merge revenue calculations from both Compound versions. Join with market dimension data to map contract addresses to underlying tokens and obtain token metadata. Apply decimal corrections by dividing raw amounts by 10^(token_decimals) to get actual token quantities. Convert token amounts to USD by multiplying with corresponding end-of-day prices from price feeds using timestamp and token address matching. Aggregate revenues across markets, chains, and versions while maintaining granular breakdowns for analysis.
- **Key fields**: Raw revenue amounts, token decimal places, price data in USD, contract names, token symbols, and chain identifiers

### Final aggregation

- **Combining components**: Sum total daily USD revenue across all markets and chains. Count total daily active users across all chains and interaction types using HyperLogLog aggregation to handle cross-chain user overlap efficiently.
- **Currency conversion**: All revenue amounts are converted to USD using end-of-day token prices matched by timestamp, token address, and chain. Price conversions occur after decimal normalization but before final aggregation.
- **Time aggregation**: All calculations use daily time boundaries created by truncating block timestamps to day level. Revenue and user counts are aggregated within these daily windows before ARPU calculation.
- **Final calculation**: Divide total daily protocol revenue (in USD) by total daily active users to compute average revenue per user. Apply gap-filling strategy to handle days with missing data and apply chain availability filters to ensure data quality and completeness across supported networks.

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

CompoundCOMP

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape