Users deposit funds into pools, called Hypervisors, and receive a return on investment (supply-side fees) after rebalancing.

Gamma Strategies is an asset management protocol built on Ethereum and other blockchains. Gamma Strategies was founded by an anonymous team and launched in 2020.

GAMMA tokenholders own and govern the protocol. They currently take a cut of the total return on investment & total assets under management paid by liquidity providers (revenue).

github

twitter

discord

etherscan

website

Asset management

Gamma Strategies

# Gamma Strategies Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average daily fee revenue generated per daily active user on the Gamma Strategies platform. This metric answers the question: "How much fee revenue does each active user generate on average per day?" The calculation divides total daily fees collected by the number of distinct active users, providing insight into user monetization and engagement quality across Gamma's yield aggregation services.

## 2. Data sources

The AFPU calculation relies on the following raw blockchain data:

- **Hypervisor interaction events**: Parsed `Deposit` and `Withdraw` events from Gamma Strategies hypervisor contracts deployed on Ethereum, Arbitrum, Optimism, and Polygon
- **Yield generation events**: Parsed `Rebalance` events from V1 hypervisor contracts containing fee amounts for both tokens in liquidity pairs
- **Protocol fee events**: Parsed `ZeroBurn` events from V2 hypervisor contracts that establish protocol fee rates over time
- **Token transfer events**: Blockchain transaction logs showing token movements to protocol fee collection wallets
- **Contract deployment events**: Parsed `HypeAdded` events from `HypervisorFactory` contracts to identify hypervisor versions and deployment blocks
- **Price feeds**: End-of-day token price feeds for USD conversion across all supported tokens
- **Token metadata**: Token contract information including decimal places for amount normalization

## 3. Step-by-step calculation

### Component A: Daily active user identification
- **Purpose**: Identifies and counts distinct users who interact with Gamma Strategies hypervisors each day
- **Logic**: Extracts user addresses from hypervisor interaction events across all supported chains. For `Deposit` events, captures the `sender` address as the depositing user. For `Withdraw` events, captures the `to` address as the recipient user. Groups these interactions by day using timestamp truncation and counts distinct user addresses to calculate daily active users (DAU). Supports both V1 and V2 hypervisor versions across multiple DEX integrations including Uniswap, Zyberswap, and QuickSwap.
- **Key fields**: `sender` from deposit events, `to` from withdrawal events, `block_timestamp` for daily grouping, `user_address` for distinct counting

### Component B: V1 hypervisor fee calculation  
- **Purpose**: Calculates fees generated by V1 hypervisors from yield farming activities
- **Logic**: Processes `Rebalance` events emitted by V1 hypervisor contracts when positions are rebalanced to capture trading fees. Extracts `feeAmount0` and `feeAmount1` fields representing yield generated from both tokens in the underlying liquidity pair. Links hypervisor addresses to their respective token pairs using deposit transaction analysis to identify which tokens correspond to amount0 and amount1. Aggregates fee amounts daily across all V1 hypervisors on supported chains.
- **Key fields**: `feeAmount0` and `feeAmount1` from rebalance events, `address` for hypervisor identification, `token_0_address` and `token_1_address` for token mapping

### Component C: V2 hypervisor fee calculation
- **Purpose**: Calculates fees generated by V2 hypervisors based on protocol fee distributions
- **Logic**: Identifies token transfers from V2 hypervisor contracts to specific protocol fee collection wallet addresses on each chain. These transfers represent the protocol's share of yield generated. Applies time-based protocol fee rates determined from `ZeroBurn` events, which establish fee rate changes over time. Multiplies the transfer amount by the applicable protocol fee rate to derive the total fee generated. Uses time interval logic to apply the correct fee rate based on when the transfer occurred relative to fee rate change events.
- **Key fields**: `value` from transfer events, `from_address` for hypervisor identification, `to_address` for fee wallet verification, `fee_rate` from zero burn events

### Component D: Protocol fee rate management
- **Purpose**: Tracks protocol fee rates for V2 hypervisors over time to enable accurate fee calculations  
- **Logic**: Processes `ZeroBurn` events that contain updated protocol fee rates for specific hypervisor contracts. Creates time intervals for each fee rate by using the event timestamp as the start time and the next fee rate change as the end time. Handles the initial fee rate setup and subsequent changes, ensuring each transfer can be matched to the correct fee rate based on its timestamp. Maintains separate fee rate histories for each hypervisor address and chain.
- **Key fields**: `fee_rate` from zero burn events, `block_timestamp` for interval boundaries, `account_address` for hypervisor-specific rates

### Component E: Token metadata and versioning
- **Purpose**: Provides supporting data for fee calculations including hypervisor versions and token addresses
- **Logic**: Identifies hypervisor versions (V1 or V2) based on deployment timing using `HypeAdded` events from factory contracts and predefined block number cutoffs. Maps hypervisor addresses to their underlying token pair addresses by analyzing initial deposit transactions and matching deposit amounts to transfer amounts. This mapping enables proper fee attribution to specific tokens for USD conversion.
- **Key fields**: `account_address` for hypervisor identification, `account_version` for version classification, `token_0_address` and `token_1_address` for token mapping

### Final aggregation
- **Combining components**: Daily active users from Component A and total fees from Components B and C are aggregated separately by day across all chains and hypervisor versions. V1 and V2 fees are combined into a single daily fee total after USD conversion.
- **Currency conversion**: All fee amounts are converted to USD using end-of-day price feeds matched by token address and date. Token amounts are corrected for decimal places before price multiplication to ensure accurate USD values.
- **Time aggregation**: Both user counts and fee amounts use day-level timestamp truncation with consistent timezone handling. Missing days are filled with zero values to maintain complete daily series.
- **Final calculation**: AFPU is calculated by dividing the total daily fees (in USD) by the daily active user count. Days with zero active users result in zero AFPU values. The result represents the average fee revenue generated per active user on each day across the entire Gamma Strategies platform.

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

Gamma StrategiesGAMMA

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape