website

twitter

discord

Exchanges (DEX)

Shadow

# Shadow Revenue Methodology

## 1. Overview

ShadowExchange revenue represents the total USD value of fees collected by the protocol from trading activities and voting incentives. The metric combines two revenue streams: trading fees calculated as a percentage of trading volume based on fee tiers and fee splits, and voting bribe revenue from incentivized governance voting. This provides a comprehensive view of ShadowExchange's revenue generation across its decentralized exchange and governance features.

## 2. Data sources

- **Sonic blockchain swap events**: Parsed `Pair_Swap_event` logs from ShadowExchange V2 pair contracts and `Pool_Swap_event` logs from ShadowExchange V3 pool contracts containing token amounts and trade details
- **Sonic blockchain fee configuration events**: `Factory_PairCreated_event`, `Factory_PoolCreated_event`, `PairFactory_SetPairFee_event`, `PairFactory_SetPairFeeSplit_event`, and related events that establish and modify fee parameters for trading pairs
- **Sonic blockchain voting bribe events**: `VotesIncentivized_event` logs from FeeDistributor contracts containing bribe amounts and token addresses
- **Sonic blockchain transaction records**: Transaction data used to identify user addresses and validate successful transactions
- **End-of-day token price feeds**: USD price data for all traded tokens and bribe tokens for currency conversion
- **Token metadata**: Token symbols, decimal places, and contract addresses for proper amount calculations and token identification

## 3. Step-by-step calculation

### Component A: Trading volume extraction
- **Purpose**: Extract and normalize trading volume data from swap events across ShadowExchange V2 and V3
- **Logic**: Parse `Pair_Swap_event` from V2 contracts and `Pool_Swap_event` from V3 contracts on Sonic blockchain. For V2 events, calculate net token amounts as `amount0In - amount0Out` and `amount1In - amount1Out`. For V3 events, use `amount0` and `amount1` directly. Take absolute values to get traded amounts regardless of swap direction. Join with trading pair metadata to identify `token0_address`, `token1_address`, and decimal information. Filter to successful transactions only and exclude any denylisted pairs
- **Key fields**: `token0_amount`, `token1_amount`, `account_address` (pool address), `transaction_hash`, `block_timestamp`

### Component B: Fee parameter tracking
- **Purpose**: Track time-sensitive fee tiers and fee splits for each trading pair
- **Logic**: Extract fee tier settings from factory creation events and fee adjustment events. For V2 pairs, default fee tier is 3000 (0.3%) unless factory default is changed. Track fee tier changes through `PairFactory_SetPairFee_event` and pool-specific adjustments. Track fee splits (protocol's share of fees) through `PairFactory_SetPairFeeSplit_event` and pool creation events. Use window functions with `order_id` (formatted as block_number + log_index) to create time intervals, ensuring correct fee parameters are applied based on when trades occurred
- **Key fields**: `fee_tier` (as decimal percentage), `fee_split` (protocol's share as decimal), `next_block_timestamp` (interval boundaries)

### Component C: Trading volume USD conversion
- **Purpose**: Convert token amounts to USD values and apply anti-manipulation filtering
- **Logic**: Join trading volume data with end-of-day price feeds for both tokens in each pair. Calculate USD values by multiplying token amounts by respective prices. Apply price manipulation protection by taking the minimum USD value between `token0_amount * token0_price` and `token1_amount * token1_price`. This prevents inflated volumes from manipulated token prices. Aggregate volumes daily by chain, product, fee tier, and fee split parameters
- **Key fields**: `trading_volume` (USD value), `fee_tier`, `fee_split`

### Component D: Voting bribe revenue extraction
- **Purpose**: Calculate revenue from voting incentive bribes in the governance system
- **Logic**: Extract `VotesIncentivized_event` logs from FeeDistributor contracts containing bribe amounts and reward token addresses. Convert xSHADOW token addresses (`0x5050bc082ff4a74fb6b0b04385defddb114b2424`) to SHADOW token addresses (`0x3333b97138d4b086720b5ae8a7844b1345a33333`) for consistent pricing. Apply decimal corrections by dividing amounts by `10^token_decimals`. Convert to USD using end-of-day price feeds. Aggregate by day, chain, and product
- **Key fields**: `amount` (bribe amount in USD), `token_address`, `block_timestamp`

### Final aggregation
- **Combining components**: Combine trading fee revenue and voting bribe revenue using union all operation. Trading fee revenue calculated as `trading_volume * fee_tier * fee_split`. Voting bribe revenue used directly as protocol revenue
- **Currency conversion**: All amounts converted to USD using end-of-day price feeds matched by token address, chain, and day
- **Time aggregation**: All data aggregated to daily boundaries using `timestamp_trunc(block_timestamp, day)`
- **Final calculation**: Total revenue = sum of (trading_volume × fee_tier × fee_split) + sum of voting_bribe_amounts, aggregated by day, chain, and product. The `finalize_metric_revenue` macro applies final formatting and fills zeros for missing days

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

ShadowSHADOW

Revenue

Revenue

Competitive landscape