website

twitter

discord

Exchanges (DEX)

Shadow

# Shadow Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for Shadow Exchange measures the number of unique users who performed trading activities (swaps) or flash loans on the Shadow Exchange protocol over a rolling 7-day period. This metric uses HyperLogLog probabilistic data structures to efficiently count unique users across multiple dimensions including project-level, chain-level, user type, and product version breakdowns.

## 2. Data sources

- **Blockchain events**: Parsed Sonic blockchain event logs from Shadow Exchange smart contracts
  - `Pool_Flash_event` logs from Shadow Exchange v3 pool contracts capturing flash loan activities
  - `Pair_Swap_event` logs from Shadow Exchange v2 pair contracts capturing trading activities  
  - `Pool_Swap_event` logs from Shadow Exchange v3 pool contracts capturing trading activities
- **Transaction data**: Sonic blockchain transaction records used to identify the actual user addresses who initiated the contract interactions
- **Contract metadata**: Shadow Exchange protocol version information (v2, v3) and product identifiers

## 3. Step-by-step calculation

### Component A: Flash loan user extraction
- **Purpose**: Identify users who performed flash loans on Shadow Exchange
- **Logic**: Extract `Pool_Flash_event` logs from Shadow Exchange v3 contracts on Sonic blockchain. Join with transaction records to map the contract interaction to the actual user address (`from_address` field). Create unique identifiers using block number and log index. Filter to users classified as 'Trader' type and group by day, chain, and product identifier.
- **Key fields**: `user_address` from transaction records, `block_timestamp` for daily grouping, `product_id` for version tracking, `chain` for blockchain identification

### Component B: Trading user extraction  
- **Purpose**: Identify users who performed swaps/trades on Shadow Exchange
- **Logic**: Process swap events from both Shadow Exchange v2 and v3 contracts. For v2, extract `Pair_Swap_event` logs and calculate token amounts as the difference between `amount0In/amount0Out` and `amount1In/amount1Out`. For v3, extract `Pool_Swap_event` logs with direct `amount0` and `amount1` values. Join both event types with transaction records to get user addresses. Classify all users as 'Trader' type and group by day, chain, and product version.
- **Key fields**: `user_address` from joined transactions, `block_timestamp` for daily aggregation, `token0_amount` and `token1_amount` for trade volumes, `product_id` distinguishing v2/v3

### Component C: Daily active user consolidation
- **Purpose**: Combine flash loan and trading users into daily unique active users
- **Logic**: Union the flash loan users and trading users using UNION DISTINCT to eliminate double-counting of users who performed both activities on the same day. Group by timestamp (day), chain, user type, and product identifier. Each unique user address becomes a daily active user record.
- **Key fields**: `timestamp` truncated to day, `user_address` as the unique identifier, `chain` and `product_id` for dimensional grouping

### Component D: HyperLogLog initialization
- **Purpose**: Convert daily user data into probabilistic counting structures
- **Logic**: Initialize HyperLogLog data structures for each daily active user record using `hll_count.init` with precision parameter 15. This enables efficient approximate counting of unique users across time windows without storing actual user addresses.
- **Key fields**: `hll` structure containing encoded user information, maintaining all dimensional attributes for later aggregation

### Component E: Rolling window creation
- **Purpose**: Generate 7-day rolling windows for weekly calculations
- **Logic**: Create a datespine covering all days from the earliest user activity to the current date. For each date in the spine, generate an array of the 7 days ending on that date (6 days prior plus the current day). This creates joinday mappings that define the rolling weekly windows.
- **Key fields**: `timestamp` as the window end date, `joinday` as each day within the 7-day window

### Component F: Window-based HLL aggregation
- **Purpose**: Collect HLL structures across 7-day windows
- **Logic**: Join the rolling window structure with the HLL-encoded daily user data. For each window end date, collect all HLL structures from the 7 constituent days. Group by the window timestamp and dimensional attributes (chain, user type, product) while preserving the HLL structures for merging.
- **Key fields**: `timestamp` as window identifier, `hll` structures from each day in the window, dimensional grouping fields

### Final aggregation
- **Combining components**: Merge the HLL structures within each 7-day window using `hll_count.merge_partial` to combine probabilistic user counts across the time period. Extract the final unique user count using `hll_count.extract` to get the approximate number of unique users.
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Rolling 7-day windows calculated for each day, with the window including the current day plus the 6 preceding days
- **Final calculation**: Generate four dimensional breakdowns of the weekly active user counts: project-level (all dimensions aggregated), chain-level (grouped by blockchain), user-type-level (grouped by user classification), and product-level (grouped by protocol version). Union all dimensional views and apply standard metric formatting including zero-filling for missing dates and proper schema structuring.

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

Unique revenue-generating users over a rolling 7-day window.

ShadowSHADOW

Active users (weekly)

Active users (weekly)

Competitive landscape