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

## 1. Overview

Compound fees represent the total fees generated by the Compound protocol, calculated as the sum of protocol revenue (fees retained by the protocol) and supply-side fees (fees paid to liquidity suppliers). This metric combines data from both Compound V2 and V3, which use different calculation methodologies based on their distinct architectural approaches. V2 calculates fees from interest accrual events and reserve factors, while V3 uses supply/borrow rates and market indices.

## 2. Data sources

The calculation uses several key data sources:
- **Compound V2 interest events**: Parsed `AccrueInterest` events from CEther, CErc20, and CErc20Delegator contracts on Ethereum, containing accumulated interest amounts
- **Compound V2 reserve factor events**: Parsed `NewReserveFactor` events from CEther, CErc20, and CErc20Delegator contracts on Ethereum, containing reserve factor updates
- **Compound V3 protocol states**: Daily snapshots of protocol state data including supply rates, borrow rates, base supply indices, base borrow indices, total supply base, and total borrow base
- **Market configuration data**: Protocol state data mapping market contracts to underlying token addresses for both V2 and V3
- **Token metadata**: Token information including decimal places and symbols for proper scaling and identification
- **End-of-day price feeds**: Daily USD price data for all underlying tokens to enable currency conversion

## 3. Step-by-step calculation

### Component A: Compound V2 revenue calculation
- **Purpose**: Calculates protocol revenue and supply-side fees from V2 lending markets using interest accrual events
- **Logic**: Extracts `AccrueInterest` events from all V2 market contracts (CEther, CErc20, CErc20Delegator) containing the `interestAccumulated` field. Matches each interest event with the appropriate reserve factor by using temporal logic - finding reserve factor updates where the interest event timestamp falls between the reserve factor update timestamp and the next update timestamp. Applies the reserve factor split where protocol revenue equals reserve factor multiplied by accrued interest, and supply-side fees equal one minus reserve factor multiplied by accrued interest. Only calculates fees when the temporal matching logic correctly identifies the applicable reserve factor
- **Key fields**: `interestAccumulated` from accrual events, `newReserveFactorMantissa` from reserve factor events (scaled by dividing by 10^18), calculated `revenue` and `fees_supply_side` amounts

### Component B: Compound V3 revenue calculation  
- **Purpose**: Calculates protocol revenue and supply-side fees from V3 lending markets using supply/borrow rates and indices
- **Logic**: Extracts daily protocol state snapshots containing supply rates, borrow rates, base supply indices, base borrow indices, total supply base, and total borrow base. Calculates daily averages of these rates and converts rates to daily values by multiplying by seconds per day. Normalizes indices by dividing by 10^15 for proper scaling. Calculates supply-side fees as supply rate multiplied by base supply index multiplied by total supply base. Calculates gross interest income as borrow rate multiplied by base borrow index multiplied by total borrow base. Derives protocol revenue by subtracting supply-side fees from gross interest income. Sets any negative revenue values to zero as they represent protocol expenses rather than revenue
- **Key fields**: `supply_rate`, `borrow_rate`, `baseSupplyIndex`, `baseBorrowIndex`, `totalSupplyBase`, `totalBorrowBase` from protocol states, calculated `revenue` and `fees_supply_side`

### Component C: Market metadata integration
- **Purpose**: Maps market contract addresses to underlying token information for both V2 and V3
- **Logic**: Joins revenue calculations with market configuration data that maps each market contract address to its underlying token address. For V2, extracts underlying token addresses from market state data. For V3, extracts denomination token addresses. Adds token symbols and market names by joining with token metadata using both token address and chain identifiers
- **Key fields**: `account_address` (market contract), `token_address` (underlying asset), `token_symbol`, `account_name` (market identifier)

### Component D: Decimal and currency conversion
- **Purpose**: Normalizes token amounts and converts to USD values
- **Logic**: Corrects for token decimal places by dividing raw amounts by 10 raised to the power of the token's decimal places. Converts corrected amounts to USD by multiplying with end-of-day token prices. Joins with price data using token address, chain, and timestamp as matching keys. Ensures consistent daily time boundaries by truncating all timestamps to day level
- **Key fields**: Token `decimals` for scaling, `price_usd` from price feeds, USD-denominated `revenue` and `fees_supply_side`

### Final aggregation
- **Combining components**: Unions V2 and V3 revenue calculations after applying market metadata and currency conversion to both streams. Maintains separate identification of protocol version and business segment information
- **Currency conversion**: All amounts converted to USD using end-of-day price feeds matched by token address, chain, and daily timestamp
- **Time aggregation**: All data aggregated to daily boundaries using day-truncated timestamps, with V3 data pre-aggregated using daily averages of rates and indices
- **Final calculation**: Total fees calculated as the sum of protocol revenue and supply-side fees for each market and day: `total_fees = revenue + fees_supply_side`. Results include breakdowns by chain, protocol version, market, and token for detailed analysis

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

Total value users pay to use a protocol (gross fees, user-paid fees).

CompoundCOMP

Fees

Fees

Competitive landscape

Chain breakdown