website

twitter

discord

Exchanges (DEX)

Shadow

# Shadow Fees Methodology

## 1. Overview

The ShadowExchange fees metric measures the total daily fees generated across ShadowExchange's decentralized exchange protocol on the Sonic blockchain. This metric combines traditional trading fees with additional revenue streams from liquidity incentives and governance activities. The calculation aggregates both supply-side fees (earned by liquidity providers) and protocol revenue (earned by the protocol and governance participants) to provide a comprehensive view of the platform's fee generation.

## 2. Data sources

The methodology utilizes several categories of raw blockchain data:

- **Swap events**: Parsed `Swap` events from both v2 pairs and v3 pools on the Sonic blockchain, containing token amounts and user information
- **Pool creation events**: `PairCreated` and `PoolCreated` events that establish valid trading pairs and initial fee parameters
- **Fee parameter events**: Various governance events that update fee rates and protocol fee splits over time, including `SetPairFee`, `SetPairFeeSplit`, `FeeAdjustment`, and `SetFeeProtocol` events
- **Reward claim events**: `ClaimRewards` events from both v2 and v3 gauge contracts representing liquidity provider incentives
- **Voting bribe events**: `VotesIncentivized` events from the FeeDistributor contract representing governance revenue
- **Transaction data**: Sonic blockchain transaction records for user identification
- **External data**: End-of-day token price feeds for USD conversion and token metadata including symbols and decimal places

## 3. Step-by-step calculation

### Component A: Trading volume extraction
- **Purpose**: Extract and standardize trading volumes from swap events across v2 and v3 protocols
- **Logic**: The system processes `Swap` events from v2 pairs and `Pool_Swap` events from v3 pools. For v2, token amounts are calculated as the difference between input and output amounts (`amount0In - amount0Out`). For v3, amounts are taken directly from the event data. All amounts are converted to their proper decimal representation using token metadata and filtered through transaction data to identify actual users
- **Key fields**: `token0_amount`, `token1_amount`, `account_address`, `block_timestamp`, `transaction_hash`

### Component B: Fee parameter tracking
- **Purpose**: Maintain historical records of fee rates and protocol fee splits for accurate fee calculations
- **Logic**: The system tracks two key parameters over time. Fee tiers are established at pool creation (defaulting to 0.3% for v2 pairs) and updated through governance events. Protocol fee splits determine what portion of fees goes to the protocol versus liquidity providers, tracked through fee split events. Both parameters use block-based ordering to ensure trades are matched with the correct historical parameters
- **Key fields**: `fee_tier`, `fee_split`, `pool_address`, `block_number`, `order_id`

### Component C: USD conversion and volume calculation
- **Purpose**: Convert token amounts to USD values and calculate final trading volumes with anti-manipulation protection
- **Logic**: For each swap, both token amounts are converted to USD using end-of-day price feeds. To prevent price manipulation attacks, the system uses the lesser of the two USD values as the trading volume. This approach ensures that artificially inflated prices in one token cannot inflate the volume calculation. Volumes are aggregated daily across all pools
- **Key fields**: `trading_volume`, `timestamp`, `chain`, `product_id`

### Component D: LP reward processing
- **Purpose**: Capture liquidity provider incentives from gauge contracts
- **Logic**: The system processes `ClaimRewards` events from both v2 and v3 gauge contracts on the Sonic blockchain. xShadow token rewards are excluded as they represent governance tokens rather than fee-based rewards. Remaining reward tokens are converted to USD using end-of-day price feeds and proper decimal corrections, then aggregated daily
- **Key fields**: `amount`, `token_address`, `timestamp`, `chain_id`

### Component E: Voting bribe revenue
- **Purpose**: Capture governance-related revenue from voting incentives
- **Logic**: The system processes `VotesIncentivized` events from the FeeDistributor contract, which represent payments to incentivize voting behavior. xShadow token addresses are converted to Shadow addresses for proper price lookup. These amounts are converted to USD using end-of-day price feeds and aggregated daily
- **Key fields**: `amount`, `token_address`, `timestamp`, `chain_id`

### Final aggregation
- **Combining components**: The methodology combines two main fee streams. Supply-side fees equal trading volumes multiplied by fee tiers and the liquidity provider portion (1 - fee split), plus LP reward claims. Revenue equals trading volumes multiplied by fee tiers and the protocol portion (fee split), plus voting bribe revenue
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds at the time of the transaction, with token decimals properly corrected
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation to the day level
- **Final calculation**: Total fees equal supply-side fees plus revenue, representing the complete fee generation across trading activities, liquidity incentives, and governance mechanisms

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

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

ShadowSHADOW

Fees

Fees

Competitive landscape