Liquidity providers deposit funds into Pharaoh and stake their LP tokens to receive PHAR tokens in proportion to their share of the votes (token incentives).

Pharaoh is a non-custodial exchange protocol built on Avalanche. Pharaoh was founded in 2023.

PHAR tokenholders own and govern the protocol. They vote which pools they wish to earn trading fees from (revenue).

website

twitter

discord

Exchanges (DEX)

Pharaoh

# Pharaoh Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the portion of trading fees that flows to liquidity providers in the Pharaoh decentralized exchange protocol. This metric measures the daily USD value of fees earned by liquidity providers across Pharaoh's V1 legacy pairs and V2 concentrated liquidity pools on Avalanche. Currently, the methodology sets supply-side fees to zero for all versions, though the infrastructure exists to allocate a 20% share to liquidity providers for V2 pools.

## 2. Data sources

- **Avalanche blockchain events**: Parsed `Swap` events from legacy pairs, `FeesCollected` events from fee collectors, and `PairCreated`/`PoolCreated` events from factory contracts
- **Fee management events**: Parsed `feeChangeV1` events from the Pharaoh command center tracking dynamic fee rate changes
- **Factory contract events**: Pool and pair creation events across V1, V2, and V3 versions providing trading pair metadata
- **End-of-day token price feeds**: USD prices for all tokens involved in trading pairs
- **Token metadata**: Token symbols and decimal precision information for amount calculations

## 3. Step-by-step calculation

### Component A: V1 legacy pair fee calculation
- **Purpose**: Calculate fees generated from swaps on V1 legacy pairs by applying dynamic fee percentages to swap amounts
- **Logic**: Extract `Swap` events from legacy pairs on Avalanche, multiply the `amount0In` and `amount1In` values by the applicable fee percentage for that pair and day. Fee percentages are tracked through `feeChangeV1` events from the command center, with default rates of 0.05% for stable pairs and 0.5% for volatile pairs set at pair creation. Fee percentages are forward-filled daily using a time series approach to ensure every day has an applicable rate for each pair.
- **Key fields**: `amount0In` and `amount1In` from swap events, dynamic `fee_percentage` from fee tracking, pair `address` for identification

### Component B: V2 concentrated liquidity pool fee collection  
- **Purpose**: Extract actual fees collected from V2 concentrated liquidity pools through fee collection events
- **Logic**: Process `FeesCollected` events from fee collector contracts, summing `feeDistAmount0` with `treasuryAmount0` for token0 fees and `feeDistAmount1` with `treasuryAmount1` for token1 fees. These events represent actual fees collected from the pools rather than calculated fees, providing a direct measurement of fee generation.
- **Key fields**: `feeDistAmount0`, `feeDistAmount1`, `treasuryAmount0`, `treasuryAmount1` from collection events, `pool` address and `fee_collector_address`

### Component C: Trading pair metadata enrichment
- **Purpose**: Enrich fee data with token addresses, decimals, and pair information for proper amount calculation and USD conversion
- **Logic**: Join fee data with trading pair information derived from factory contract events across all versions. Extract `token0_address`, `token1_address`, and their respective decimal precision from token metadata. Create human-readable pair names by concatenating token symbols.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`

### Component D: Amount normalization and USD conversion
- **Purpose**: Convert raw token amounts to decimal-adjusted values and then to USD using end-of-day prices
- **Logic**: Divide raw token amounts by 10 raised to the power of token decimals to get actual token quantities. Join with end-of-day price feeds for both tokens in each pair, multiply the decimal-adjusted amounts by their respective USD prices, and sum the USD values to get total fee value per transaction.
- **Key fields**: Decimal-adjusted `token0_amount` and `token1_amount`, `price_usd` from price feeds

### Final aggregation
- **Combining components**: Union V1 calculated fees and V2 collected fees into a single dataset, then aggregate by timestamp, chain, product type, version, and account address to get daily fee totals per trading pair or pool
- **Currency conversion**: All token amounts are converted to USD using end-of-day token prices matched by timestamp, token address, and chain
- **Time aggregation**: Fees are aggregated to daily boundaries using timestamp truncation, with all transactions within a day summed together
- **Final calculation**: Apply supply-side fee allocation percentage to determine liquidity provider share. Currently set to 0% for all versions (V1 explicitly gets 0%, V2 has a defined 20% share but is not applied in the current logic), resulting in zero supply-side fees across the protocol

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

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

PharaohPHAR

Archived

Supply-side fees

Supply-side fees

Competitive landscape