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

## 1. Overview

Gamma Strategies revenue represents the protocol fees earned by Gamma from their automated liquidity management hypervisor contracts across multiple chains and DEX integrations. The metric combines revenue from two different hypervisor versions: v1 hypervisors where revenue is calculated as 10% of total yield generated, and v2 hypervisors where revenue is tracked through actual protocol fee transfers to designated fee wallets. This approach captures the evolution of Gamma's fee structure from estimated revenue sharing to direct protocol fee collection.

## 2. Data sources

The calculation draws from several types of blockchain event data and external sources:
- **Hypervisor creation events**: Parsed `HypeAdded` events from HypervisorFactory contracts on Ethereum, Arbitrum, Optimism, and Polygon to identify and version hypervisor accounts
- **Yield generation events**: Parsed `Rebalance` events from HypervisorV1 contracts across all supported chains containing fee amount data
- **Fee configuration events**: Parsed `ZeroBurn` events from HypervisorV2 contracts that specify dynamic protocol fee rates
- **Token transfer logs**: Ethereum, Arbitrum, Optimism, and Polygon token transfer events to track protocol fee payments to fee wallets
- **Deposit transaction data**: Parsed `Deposit` events from HypervisorV1 contracts to identify underlying token pairs for each hypervisor
- **External data**: End-of-day token price feeds for USD conversion and token metadata for decimal correction

## 3. Step-by-step calculation

### Component A: Hypervisor version identification
- **Purpose**: Classify hypervisor contracts as v1 or v2 based on deployment timing and factory contracts
- **Logic**: Extract hypervisor addresses from `HypeAdded` events across different factory contracts on Ethereum, Arbitrum, Optimism, and Polygon. Apply block number thresholds to distinguish v1 from v2 hypervisors, where hypervisors created before specific block numbers (16071971 for Ethereum, 39409888 for Optimism, etc.) are classified as v1, while later deployments are v2. Additional v2 hypervisors are identified from Zyberswap and QuickSwap factory contracts regardless of block number
- **Key fields**: `account_address` (hypervisor contract), `chain`, `account_version` (v1 or v2 classification), and `block_number` for version determination

### Component B: Token address mapping
- **Purpose**: Identify the underlying token pairs managed by each hypervisor for proper revenue attribution
- **Logic**: Analyze `Deposit` events from v1 hypervisor contracts to identify deposit amounts for token0 and token1. Cross-reference with token transfer events in the same transactions to match deposit amounts with specific token addresses. Filter for deposits where token amounts differ to ensure valid token pair identification, and verify that identified tokens are distinct addresses
- **Key fields**: `account_address` (hypervisor), `token_0_address`, `token_1_address`, and transaction-level matching between deposit amounts and transfer values

### Component C: V1 hypervisor revenue calculation
- **Purpose**: Calculate protocol revenue from v1 hypervisors using a fixed fee rate applied to yield generation
- **Logic**: Extract fee amounts from `Rebalance` events on v1 hypervisors across Ethereum, Polygon, Optimism, and Arbitrum. Capture both `feeAmount0` and `feeAmount1` fields, creating separate revenue records for each token type. Join with token address mappings to properly attribute fees to specific tokens. Apply a fixed 10% protocol fee rate to all collected fee amounts to estimate Gamma's revenue share from yield generation activities
- **Key fields**: `feeAmount0` and `feeAmount1` from rebalance events, `amount` (calculated fee), and `token_address` from dimension mapping

### Component D: V2 hypervisor protocol fee tracking
- **Purpose**: Track actual protocol fee transfers from v2 hypervisors to Gamma's fee collection wallets
- **Logic**: Monitor token transfers from v2 hypervisor addresses to designated fee wallet addresses specific to each chain and DEX integration (Uniswap, Zyberswap, QuickSwap). Fee wallets include addresses like `0xdee9e378e483ab862d93364069ae381377bb2899` for Ethereum Uniswap and `0x8beff353fcb2e288fdffbb0b2b61b4c76dc700df` for Arbitrum Zyberswap. Filter transfers to only include those from confirmed v2 hypervisor addresses to ensure accurate fee attribution
- **Key fields**: `from_address` (hypervisor), `to_address` (fee wallet), `token_address`, `value` (transfer amount), and `chain` identification

### Component E: Dynamic fee rate application
- **Purpose**: Apply time-varying protocol fee rates to v2 hypervisor fee transfers based on configuration events
- **Logic**: Extract fee rate information from `ZeroBurn` events emitted by v2 hypervisor contracts, which specify the protocol fee rate as a numeric value in the `fee` field. Create time intervals for each hypervisor's fee rate by using the current event timestamp as the start and the next event timestamp (or end of time) as the interval end. Join protocol fee transfers with fee rate intervals based on hypervisor address, chain, and timestamp ranges to apply the correct rate to each transfer
- **Key fields**: `fee_rate` from ZeroBurn events, `block_timestamp` for interval creation, and `protocol_fee_amount` as the final adjusted amount

### Final aggregation
- **Combining components**: Union v1 estimated revenue (yield amounts multiplied by 10% fee rate) with v2 actual protocol fees (transfer amounts adjusted by dynamic fee rates) to create a comprehensive revenue dataset spanning both hypervisor versions
- **Currency conversion**: Convert all revenue amounts to USD using end-of-day token price feeds, applying appropriate decimal corrections based on token metadata to ensure accurate price multiplication
- **Time aggregation**: Aggregate revenue by day using timestamp truncation, grouping by hypervisor address, chain, token, and business classification dimensions
- **Final calculation**: Sum daily revenue amounts across all hypervisors, versions, and tokens to produce total daily protocol revenue for Gamma Strategies, with zero-filling applied to ensure complete time series data for all active periods

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

Gamma StrategiesGAMMA

Revenue

Revenue

Competitive landscape

Chain breakdown