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 Trade count Methodology

## 1. Overview

The SyncSwap trade count metric measures the daily number of unique trading transactions on the SyncSwap decentralized exchange. This metric counts distinct transaction hashes that contain swap events from SyncSwap's Classic and Stable liquidity pools on zkSync Era. The calculation aggregates individual swap events into daily totals, providing insight into trading activity and user engagement on the platform.

## 2. Data sources

The calculation relies on several key data sources:

- **Blockchain events**: Parsed zkSync Era `Swap` events from SyncSwap's `ClassicPool` and `StablePool` contracts, capturing individual trade executions with token amounts and pool addresses
- **Transaction data**: zkSync Era transaction records providing user addresses and transaction metadata to link swap events to actual users
- **Pool creation events**: `PoolCreated` events from SyncSwap's `ClassicPoolFactory` and `StablePoolFactory` contracts establishing trading pair metadata and initial fee structures
- **Fee update events**: `SetPoolSwapFee` and `SetPoolProtocolFee` events from SyncSwap's `FeeManager` contract tracking dynamic fee changes over time
- **External data**: End-of-day token price feeds for USD conversion and token metadata including decimals and symbols for proper amount calculations

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract and standardize all swap events from SyncSwap pools
- **Logic**: The system collects `Swap` events from both Classic and Stable pool contracts on zkSync Era. Each event contains token amounts in (`amount0In`, `amount1In`) and out (`amount0Out`, `amount1Out`) for the two tokens in the trading pair. The net change for each token is calculated by subtracting outgoing amounts from incoming amounts. Events are joined with transaction data to map the contract caller (`sender`) to the actual user address (`from_address`). Each trade receives a unique identifier created by concatenating the block number and log index.
- **Key fields**: `transaction_hash`, `block_timestamp`, `sender` (contract user), `from_address` (actual user), `amount0In/Out`, `amount1In/Out`, `address` (pool contract)

### Component B: Trading pair metadata enrichment  
- **Purpose**: Combine trade events with pool configuration and token information
- **Logic**: Trade events are matched with trading pair data derived from pool creation events. The system identifies each pool's token pair, fee tier, and product type (Classic vs Stable pool). Token metadata is joined to get decimal places and symbols for proper amount calculations. ETH addresses are standardized to WETH addresses for consistency. This creates a complete picture of each trade including the tokens involved and pool characteristics.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `fee_tier`, `protocol_fee_tier`, `account_name` (token pair symbol), `product_id`

### Component C: Fee tier updates application
- **Purpose**: Apply dynamic fee changes that occurred during the trading period
- **Logic**: SyncSwap allows fee tiers to be updated over time through `FeeManager` events. The system tracks these updates chronologically and applies the correct fee tier to each trade based on when it occurred. Fee updates are matched to trades using the composite ID ordering - trades get the most recent fee update that occurred before them. This ensures fee calculations reflect the actual rates in effect at trade time.
- **Key fields**: `fee_tier`, `protocol_fee_tier` updated based on chronological `SetPoolSwapFee` and `SetPoolProtocolFee` events

### Component D: Amount processing and USD conversion
- **Purpose**: Convert raw token amounts to standardized decimal-corrected values
- **Logic**: Raw token amounts are converted to proper decimal representation by dividing by 10 raised to the token's decimal places. The absolute value is taken since the system cares about trade magnitude, not direction. Token amounts are then converted to USD using end-of-day price feeds. To prevent price manipulation attacks, the system takes the lesser of the two USD values (token0 vs token1) when both are available. This creates a conservative volume estimate that filters out trades with suspicious price ratios.
- **Key fields**: `token0_amount`, `token1_amount` (decimal corrected), `trading_volume` (USD value using minimum of both tokens)

### Final aggregation
- **Combining components**: All processed trade data is aggregated at the daily level by truncating timestamps to day boundaries
- **Currency conversion**: USD conversion uses end-of-day price feeds matched by timestamp, token address, and chain  
- **Time aggregation**: Trades are grouped by day using timestamp truncation, with each day representing a complete 24-hour period
- **Final calculation**: The metric counts distinct transaction hashes within each day, grouped by chain, market sector (exchanges), business segment (dex), and product type (Classic pool vs Stable pool). The `finalize_metric_trade_count` macro standardizes the output format and fills missing days with zero values. Results are filtered based on chain availability settings to ensure data completeness.

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

Number of trades executed on a decentralized exchange.

SyncSwap

Trade count

Trade count

Competitive landscape

Chain breakdown