Liquidity providers deposit funds into Zyberswap and receive trading fees from traders (supply-side fees).

Zyberswap is a non-custodial exchange protocol built on Arbitrum. Zyberswap was founded by anonymous team and launched in 2023.

ZYB tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

twitter

discord

etherscan

website

Exchanges (DEX)

Zyberswap

# Zyberswap Active users (monthly) Methodology

## 1. Overview

ZyberSwap Monthly Active Users (MAU) measures the number of unique users who interact with ZyberSwap's decentralized exchange on Arbitrum over a rolling 30-day period. The metric captures users engaged in trading activities (swaps) and flash loan operations across both ZyberSwap V2 and V3 protocols. The calculation uses HyperLogLog data structures to efficiently count distinct users across multiple dimensions including overall project level, by chain, by user type, and by product.

## 2. Data sources

The calculation relies on several types of raw blockchain data from Arbitrum:

- **Arbitrum transaction records**: Contains transaction metadata including the `from_address` field that identifies the actual user initiating transactions
- **ZyberSwap V2 swap events**: Parsed `Pair_Swap` event logs from ZyberSwap V2 pair contracts containing swap details including token amounts and participant addresses
- **ZyberSwap V3 swap events**: Parsed `AlgebraPool_Swap` event logs from ZyberSwap V3 pool contracts with swap execution details and participant information
- **ZyberSwap V2 flash loan events**: Parsed `SwapFlashLoan_TokenSwap` event logs capturing flash loan operations in V2 contracts
- **ZyberSwap V3 flash loan events**: Parsed `AlgebraPool_Flash` event logs from V3 pools documenting flash loan activities

All data processing begins with events timestamped from January 23, 2023 onwards.

## 3. Step-by-step calculation

### Component A: Trading activity extraction

- **Purpose**: Identify daily active users from ZyberSwap trading operations across V2 and V3
- **Logic**: For V2, the system processes `Pair_Swap` events and calculates net token flows by subtracting `amount0Out` from `amount0In` and `amount1Out` from `amount1In`. For V3, it directly uses `amount0` and `amount1` values from `AlgebraPool_Swap` events. Both versions join swap events with Arbitrum transaction records to extract the actual user address from the `from_address` field rather than using contract interaction addresses. Users are aggregated by day using timestamp truncation to day granularity.
- **Key fields**: `block_timestamp` for temporal aggregation, `from_address` for user identification, `amount0In/Out` and `amount1In/Out` for V2 token flows, `amount0` and `amount1` for V3 amounts, `transaction_hash` for joining events with transaction data

### Component B: Flash loan activity extraction  

- **Purpose**: Capture daily active users from flash loan operations across ZyberSwap versions
- **Logic**: For V3, the system processes `AlgebraPool_Flash` events extracting flash loan amounts and participant information. For V2, it handles `SwapFlashLoan_TokenSwap` events which represent token swaps within flash loan operations. Similar to trading activity, all events are joined with transaction records to obtain the actual user address from `from_address`. Flash loan users are aggregated by day and categorized under the same business classifications as traders.
- **Key fields**: `block_timestamp` for daily aggregation, `from_address` for user identification, `amount0` and `amount1` for flash loan amounts, `sender` for contract-level addresses, `transaction_hash` for transaction joins

### Component C: Daily active user consolidation

- **Purpose**: Combine trading and flash loan users into unified daily active user counts
- **Logic**: The system performs a union distinct operation combining users from both trading and flash loan activities. This ensures that users active in multiple activities on the same day are counted only once. All users are classified as 'Trader' type regardless of their specific activity. The consolidation maintains dimensional attributes including chain, product identifiers, and business segment classifications.
- **Key fields**: `timestamp` truncated to day, `user_address` for distinct counting, `chain` for network identification, `user_type` standardized as 'Trader', `market_sector_id` and `business_segment_id` for business categorization

### Component D: HyperLogLog initialization

- **Purpose**: Convert daily user sets into HyperLogLog data structures for efficient aggregation
- **Logic**: Daily active user data is transformed into HyperLogLog structures using `hll_count.init` with precision parameter 15. This probabilistic data structure enables memory-efficient counting of distinct users across large datasets and time periods. The HLL initialization maintains all dimensional attributes while preparing the data for rolling window aggregation.
- **Key fields**: `user_dau` converted to HLL structure, dimensional attributes preserved for grouping, `timestamp_grain` set to 'day' for aggregation consistency

### Component E: Rolling window construction

- **Purpose**: Create 30-day rolling windows for each date to capture monthly active user periods  
- **Logic**: The system generates a date spine covering the full date range, then creates rolling 30-day windows by joining each date with the 29 preceding days. This produces a comprehensive set of date pairs where each target date is associated with all dates in its 30-day lookback window. The windowing logic ensures complete coverage even for dates with no activity by using the date spine as the foundation.
- **Key fields**: `timestamp` for target dates, `joinday` for dates within the 30-day window, window boundaries defined by 29-day lookback from current date

### Component F: Window aggregation and merging

- **Purpose**: Aggregate HyperLogLog structures across 30-day windows to calculate monthly active users
- **Logic**: For each 30-day window, the system joins window dates with daily HLL data and merges HyperLogLog structures using `hll_count.merge_partial`. This probabilistic merging efficiently combines distinct user counts across the rolling period. The aggregation maintains dimensional breakdowns while producing monthly active user estimates through HLL extraction using `hll_count.extract`.
- **Key fields**: HLL structures merged across window periods, dimensional attributes maintained for breakdown analysis, `user_mau` extracted from merged HLL data

### Final aggregation

- **Combining components**: Monthly active users are calculated separately for four dimensional breakdowns: overall project level (project_dbt_tag), by chain, by user_type, and by product_id. Each breakdown aggregates the merged HLL data differently while maintaining consistent schema structure. The breakdowns are combined using union all operations to create a comprehensive dimensional dataset.
- **Time aggregation**: The metric uses rolling 30-day windows updated daily, where each date represents the count of distinct users active in the current day plus the previous 29 days. Window boundaries are calculated using timestamp arithmetic with 29-day lookback periods.
- **Final calculation**: The final MAU value for any given date represents the estimated count of unique users who performed trading or flash loan activities within the 30-day period ending on that date, calculated using probabilistic HyperLogLog merging and extraction across the rolling window.

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

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

ZyberswapZYB

Active users (monthly)

Active users (monthly)

Competitive landscape