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

## 1. Overview

The Zyberswap trade count metric measures the daily number of unique trades executed on the Zyberswap decentralized exchange on Arbitrum. This metric counts distinct transactions that resulted in token swaps across both Zyberswap v2 and v3 protocols. The calculation identifies unique trades by counting distinct transaction hashes for swap events that occur within each daily period, providing insight into trading activity and user engagement on the platform.

## 2. Data sources

- **Blockchain events**: Parsed Arbitrum swap events including `Pair_Swap_event` from Zyberswap v2 contracts and `AlgebraPool_Swap_event` from Zyberswap v3 contracts
- **Pool creation events**: Parsed pool and pair creation events including `SwapDeployer_NewSwapPool_event`, `Factory_PairCreated_event`, and `AlgebraFactory_Pool_event` to establish trading pair relationships
- **Fee management events**: Parsed `AlgebraPool_Fee_event` and `AlgebraPool_CommunityFee_event` from Zyberswap v3 contracts for dynamic fee tracking
- **Transaction data**: Arbitrum blockchain transaction records to obtain user addresses and transaction metadata
- **External data**: End-of-day token price feeds for USD conversion and token metadata including decimals and symbols
- **Data filtering**: All trade data is filtered to include only transactions occurring after January 23, 2023

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract and standardize trade events from both Zyberswap v2 and v3 protocols
- **Logic**: Parse swap events from Arbitrum blockchain logs, capturing `Pair_Swap_event` from v2 contracts and `AlgebraPool_Swap_event` from v3 contracts. For v2 trades, calculate net token amounts by subtracting `amount0Out` from `amount0In` and `amount1Out` from `amount1In`. For v3 trades, use the direct `amount0` and `amount1` values. Join each swap event with Arbitrum transaction records to obtain the originating user address (`from_address`) and apply timestamp filtering to include only trades after January 23, 2023
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `address` (pool contract), `sender` (contract user), `from_address` (actual user), `amount0In/Out` (v2), `amount0/1` (v3)

### Component B: Trading pair dimension mapping
- **Purpose**: Establish relationships between pool contracts and their underlying token pairs
- **Logic**: Process pool creation events from multiple sources to build a comprehensive mapping of trading pairs. For v2, extract pair information from `SwapDeployer_NewSwapPool_event` (handling multi-token pools) and `Factory_PairCreated_event`. For v3, process `AlgebraFactory_Pool_event`. Each event provides the pool contract address and associated token addresses. Join with token metadata to obtain token decimals and symbols, creating standardized trading pair identifiers
- **Key fields**: `account_address` (pool contract), `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name` (token pair symbol)

### Component C: Fee tier management
- **Purpose**: Determine applicable trading fees for each transaction
- **Logic**: Apply different fee calculation methods based on protocol version. For v2 trades, use a hardcoded fee tier of 0.25% (0.0025). For v3 trades, join with `AlgebraPool_Fee_event` data to retrieve dynamic fee tiers that can change per block. Fee events contain `fee` values that are converted from the raw format by dividing by 10^6. When no specific fee event matches a v3 trade, the system applies the most recent available fee tier for that pool
- **Key fields**: `fee_tier` (calculated fee percentage), `block_number` (for temporal matching), `fee` (raw fee value from events)

### Component D: Protocol fee calculation
- **Purpose**: Calculate protocol-level fees that are retained by the protocol
- **Logic**: For v2 trades, apply a hardcoded protocol fee tier of 0.10% (0.001). For v3 trades, process `AlgebraPool_CommunityFee_event` data to determine dynamic protocol fees. Extract `communityFee0New` and `communityFee1New` values, convert by dividing by 10^3, and take the maximum of the two values as the protocol fee tier. Multiply this protocol fee tier by the base trading fee tier to get the final protocol fee. Use forward-filling to apply the most recent protocol fee setting to dates without explicit fee changes
- **Key fields**: `protocol_fee_tier`, `communityFee0New`, `communityFee1New` (raw protocol fee values)

### Component E: Amount standardization and USD conversion
- **Purpose**: Convert raw token amounts to standardized decimal-corrected values and USD equivalents
- **Logic**: Correct token amounts by dividing the raw blockchain values by 10 raised to the power of each token's decimal places, obtained from token metadata. Calculate USD values for both tokens in each trade using end-of-day price feeds matched by timestamp, token address, and chain. To filter out potential price manipulation, apply a conservative approach by taking the lesser of the two USD amounts (token0 USD value vs token1 USD value) as the final trading volume for each transaction
- **Key fields**: `token0_amount`, `token1_amount` (decimal-corrected), `price_usd` (from price feeds), `trading_volume` (final USD amount)

### Final aggregation
- **Combining components**: Join all components using pool contract addresses, transaction identifiers, and timestamps to create a comprehensive view of each trade with associated fees, token information, and USD values
- **Currency conversion**: USD conversion uses end-of-day price feeds with conservative price manipulation filtering by selecting the minimum USD value between the two tokens in each trade
- **Time aggregation**: Truncate all timestamps to daily boundaries and group trades by day, maintaining transaction-level granularity within each day
- **Final calculation**: Count distinct `transaction_hash` values within each daily period to determine the number of unique trades, ensuring that multiple swap events within a single transaction are counted as one trade. Apply zero-filling strategy to ensure continuous daily data and chain availability filtering to maintain data quality standards

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

Number of trades executed on a decentralized exchange.

ZyberswapZYB

Trade count

Trade count

Competitive landscape