website

twitter

discord

Exchanges (DEX)

Shadow

# Shadow Liquidity turnover Methodology

## 1. Overview

Liquidity turnover measures how efficiently capital is utilized in Shadow Exchange pools by calculating the ratio of daily trading volume to total value locked (TVL). This metric indicates how many times the protocol's liquidity is traded over in a given period, with higher values suggesting more active and efficient capital utilization. The calculation divides daily trading volume by daily TVL across both Shadow Exchange v2 and v3 protocols on the Sonic blockchain.

## 2. Data sources

- **Blockchain swap events**: Parsed Sonic blockchain `Pair_Swap_event` (v2) and `Pool_Swap_event` (v3) containing token amount changes and user interactions
- **Pool creation events**: Sonic blockchain `Factory_PairCreated_event` (v2) and `Factory_PoolCreated_event` (v3) establishing trading pair configurations
- **Liquidity events**: Sonic blockchain `Pool_Mint_event` (deposits), `Pool_Collect_event` (withdrawals), and `Pool_Flash_event` (flash loans) tracking liquidity changes
- **Reserve synchronization events**: Sonic blockchain `Pair_Sync_event` tracking v2 pool reserve updates
- **Fee configuration events**: Sonic blockchain fee setting events including `PairFactory_SetPairFee_event`, `Pool_SetFeeProtocol_event`, and related fee adjustment events
- **Transaction data**: Sonic blockchain transaction records for user address resolution
- **External data**: End-of-day token price feeds for USD conversion and token metadata containing decimals and symbols

## 3. Step-by-step calculation

### Component A: Trading volume calculation
- **Purpose**: Calculate daily USD trading volume across Shadow Exchange v2 and v3 protocols
- **Logic**: Extract swap events from both protocols on Sonic blockchain. For v2 swaps, calculate token amount changes by subtracting `amount0Out` from `amount0In` and `amount1Out` from `amount1In`. For v3 swaps, use direct `amount0` and `amount1` values from swap events. Join swap data with trading pair metadata to obtain token addresses and decimal configurations. Apply decimal corrections by dividing token amounts by 10 raised to the power of each token's decimals. Convert corrected amounts to USD using end-of-day price feeds, taking the minimum USD value between the two tokens in each pair to filter out potential price manipulation. Aggregate volumes daily by protocol version and trading pair
- **Key fields**: `token0_amount` and `token1_amount` (swap amounts), `token0_decimals` and `token1_decimals` (decimal configurations), `price_usd` (token prices), `trading_volume` (final USD volume)

### Component B: Total value locked calculation  
- **Purpose**: Calculate daily TVL by tracking net liquidity deposits across both protocol versions
- **Logic**: For v2 pools, monitor reserve changes through `Pair_Sync_event` data, calculating daily differences in `reserve0` and `reserve1` amounts compared to previous day balances. For v3 pools, combine multiple liquidity-affecting events: deposits from `Pool_Mint_event` (positive flow), withdrawals from `Pool_Collect_event` (negative flow), directional flows from `Pool_Swap_event`, and flash loan fees from `Pool_Flash_event` multiplied by the pool's current fee tier. Apply decimal corrections using token-specific decimals and convert to USD using end-of-day price feeds. Calculate net deposits as the cumulative sum of all asset flows, representing the total value locked in each pool
- **Key fields**: `reserve0_amount` and `reserve1_amount` (v2 reserves), `token0_amount` and `token1_amount` (asset flow amounts), `fee_tier` (for flash loan calculations), `net_deposits` (cumulative TVL)

### Component C: Fee and configuration tracking
- **Purpose**: Track dynamic fee structures and pool configurations over time
- **Logic**: Monitor fee tier changes through various configuration events, establishing time intervals where specific fee rates apply. Track protocol fee splits that affect flash loan calculations. Match fee configurations to trading events based on transaction order and timing to ensure accurate fee applications. Maintain historical fee records with validity periods to handle fee changes over time
- **Key fields**: `fee_tier` (trading fees), `fee_split` (protocol fee portion), `next_block_timestamp` (validity period)

### Final aggregation
- **Combining components**: Join daily trading volume with daily TVL data by timestamp and chain, ensuring both metrics use the same time boundaries and currency conversion approach
- **Currency conversion**: Apply end-of-day USD price feeds consistently across both trading volume and TVL calculations, using the same price reference points for accurate ratio computation
- **Time aggregation**: Truncate all timestamps to daily boundaries and aggregate trading volumes as sums while treating TVL as point-in-time balances at day end
- **Final calculation**: Divide daily trading volume by daily TVL to produce the liquidity turnover ratio, applying a fill_zeros strategy for days with missing data and standardizing output through the finalize metric schema

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

Trading volume divided by total liquidity.

ShadowSHADOW

Liquidity turnover

Liquidity turnover

Competitive landscape