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 Revenue Methodology

## 1. Overview

Compound revenue measures the total USD value of fees collected by the Compound protocol from lending and borrowing activities. The metric answers: "How much revenue does Compound generate daily from its lending protocol operations?" 

The calculation combines data from two protocol versions with different architectures: Compound v2 uses interest accrual events with configurable reserve factors to determine fee splits, while Compound v3 calculates revenue as the spread between total borrower payments and supplier rewards using protocol state data. Both are converted to USD and aggregated daily.

## 2. Data sources

- **Compound v2 blockchain events**: Parsed Ethereum `AccrueInterest` events from CEther, CErc20, and CErc20Delegator contracts that record interest accumulation
- **Reserve factor events**: Parsed Ethereum `NewReserveFactor` events from Compound v2 contracts that track fee split configuration changes
- **Compound v3 protocol state**: Daily snapshots of protocol state containing supply rates, borrow rates, supply/borrow indices, and total supply/borrow amounts
- **Market configuration data**: Mapping of Compound market contract addresses to underlying token addresses and symbols
- **Token metadata**: Token decimal information for proper amount scaling
- **End-of-day price feeds**: Daily USD price data for all supported tokens to enable currency conversion

## 3. Step-by-step calculation

### Component A: Compound v2 revenue calculation
- **Purpose**: Calculate protocol revenue from Compound v2 markets using interest accrual events and reserve factors
- **Logic**: Extract interest amounts from `AccrueInterest` events fired when interest is accumulated on v2 markets. Match each interest event with the appropriate reserve factor based on timestamp - using the most recent `NewReserveFactor` event that occurred before the interest accrual. Apply temporal logic to ensure correct reserve factor assignment: if an interest event occurs after a reserve factor update but before the next update, use that reserve factor; if it's the latest update, use that factor for all subsequent events. Calculate protocol revenue by multiplying the accrued interest amount by the reserve factor
- **Key fields**: `interestAccumulated` from interest events (raw interest amount), `newReserveFactorMantissa` from reserve factor events (scaled by 18 decimals), `block_timestamp` for temporal matching, `address` for contract identification

### Component B: Compound v3 revenue calculation  
- **Purpose**: Calculate protocol revenue from Compound v3 markets using protocol state parameters
- **Logic**: Extract daily averages of key protocol parameters including supply rates, borrow rates, base supply index, base borrow index, total supply base, and total borrow base from protocol state snapshots. Correct index values by dividing by 10^15. Calculate total interest paid by borrowers as borrow rate multiplied by borrow index and total borrowed amount. Calculate total interest paid to suppliers as supply rate multiplied by supply index and total supplied amount. Compute net protocol revenue as the difference between borrower payments and supplier payments. Filter out negative revenue values, treating them as expenses rather than revenue
- **Key fields**: `supply_rate` and `borrow_rate` (per-second rates converted to daily), `baseSupplyIndex` and `baseBorrowIndex` (index values for interest calculation), `totalSupplyBase` and `totalBorrowBase` (total amounts supplied and borrowed)

### Component C: Market data enrichment
- **Purpose**: Add market context and token information to enable proper decimal correction and USD conversion
- **Logic**: Join revenue data with market configuration to map contract addresses to underlying token addresses and symbols. Add token decimal information to enable proper scaling of raw amounts. Include market version information to distinguish between v2 and v3 calculations
- **Key fields**: `account_address` (contract address), `token_address` (underlying token), `token_symbol` (token identifier), `decimals` (scaling factor), `version` (v2 or v3)

### Final aggregation
- **Combining components**: Union v2 and v3 revenue calculations into a single dataset, maintaining separate version identifiers and market-specific information
- **Currency conversion**: Convert token amounts to USD by first correcting for decimal places (dividing by 10^token_decimals), then multiplying by end-of-day USD price for the corresponding date and token
- **Time aggregation**: Aggregate all revenue by day using timestamp truncation to daily boundaries, ensuring consistent daily reporting across both protocol versions
- **Final calculation**: Sum all USD-converted revenue amounts by day across all markets and versions to produce the daily total Compound protocol revenue metric

*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.

CompoundCOMP

Revenue

Revenue

Competitive landscape

Chain breakdown