website

twitter

discord

Exchanges (DEX)

Shadow

# Shadow Average revenue per user (ARPU) Methodology

## 1. Overview

ARPU (Average Revenue Per User) measures the average daily revenue generated per active user on the ShadowExchange protocol. This metric is calculated by dividing total daily revenue by the number of daily active users. The metric helps assess user monetization efficiency and protocol performance on a per-user basis. ARPU combines revenue from trading fees and voting bribes, divided by users who perform trading or flash loan activities.

## 2. Data sources

The ARPU calculation relies on several key data sources:

- **Swap events**: Parsed `Swap` events from ShadowExchange v2 `Pair` contracts and v3 `Pool` contracts on Sonic blockchain, containing token amounts and user interactions
- **Flash loan events**: Parsed `Flash` events from ShadowExchange v3 `Pool` contracts on Sonic blockchain, capturing flash loan activities
- **Voting bribe events**: Parsed `VotesIncentivized` events from ShadowExchange `FeeDistributor` contracts on Sonic blockchain, representing bribe payments
- **Transaction records**: Sonic blockchain transaction data linking events to originating wallet addresses
- **Factory events**: `PairCreated` and `PoolCreated` events from ShadowExchange Factory contracts establishing trading pairs and initial parameters
- **Fee parameter events**: `SetPairFee`, `FeeAdjustment`, `SetPairFeeSplit`, and `SetFeeProtocol` events tracking fee tier and fee split changes over time
- **End-of-day price feeds**: Token price data in USD for currency conversion
- **Token metadata**: Token decimals, symbols, and addresses for proper amount calculation and pair identification

## 3. Step-by-step calculation

### Component A: Daily active users calculation
- **Purpose**: Identify and count unique users who interact with the protocol daily
- **Logic**: Extract unique user addresses from both `Swap` events (trading activities) and `Flash` events (flash loan activities). The user address is determined from the `from_address` field of the underlying transaction, representing the wallet that initiated the activity. Users are deduplicated across both activity types to count each unique address only once per day. Daily aggregation uses timestamp truncation to day boundaries.
- **Key fields**: `user_address` from transaction records, `block_timestamp` for daily grouping

### Component B: Trading fee revenue calculation
- **Purpose**: Calculate revenue generated from trading fees on swaps
- **Logic**: Process `Swap` events from both v2 and v3 versions of ShadowExchange. For v2, calculate net token amounts using `amount0In` minus `amount0Out` and `amount1In` minus `amount1Out`. For v3, use `amount0` and `amount1` directly. Convert token amounts to actual units by dividing by token decimals from trading pair metadata. Convert to USD using end-of-day price feeds, taking the lesser USD value between the two tokens in each pair to prevent price manipulation. Apply fee calculations by multiplying the USD trading volume by `fee_tier` (fee percentage) and `fee_split` (protocol's share of fees). Fee parameters are tracked over time using parameter change events with time-based intervals.
- **Key fields**: `token0_amount`, `token1_amount`, `fee_tier`, `fee_split`, USD trading volume

### Component C: Voting bribe revenue calculation  
- **Purpose**: Calculate revenue from voting incentive bribes
- **Logic**: Extract `VotesIncentivized` events from `FeeDistributor` contracts, representing payments made to incentivize votes. Convert token amounts to actual units by dividing by token decimals. Convert to USD using end-of-day price feeds. Handle special case where xSHADOW tokens are treated as SHADOW tokens for pricing. Sum all bribe amounts daily.
- **Key fields**: `amount` (bribe payment), `token_address`, converted USD value

### Component D: Fee parameter tracking
- **Purpose**: Apply correct fee rates and splits based on pool settings over time
- **Logic**: Track fee tier changes from `SetPairFee`, `FeeAdjustment` events and fee split changes from `SetPairFeeSplit`, `SetFeeProtocol` events. Create time intervals for when each parameter setting was active using block timestamps and order IDs. Default fee tiers are set to 3000 (0.3%) for pairs created before any factory fee changes. Fee splits default to 0 if not explicitly set. Apply the correct parameters to each trade based on the trade's timestamp falling within the parameter's active interval.
- **Key fields**: `fee_tier`, `fee_split`, `block_timestamp`, `order_id` for temporal ordering

### Final aggregation
- **Combining components**: Sum trading fee revenue and voting bribe revenue to get total daily revenue. Count distinct user addresses across both trading and flash loan activities to get daily active users. Both metrics are aggregated at the daily level using timestamp truncation.
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds. Trading volumes use the lesser USD value between token pairs to prevent manipulation from price discrepancies.
- **Time aggregation**: Daily boundaries are established using timestamp truncation to day level. Missing days are filled with zeros to maintain complete time series.
- **Final calculation**: ARPU is calculated by dividing total daily revenue by daily active users count. The result represents the average USD revenue generated per active user on each day. Days with zero active users result in null ARPU values.

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

ShadowSHADOW

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape