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 Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the portion of trading fees that flows to liquidity providers in Gamma Strategies' automated liquidity management hypervisors. This metric measures the value earned by users who deposit assets into Gamma's yield-generating strategies across Ethereum, Arbitrum, Optimism, and Polygon networks. The calculation methodology differs between Gamma's V1 and V2 hypervisor versions, reflecting protocol evolution and different fee distribution mechanisms.

## 2. Data sources

The calculation relies on several types of blockchain data and external feeds:
- **Smart contract events**: Parsed `Rebalance` events from V1 hypervisor contracts containing fee collection data
- **Token transfer logs**: Transfer events showing protocol fee distributions to designated fee wallet addresses
- **Factory contract events**: `HypeAdded` events from hypervisor factory contracts used for version classification
- **Fee rate events**: `ZeroBurn` events from V2 hypervisor contracts that emit protocol fee rate changes
- **Deposit events**: `Deposit` events from V1 hypervisor contracts used to identify underlying token pairs
- **External price feeds**: End-of-day token price data for USD conversion
- **Token metadata**: Information for decimal correction and standardization

## 3. Step-by-step calculation

### Component A: V1 hypervisor supply-side fees
- **Purpose**: Calculate supply-side fees for V1 hypervisors using a fixed 90% user yield rate
- **Logic**: Extract fee collection data from `Rebalance` events emitted by V1 hypervisor contracts across Ethereum, Arbitrum, Optimism, and Polygon. These events contain `feeAmount0` and `feeAmount1` fields representing fees collected in both tokens of each liquidity pair. Join with hypervisor token address mappings derived from `Deposit` event analysis to identify the underlying token addresses. Filter to only include hypervisors classified as V1 based on factory contract `HypeAdded` events and block number thresholds. Apply a fixed 90% rate to the total fee amounts to calculate the portion distributed to liquidity providers
- **Key fields**: `feeAmount0` and `feeAmount1` from rebalance events, `token_0_address` and `token_1_address` from deposit analysis, hypervisor `address` and version classification

### Component B: V2 hypervisor supply-side fees  
- **Purpose**: Calculate supply-side fees for V2 hypervisors using dynamic protocol fee rates
- **Logic**: Identify protocol fee distributions by tracking token transfers to designated fee wallet addresses on each supported chain. These transfers represent the protocol's portion of collected fees from V2 hypervisors. Match each transfer with the applicable protocol fee rate by joining with fee rate intervals derived from `ZeroBurn` events, which emit fee rate changes over time with lead/lag windowing logic. Calculate supply-side fees using the formula: protocol fee amount × (protocol fee rate - 1), where the protocol fee rate represents the total fee percentage and subtracting 1 yields the portion retained by liquidity providers
- **Key fields**: Transfer `value` to fee wallets, `fee_rate` from ZeroBurn events, time intervals for fee rate applicability

### Component C: Hypervisor classification and metadata
- **Purpose**: Classify hypervisors by version and map underlying token addresses
- **Logic**: Determine hypervisor versions using `HypeAdded` events from factory contracts combined with block number splits that delineate V1 and V2 deployment periods. Map token pair addresses for each hypervisor by analyzing `Deposit` events to identify which tokens were transferred during deposits, matching deposit amounts with transfer amounts to establish token address relationships
- **Key fields**: Hypervisor `address`, `account_version`, `token_0_address`, `token_1_address`

### Final aggregation
- **Combining components**: Union the V1 and V2 fee calculations to create a comprehensive dataset of supply-side fees across all hypervisor versions
- **Currency conversion**: Convert fee amounts to USD using end-of-day token price feeds, applying decimal corrections based on token metadata to ensure proper scaling
- **Time aggregation**: Truncate timestamps to daily boundaries and aggregate fees by day, hypervisor address, chain, and token
- **Final calculation**: Apply Token Terminal's standard finalization macro for supply-side fees, which includes filling zero values for missing days, applying metadata enrichment, and ensuring consistent formatting across the metric schema

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

Portion of fees distributed to service providers or supply-side participants.

Gamma StrategiesGAMMA

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown