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

## 1. Overview

Monthly Active Users (MAU) for Kwenta measures the number of unique users who have interacted with Kwenta's derivatives trading platform within any 30-day rolling period. This metric is calculated by identifying users through their blockchain transactions on the Optimism network and aggregating them into monthly counts using HyperLogLog sketches for efficient computation. The metric answers how many distinct users are actively trading derivatives through Kwenta's interface over rolling 30-day windows.

## 2. Data sources

- **Optimism blockchain events**: Parsed event logs from Synthetix protocol contracts including `FuturesMarket`, `ProxyPerpsV2`, `ProxyPerpsV21`, and `ProxyPerpsV22` contracts
- **Position modification events**: `PositionModified` events that capture when users open, close, or modify trading positions in derivatives markets
- **Tracking events**: `PerpsTracking` and `FuturesTracking` events that contain platform-specific tracking codes to identify Kwenta users
- **Transaction data**: Optimism transaction records that link events to specific user addresses and timestamps

## 3. Step-by-step calculation

### Component A: User identification and filtering
- **Purpose**: Identify legitimate Kwenta users by filtering blockchain events for transactions containing Kwenta's tracking code
- **Logic**: Extract transactions from Synthetix derivatives contracts on Optimism that contain the specific Kwenta tracking code `0x4b57454e54410000000000000000000000000000000000000000000000000000`. This filters for users who are specifically trading through Kwenta's interface rather than directly with Synthetix contracts. Events are sourced from multiple contract versions including v1 FuturesMarket and v2/v2.1/v2.2 ProxyPerpsV2 contracts. Only `PositionModified` events from transactions that also have corresponding tracking events are included to ensure data quality.
- **Key fields**: `account` addresses from position events, `transaction_hash` for linking events, `block_timestamp` for temporal analysis, `trackingCode` for platform identification

### Component B: Daily active user aggregation  
- **Purpose**: Convert raw blockchain events into daily active user counts while preserving user addresses for downstream processing
- **Logic**: Group filtered user events by day using `timestamp_trunc` to create daily boundaries. Extract unique user addresses per day along with dimensional attributes including chain (Optimism), user type (Trader), market sector (derivatives), and business segment (perpetual). Each unique user address that appears in qualifying transactions on a given day is counted as an active user for that day.
- **Key fields**: `timestamp` truncated to daily granularity, `user_address` for unique user identification, `chain` for network identification, `user_type` for classification

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user lists into HyperLogLog sketches for memory-efficient storage and fast approximate counting
- **Logic**: Transform daily user address lists into HLL sketches using `hll_count.init` with precision 15. This probabilistic data structure allows efficient approximation of unique user counts when merging across time windows. Group by timestamp, chain, user type, and product dimensions to create separate sketches for each combination. HLL sketches enable scalable computation of rolling window unique counts without storing individual user addresses.
- **Key fields**: `hll` sketches containing compressed user count information, dimensional grouping fields for breakdowns

### Component D: Rolling window construction
- **Purpose**: Create complete 30-day rolling windows using a datespine approach that handles missing days
- **Logic**: Generate a complete daily datespine from the earliest available data to yesterday using `generate_timestamp_array`. For each day in the datespine, create associations with the previous 29 days using another timestamp array generation, resulting in 30-day windows. This cross-join approach ensures every day has a complete 30-day lookback period even when some days have no user activity. The datespine prevents gaps in the time series that would otherwise skew MAU calculations.
- **Key fields**: `timestamp` for the target date, `joinday` for dates within each 30-day window

### Component E: Window aggregation and dimensional breakdown
- **Purpose**: Merge HLL sketches across 30-day windows and calculate MAU for different dimensional cuts
- **Logic**: Join the rolling window structure with daily HLL sketches to associate each day with user activity from its 30-day lookback period. Merge HLL sketches using `hll_count.merge_partial` for each 30-day window, then extract final counts with `hll_count.extract`. Create separate breakdowns for project-level totals, chain-level, user type-level, and product-level MAU. Each dimensional breakdown groups and merges HLL sketches appropriately, setting unused dimension fields to null.
- **Key fields**: `user_mau` extracted from merged HLL sketches, `dimensions` indicating the breakdown type, dimension-specific fields like `chain_id` and `user_type`

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project-level, chain-level, user type-level, product-level) into a single result set with a consistent schema structure
- **Time aggregation**: Daily calculations with 30-day rolling windows, where each day represents users active in that day plus the previous 29 days
- **Final calculation**: The final MAU value for any given day represents the approximate count of unique user addresses that had qualifying derivatives trading activity within the 30-day period ending on that day, calculated by extracting the cardinality from merged HyperLogLog sketches

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

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

KwentaKWENTA

Active users (monthly)

Active users (monthly)

Competitive landscape