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

## 1. Overview

The Gamma Strategies fees metric measures the total fees collected by Gamma hypervisor vaults across multiple chains and protocols. This metric aggregates fees from both v1 and v2 hypervisor implementations, where v1 fees are extracted directly from rebalance events, while v2 fees are calculated by applying protocol fee rates to token transfers sent to fee collection wallets. The metric answers the business question: "How much total fee revenue is generated by Gamma's liquidity management vaults on a daily basis?"

## 2. Data sources

The calculation relies on several types of blockchain data and external feeds:

- **Hypervisor rebalance events**: Parsed `Rebalance` events from v1 Uniswap hypervisor contracts on Ethereum, Polygon, Optimism, and Arbitrum containing direct fee amount data
- **Token transfer events**: Standard ERC20 `Transfer` events from multiple chains showing token movements to fee collection wallets
- **Fee rate events**: Parsed `ZeroBurn` events from v2 hypervisor contracts (Uniswap, Zyberswap, QuickSwap) across chains that emit fee rate information
- **Hypervisor creation events**: Parsed `HypeAdded` events from hypervisor factory contracts used for version classification
- **Deposit events**: Parsed `Deposit` events from v1 hypervisor contracts used to identify token pair associations
- **End-of-day price feeds**: Token price data for USD conversion
- **Token metadata**: Decimal place information for amount normalization

## 3. Step-by-step calculation

### Component A: V1 hypervisor fees
- **Purpose**: Extract direct fee amounts from v1 hypervisor rebalance operations
- **Logic**: Parse `Rebalance` events from v1 Uniswap hypervisor contracts across Ethereum, Polygon, Optimism, and Arbitrum. Each rebalance event contains `feeAmount0` and `feeAmount1` fields representing fees collected in each token of the pair. Create separate records for each token amount, joining with token address mappings to identify which specific tokens are involved. Filter to only include hypervisors classified as v1 based on version dimension data.
- **Key fields**: `feeAmount0` and `feeAmount1` from rebalance events, `block_timestamp` for timing, `address` for hypervisor identification, token addresses for the pair

### Component B: V2 hypervisor protocol yields
- **Purpose**: Identify protocol fee distributions from v2 hypervisors to fee collection wallets
- **Logic**: Monitor token transfers where v2 hypervisors are the sender and specific protocol fee wallet addresses are the recipient. Each chain has designated fee wallet addresses (e.g., Ethereum uses `0xdee9e378e483ab862d93364069ae381377bb2899` for Uniswap). Filter transfers to only include those originating from hypervisors classified as v2 version. Capture the token address and transfer amount for each protocol yield distribution.
- **Key fields**: `from_address` (hypervisor), `to_address` (fee wallet), `token_address`, `value` (transfer amount), `block_timestamp`

### Component C: Protocol fee rate tracking
- **Purpose**: Maintain time-based fee rate information for v2 hypervisor fee calculations
- **Logic**: Parse `ZeroBurn` events from v2 hypervisor contracts which emit fee rate updates. Track changes in fee rates over time and create interval periods using window functions with `lead()` to determine when each rate is applicable. Handle the current period by setting the end timestamp to a far future date. Only record fee rate changes when the rate actually differs from the previous value.
- **Key fields**: `fee` field from ZeroBurn events representing the rate, `block_timestamp` for rate change timing, interval boundaries for rate application

### Component D: Hypervisor version classification
- **Purpose**: Determine whether each hypervisor should be processed as v1 or v2
- **Logic**: Use `HypeAdded` events from factory contracts to identify hypervisor creation, applying block number thresholds to distinguish versions. Hypervisors created before specific block numbers are classified as v1, while those after are v2. Different chains have different version split block numbers (e.g., Ethereum at block 16071971, Arbitrum at 41418947). Some chains have additional v2 hypervisors from other protocols like Zyberswap and QuickSwap.
- **Key fields**: `hype` address from factory events, `block_number` for version determination, chain-specific version split thresholds

### Component E: Token address identification
- **Purpose**: Map which token pairs are associated with each hypervisor
- **Logic**: Analyze `Deposit` events from v1 hypervisors to identify token amounts, then match these with corresponding token transfers in the same transaction to determine which token addresses correspond to `amount0` and `amount1`. Join deposit events with token transfer events on transaction hash and hypervisor address, matching deposit amounts to transfer values to establish token address mappings. Filter to ensure the two tokens in each pair are different addresses.
- **Key fields**: `amount0` and `amount1` from deposits, corresponding token addresses from transfers, `transaction_hash` for joining

### Final aggregation
- **Combining components**: Union v1 fees directly with v2 calculated fees (protocol yield amount multiplied by applicable fee rate from the time interval). Join v2 protocol yields with fee rate dimensions based on hypervisor address, chain, and timestamp falling within rate intervals.
- **Currency conversion**: Apply USD conversion using end-of-day price feeds and correct for token decimal places using the `convert_to_usd_and_correct_decimals` macro
- **Time aggregation**: Truncate all timestamps to daily granularity using `timestamp_trunc(block_timestamp, day)` and aggregate fees by day, hypervisor, chain, and token
- **Final calculation**: Sum all fee amounts after USD conversion and decimal correction, applying the `finalize_metric_fees` macro with 'fill_zeros' strategy to ensure consistent daily records across all hypervisors and time periods

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

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

Gamma StrategiesGAMMA

Fees

Fees

Competitive landscape

Chain breakdown