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

SyncSwap is a non-custodial exchange protocol built on zkSync Era (originally a fork of Uniswap). SyncSwap was founded by an anonymous team in 2023.

The SyncSwap team owns and governs the protocol. They currently take a cut of the trading fees paid by the users (revenue).

github

twitter

discord

website

Exchanges (DEX)

SyncSwap

# SyncSwap Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who performed any trading activity on SyncSwap within a rolling 30-day period. This includes users who executed token swaps on classic or stable pools, or took flash loans. The metric uses HyperLogLog probabilistic counting for efficient computation across large datasets and provides breakdowns by chain, user type, and product categories.

## 2. Data sources

- **Flash loan event logs**: Parsed `Vault_FlashLoan_event` logs from SyncSwap v1 vault contract on zkSync Era, capturing flash loan transactions with recipient, token, and amount details
- **Swap event logs**: Parsed `ClassicPool_Swap_event` and `StablePool_Swap_event` logs from SyncSwap v1 pool contracts on zkSync Era, capturing token swap transactions with input/output amounts for both tokens
- **Transaction records**: zkSync Era transaction data providing user addresses and transaction metadata for correlation with event logs

## 3. Step-by-step calculation

### Component A: Flash loan user identification
- **Purpose**: Identifies users who took flash loans as one type of trading activity
- **Logic**: Processes flash loan event logs from the SyncSwap vault contract. Extracts the `recipient` field from events and joins with transaction records to get the actual user address from the `from_address` field. Includes flash loan details like token address, fee amount, and loan amount. Standardizes business metadata with product classification as 'flashloan' within the 'Exchange AMM' business line.
- **Key fields**: `block_timestamp` for daily aggregation, `user_address` from transaction records, `token_address` and `amount` from event logs, `product_id` set to 'flashloan'

### Component B: Swap user identification  
- **Purpose**: Identifies users who performed token swaps on different pool types
- **Logic**: Processes swap event logs from both classic and stable pool contracts. Calculates net token amounts by computing the difference between input and output amounts for both tokens in each swap. Joins with transaction records to extract user addresses. Differentiates between 'Classic pool' and 'Stable pool' product types based on the source contract. Standardizes business metadata with 'dex' business segment classification.
- **Key fields**: `block_timestamp` for daily aggregation, `user_address` from transaction records, `token0_amount` and `token1_amount` calculated as net changes, `product_id` distinguishing pool types

### Component C: Daily active user aggregation
- **Purpose**: Combines all user activities into daily unique user counts
- **Logic**: Unions flash loan and swap users using UNION DISTINCT to deduplicate users who performed multiple activity types on the same day. Truncates all timestamps to daily granularity. Classifies all users as 'Trader' user type since they're performing trading-related activities. Maintains dimensional attributes like chain, product categories, and business segment information.
- **Key fields**: `timestamp` truncated to day, `user_dau` containing unique user addresses, `user_type` set to 'Trader', `product_id` preserving activity type

### Component D: HyperLogLog initialization
- **Purpose**: Converts daily user lists into probabilistic data structures for efficient distinct counting
- **Logic**: Takes the daily user data and creates HyperLogLog sketches using BigQuery's `hll_count.init` function with precision parameter 15. Groups by timestamp, chain, user type, and product to create separate HLL sketches for each combination. This enables efficient merging across time periods without storing individual user identifiers.
- **Key fields**: `hll` sketches containing encoded user sets, dimensional grouping fields preserved for breakdown calculations

### Component E: Rolling window creation
- **Purpose**: Establishes 30-day rolling windows for MAU calculation
- **Logic**: Uses a datespine approach to generate all possible date combinations. Creates a base datespine of all days in the data range, then generates a cross-join with the previous 29 days for each date to create 30-day windows. This ensures consistent MAU calculation even when certain days have no activity, avoiding gaps in the rolling window.
- **Key fields**: `timestamp` for the MAU calculation date, `joinday` for the historical days to include in the window

### Component F: HLL aggregation across windows
- **Purpose**: Merges HLL sketches across 30-day periods to count distinct users
- **Logic**: Joins the rolling window structure with the daily HLL data to collect all relevant sketches for each 30-day period. Uses BigQuery's `hll_count.merge_partial` to combine HLL sketches across the window, then `hll_count.extract` to get the final distinct user count. This provides an approximate but highly accurate count of users active within each rolling 30-day period.
- **Key fields**: `user_mau` containing the extracted distinct user count, dimensional fields maintained for breakdowns

### Component G: Multi-dimensional breakdowns
- **Purpose**: Calculates MAU across different business dimensions
- **Logic**: Creates separate aggregations for four different dimensional views: project level (all SyncSwap activity), chain level (zkSync Era), user type level (Traders), and product level (Classic pool, Stable pool, flashloan). Each breakdown nullifies non-applicable dimension fields and aggregates HLL sketches accordingly. Uses UNION ALL to combine all dimensional views into a single result set.
- **Key fields**: `dimensions` field identifying the breakdown type, dimensional fields set to null when not applicable, `user_mau` calculated for each dimensional combination

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with MAU calculations for every relevant business dimension
- **Currency conversion**: Not applicable - this metric counts users rather than monetary values
- **Time aggregation**: Uses rolling 30-day windows calculated daily, with each day's MAU representing unique users active in the previous 30 days including the current day
- **Final calculation**: The final MAU value for each dimension is the HyperLogLog-estimated count of distinct user addresses who performed any flash loan or swap activity within the rolling 30-day period, broken down by project, chain, user type, and product categories

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

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

SyncSwap

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown