Swappers provide liquidity and execute trades. They receive trading fees charged for each swap.

Mean Finance is a protocol that enables users to Dollar Cost Average (DCA) any ERC20 into any ERC20 with their preferred period frequency.

Mean Finance team owns and governs the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

github

twitter

discord

website

Exchanges (DEX)

Mean Finance

# Mean Finance Fees Methodology

## 1. Overview

The Mean Finance fees metric represents the total fees generated by the Mean Finance protocol's Dollar Cost Averaging (DCA) platform. The metric is calculated by taking the protocol's collected revenue and applying a 4x multiplier, based on the business assumption that total fees are approximately four times the platform's direct revenue collection. This metric answers the question: "What are the total fees generated across Mean Finance's DCA platform and wrapped token products?"

## 2. Data sources

The calculation relies on several key blockchain data sources:

- **DCA swap events**: Parsed `Swapped` events from Mean Finance's DCAHub contracts deployed on Ethereum, Optimism, Polygon, Arbitrum, and BSC chains
- **ERC4626 factory events**: `CreateERC4626` events from multiple wrapped token factory contracts including Euler, Aave V3, and Venus protocol integrations
- **Beefy wrapper events**: `ProxyCreated` events from Beefy Wrapper factory contracts on BSC
- **Token approval events**: ERC20 `Approval` events used to identify Beefy wrapper token addresses
- **Price feed data**: End-of-day token price feeds for USD conversion
- **Token metadata**: Token decimal information for amount normalization

## 3. Step-by-step calculation

### Component A: Platform fee extraction
- **Purpose**: Extract direct platform fees collected by Mean Finance during DCA swaps
- **Logic**: The system processes `Swapped` events from DCAHub contracts across five supported chains. Each swap event contains a nested `swapInformation` structure with a `tokens` array. For each token in this array, the `platformFee` field represents the fee amount collected by the protocol in that specific token. The system cross-joins each swap event with its associated tokens to create individual fee records, capturing the timestamp, transaction details, chain information, and the raw `platformFee` amount for each token involved in the swap.
- **Key fields**: Key data includes `block_timestamp` for timing, `platformFee` for the raw fee amount, `token` address for the fee token, `address` for the DCAHub contract, and chain identification

### Component B: ERC4626 wrapped token tracking
- **Purpose**: Create a mapping of Mean Finance's wrapped token products to their underlying assets
- **Logic**: This component tracks the creation of ERC4626-compliant wrapped tokens offered by Mean Finance across multiple DeFi protocols. It monitors `CreateERC4626` events from various factory contracts including Stakeable Euler factories, standard Euler factories, Aave V3 factories across multiple chains, and Venus factories on BSC. Each creation event provides the vault address (`vault`) and underlying asset address (`asset`). For Beefy wrapper tokens on BSC, the system uses a different approach, monitoring `ProxyCreated` events and joining them with ERC20 `Approval` events to identify the token addresses associated with each proxy vault.
- **Key fields**: Critical fields include `vault` addresses (mapped to account_address), `asset` addresses (mapped to token_address), creation timestamps, and chain identifiers

### Component C: Revenue aggregation and attribution
- **Purpose**: Combine direct platform fees with fees attributed to wrapped token products
- **Logic**: This component creates a unified revenue dataset by combining fees in two ways. First, it includes all direct platform fees from DCA swaps as captured in Component A. Second, it attributes additional fees to wrapped token products by joining the platform fee data with the ERC4626 allowlist, matching on account addresses and chains. This creates a second set of records where the same platform fees are associated with the underlying tokens of wrapped products, enabling revenue attribution across different product lines.
- **Key fields**: The unified dataset includes `timestamp`, `chain`, business classification fields like `business_line` and `market_sector_id`, `account_address`, `token_address`, and the raw `revenue` amounts

### Component D: USD conversion and normalization
- **Purpose**: Convert all fee amounts to USD and normalize for different token decimal places
- **Logic**: Raw platform fee amounts are converted to USD using end-of-day price feeds matched by token address and date. The system corrects for token decimal places by dividing amounts by 10 raised to the power of the token's decimal count (e.g., dividing by 10^18 for 18-decimal tokens like ETH). This ensures all fee amounts are expressed in actual token units rather than the smallest denomination (wei equivalent) used in blockchain storage.
- **Key fields**: Converted amounts use USD-denominated `revenue` values normalized to actual token units

### Final aggregation
- **Combining components**: The converted USD revenue amounts are aggregated daily by grouping on timestamp (truncated to day), chain identifier, and product dimensions
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds matched by token address and calculation date
- **Time aggregation**: Data is aggregated to daily granularity using timestamp truncation to day boundaries
- **Final calculation**: The total fees metric is calculated by multiplying the aggregated daily revenue by a fixed multiplier of 4, implementing the business rule that total fees are approximately four times the collected platform revenue: `fees = revenue × 4`

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

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

Mean Finance

Fees

Fees

Competitive landscape

Chain breakdown