website

twitter

discord

Exchanges (DEX)

Shadow

# Shadow Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the portion of protocol revenue that goes to liquidity providers in the ShadowExchange decentralized exchange. This metric combines two revenue streams: the liquidity provider portion of trading fees (after protocol fees are deducted) and additional rewards distributed through gauge contracts. The calculation captures fees earned by LPs from both organic trading activity and protocol incentive programs, excluding native governance token emissions.

## 2. Data sources

- **Blockchain events**: Parsed Sonic blockchain `Swap` events from both v2 Pair contracts and v3 Pool contracts
- **Factory events**: Sonic blockchain `PairCreated` and `PoolCreated` events that establish trading pairs and initial parameters
- **Parameter adjustment events**: Various Sonic blockchain events tracking fee changes over time including `SetPairFee`, `SetPairFeeSplit`, `FeeAdjustment`, and `SetFeeProtocol` events
- **Reward distribution events**: Sonic blockchain `ClaimRewards` events from both v2 Gauge and v3 GaugeV3 contracts
- **Transaction data**: Sonic blockchain transaction records for user address identification
- **External data**: End-of-day token price feeds for USD conversion and token metadata including decimals and symbols

## 3. Step-by-step calculation

### Component A: Trading fee revenue

- **Purpose**: Calculate the portion of trading fees that goes to liquidity providers after protocol fees are deducted
- **Logic**: Extract all `Swap` events from both v2 Pair contracts and v3 Pool contracts on Sonic. For v2, calculate token amount changes using the difference between `amount0In` minus `amount0Out` and `amount1In` minus `amount1Out`. For v3, use the `amount0` and `amount1` fields directly. Join swap events with trading pair data from Factory creation events to identify token addresses and decimals. Apply current fee parameters by matching swap block numbers against fee parameter change intervals tracked from various fee adjustment events. Calculate trading volume using the lesser USD value between the two tokens in each swap to prevent price manipulation. Multiply trading volume by `fee_tier` (fee rate) and `(1 - fee_split)` where `fee_split` represents the protocol's share, leaving the remainder for liquidity providers
- **Key fields**: `amount0In`, `amount0Out`, `amount1In`, `amount1Out` for v2; `amount0`, `amount1` for v3; `fee_tier` (fee rate as decimal), `fee_split` (protocol fee portion)

### Component B: Gauge reward distributions

- **Purpose**: Capture additional rewards paid to liquidity providers through gauge incentive programs
- **Logic**: Extract `ClaimRewards` events from both v2 Gauge and v3 GaugeV3 contracts on Sonic blockchain. Filter out xShadow governance token rewards (address `0x5050bc082ff4a74fb6b0b04385defddb114b2424`) to focus only on monetary incentives. Convert reward amounts to USD using end-of-day price feeds and correct for token decimals using metadata. Aggregate by day, chain, and product version
- **Key fields**: `reward` (token address), `amount` (reward quantity before decimal correction)

### Component C: Fee parameter tracking

- **Purpose**: Maintain historical records of fee rates and protocol fee splits for accurate fee calculations
- **Logic**: Track fee parameter changes over time using block-based intervals. For fee rates, combine initial settings from Factory creation events with updates from various fee adjustment events. For v2 pairs, default to 3000 basis points (0.3%) if no explicit fee is set before the first factory default change. For protocol fee splits, track changes from `SetPairFeeSplit`, `PoolCreated`, and `SetFeeProtocol` events. Create time intervals between parameter changes and apply the appropriate rates based on when each swap occurred
- **Key fields**: `fee` (fee rate in basis points), `feeSplit` or `feeProtocol` (protocol share), block-based `order_id` for chronological ordering

### Final aggregation

- **Combining components**: Union trading fee revenue and gauge rewards using the same timestamp, chain, and product dimensions. Both components are aggregated daily and measured in USD
- **Currency conversion**: Apply end-of-day token price feeds to convert all amounts to USD. For trading volumes, use the lesser of the two token USD values in each swap to prevent price manipulation
- **Time aggregation**: Truncate all timestamps to daily boundaries using the `day` granularity. Track both components with `timestamp_grain` set to 'day'
- **Final calculation**: Sum the trading fee component (`trading_volume * fee_tier * (1 - fee_split)`) with the LP rewards component (`amount` in USD) to get total supply-side fees. Apply chain availability filtering and standardization through the finalize metric macro

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

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

ShadowSHADOW

Supply-side fees

Supply-side fees

Competitive landscape