Kwenta builds on top of Synthetix to create a synthetic perpetuals trading platform. Traders on Kwenta trade futures against the liquidity provided by liquidity providers on Synthetix.

Kwenta is a non-custodial exchange for perpetual contracts built on Optimism. Kwenta was born out of the Synthetix community and launched in 2022.

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

governance

github

twitter

discord

etherscan

website

Derivative exchanges

Kwenta

# Kwenta Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of distinct users who performed trading activities on Kwenta over a rolling 7-day period. This metric answers the business question: "How many unique traders are actively using Kwenta's derivatives trading platform each week?" The calculation uses a rolling window approach that counts distinct user addresses across any 7-day period, providing insight into user engagement and platform adoption trends.

## 2. Data sources

The metric relies on the following raw data sources:
- **Optimism blockchain event logs**: Parsed contract events from the Synthetix protocol ecosystem on Optimism
- **FuturesTracking events**: Event logs from Synthetix FuturesMarket contracts that contain tracking codes identifying platform usage
- **PositionModified events**: Event logs from multiple versions of Synthetix perpetual futures contracts (ProxyPerpsV2, ProxyPerpsV21, ProxyPerpsV22) that record trading activity
- **Transaction metadata**: Blockchain transaction data including timestamps, transaction hashes, and user addresses

## 3. Step-by-step calculation

### Component A: User identification and validation
- **Purpose**: Identifies valid Kwenta users from Synthetix protocol events by filtering for Kwenta-specific activity
- **Logic**: Extracts user addresses from PositionModified events across multiple Synthetix contract versions on Optimism. Validates that transactions contain the Kwenta tracking code (`0x4b57454e54410000000000000000000000000000000000000000000000000000`, which represents 'KWENTA' in hexadecimal) from corresponding FuturesTracking events. Only includes user events where the transaction hash appears in the validated tracking code transactions. Classifies all identified users as 'Trader' type within the 'derivatives' market sector and 'perpetual' business segment.
- **Key fields**: User addresses (`account` from events), transaction timestamps (`block_timestamp`), transaction hashes, tracking codes (`trackingCode`), chain identifier

### Component B: Daily active user aggregation  
- **Purpose**: Aggregates identified users to daily level to create the foundation for rolling window calculations
- **Logic**: Takes distinct user addresses per day by truncating transaction timestamps to day granularity. Preserves dimensional attributes including chain, user type, and product identifiers for subsequent breakdowns. Applies chain availability filtering to ensure data quality. Each resulting row represents one unique user's activity on a specific day.
- **Key fields**: Daily timestamp (`timestamp`), user address (`user_dau`), chain identifier, user type classification, product and segment identifiers

### Component C: HyperLogLog sketch creation
- **Purpose**: Converts daily user data into efficient probabilistic data structures for distinct counting across time windows
- **Logic**: Creates HyperLogLog sketches from daily user address sets using 15-bit precision, which provides high accuracy for distinct counting while enabling efficient aggregation across multiple days. Groups data by timestamp, chain, user type, and product dimensions to maintain granular breakdowns.
- **Key fields**: HLL sketch representations of daily user sets (`hll`), grouping dimensions preserved from daily data

### Component D: Rolling window construction
- **Purpose**: Creates 7-day rolling windows for each date to enable weekly active user calculations
- **Logic**: Generates a complete date spine covering the full time range to prevent missing timestamps from creating gaps in the time series. For each date in the spine, creates join relationships with the preceding 6 days to form 7-day windows. This approach ensures every day has a complete weekly context, even if some days had no user activity.
- **Key fields**: Target date for WAU calculation, array of 7 days including target date and preceding 6 days

### Component E: Window-based HLL aggregation
- **Purpose**: Combines daily HLL sketches across each 7-day window to count distinct users over weekly periods
- **Logic**: Joins the rolling window structure with daily HLL sketches based on date matching. For each target date, merges the HLL sketches from all 7 days in that date's window using HyperLogLog merge operations. Extracts the final distinct count from each merged sketch, which represents the number of unique users active during that 7-day period.
- **Key fields**: Weekly distinct user counts (`user_wau`), window timestamp, dimensional groupings

### Component F: Dimensional breakdowns
- **Purpose**: Creates multiple analytical perspectives of the WAU data for different business use cases
- **Logic**: Generates four distinct dimensional views: project-level aggregation (all dimensions collapsed), chain-level breakdown (grouped by blockchain), user type breakdown (grouped by trader classification), and product-level breakdown (grouped by product identifier). Each breakdown maintains the same weekly distinct user counting logic while aggregating across the non-selected dimensions.
- **Key fields**: Dimension type indicator (`dimensions`), dimension-specific identifiers, weekly active user counts for each breakdown

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single result set, creating a comprehensive view that supports analysis at multiple granularity levels
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 7-day rolling windows where each date represents users active in that date's 7-day period (including the date itself and the preceding 6 days)
- **Final calculation**: The final WAU value for any given date represents the count of distinct user addresses that performed trading activities on Kwenta during the 7-day window ending on that date, calculated using merged HyperLogLog sketches for accuracy and efficiency

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

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

KwentaKWENTA

Active users (weekly)

Active users (weekly)

Competitive landscape