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 (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for SyncSwap measures the number of unique users who interact with SyncSwap V1 protocols on zkSync Era within any 7-day rolling window. This metric captures user engagement across both trading activities (swaps in Classic and Stable pools) and flash loan usage. The calculation uses HyperLogLog estimation for efficient computation across time windows and provides dimensional breakdowns by project, chain, user type, and product type.

## 2. Data sources

- **SyncSwap event logs**: Parsed `Vault_FlashLoan` events from SyncSwap V1 Vault contracts on zkSync Era capturing flash loan activities
- **SyncSwap swap events**: Parsed `ClassicPool_Swap` and `StablePool_Swap` events from SyncSwap V1 pool contracts on zkSync Era capturing trading activities  
- **zkSync Era transaction data**: Transaction records providing user address resolution for contract interactions
- **Blockchain events**: zkSync Era transaction logs and event data for activity timestamps and transaction context

## 3. Step-by-step calculation

### Component A: Flash loan user identification
- **Purpose**: Identifies users who execute flash loans on SyncSwap V1 Vault contracts
- **Logic**: Extracts `Vault_FlashLoan` events from SyncSwap V1 contracts on zkSync Era. Each flash loan event contains a `recipient` address and transaction context. The system joins these events with zkSync Era transaction records to resolve the actual user address (`from_address`) who initiated the transaction, as the recipient may be a smart contract. Key fields include block timestamp for daily aggregation, transaction hash for deduplication, and user address for counting unique users.
- **Key fields**: `block_timestamp` for temporal grouping, `transaction_hash` for event identification, `recipient` for contract-level address, `from_address` for end-user identification

### Component B: Trading user identification  
- **Purpose**: Identifies users who execute swaps across SyncSwap V1 Classic and Stable pools
- **Logic**: Extracts `ClassicPool_Swap` and `StablePool_Swap` events from respective SyncSwap V1 pool contracts on zkSync Era. Each swap event contains sender information and token amount changes (`amount0In`, `amount0Out`, `amount1In`, `amount1Out`). The system joins these events with zkSync Era transaction records to resolve the actual user address who initiated the swap transaction. Events are categorized by pool type (Classic pool vs Stable pool) for product-level analysis.
- **Key fields**: `block_timestamp` for temporal grouping, `transaction_hash` for event identification, `sender` for contract-level address, `from_address` for end-user identification, amount fields for trade validation

### Component C: Daily user aggregation
- **Purpose**: Combines flash loan and trading users into daily unique user counts
- **Logic**: Takes the union of user addresses from both flash loan and trading activities, aggregating by day using timestamp truncation to day boundaries. All users are classified as 'Trader' user type regardless of whether they performed flash loans or swaps. The system deduplicates users within each day and across activities, ensuring users active in multiple product types are counted only once per day. Users are grouped by chain (zksyncera), product type, and other dimensional attributes.
- **Key fields**: `timestamp` truncated to day, `chain` as zksyncera, `user_type` as Trader, `product_id` indicating activity type, `user_address` for deduplication

### Component D: HyperLogLog sketch creation
- **Purpose**: Converts daily user sets into efficient HyperLogLog sketches for rolling window calculations
- **Logic**: Transforms daily user address sets into HyperLogLog sketches with precision parameter 15, which allows for approximate cardinality counting with high accuracy while enabling efficient merging across time periods. Each daily HLL sketch represents the unique users for that specific day, grouped by all dimensional attributes (chain, user type, product type). This approach enables efficient computation of rolling windows without storing complete user sets.
- **Key fields**: `hll` sketch containing compressed user cardinality, dimensional grouping fields, `timestamp` for temporal organization

### Component E: Rolling window generation
- **Purpose**: Creates 7-day rolling windows for weekly active user calculation
- **Logic**: Generates a complete datespine covering all days from the earliest data through yesterday, then creates a join table mapping each day to its corresponding 7-day window (current day plus 6 preceding days). This approach ensures no missing days in the time series and creates overlapping 7-day windows for each calendar day. The system uses timestamp arrays to generate both the datespine and the 7-day lookback periods, handling edge cases where fewer than 7 days of historical data exist.
- **Key fields**: `timestamp` as the target date, `joinday` representing each day within the 7-day window

### Component F: HyperLogLog aggregation across time windows
- **Purpose**: Merges daily HLL sketches across 7-day windows to calculate unique users
- **Logic**: For each day, joins the daily HLL sketches with the corresponding 7-day window definition, then merges all HLL sketches within each window using HLL merge operations. This produces a single HLL sketch representing unique users across the entire 7-day period. The merging process automatically handles overlapping users across multiple days within the window, ensuring accurate unique user counts.
- **Key fields**: `hll` merged sketch containing 7-day unique user cardinality, dimensional attributes preserved from daily level

### Component G: Dimensional breakdown calculation
- **Purpose**: Calculates WAU across multiple dimensional perspectives
- **Logic**: Creates four separate dimensional views by grouping and aggregating the 7-day HLL sketches: 1) Project-level (all dimensions collapsed), 2) Chain-level (grouped by chain), 3) User-type-level (grouped by user type), 4) Product-level (grouped by product type). Each breakdown merges HLL sketches appropriately and extracts the final cardinality estimate using HLL extract functions. Non-relevant dimension fields are set to null for each breakdown type.
- **Key fields**: `dimensions` indicating breakdown type, relevant dimensional fields populated, others set to null, `user_wau` as extracted cardinality

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations, creating a unified result set with different dimensional perspectives of the same underlying WAU metric
- **Time aggregation**: Uses daily boundaries with 7-day rolling windows, where each day represents the WAU for that day plus the 6 preceding days
- **Final calculation**: Extracts unique user counts from merged HLL sketches using HLL cardinality extraction, applies schema standardization through the finalize metric macro, and fills missing days with zero values to ensure complete time series coverage

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

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

SyncSwap

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown