Overcollateralized borrowers deposit funds into Synthetix and mint synthetic assets.

Synthetix is a non-custodial derivatives exchange protocol built on Ethereum. Synthetix was founded by Kain Warwick and launched in 2017.

SNX tokenholders own and govern the protocol. They currently take all of the total trading fees paid by traders (revenue). Synthetix's investors include Paradigm, Framework Ventures, Coinbase Ventures, etc.

governance

github

twitter

discord

etherscan

website

Derivative exchanges

Synthetix

# Synthetix Active users (monthly) Methodology

## 1. Overview

The Synthetix Monthly Active Users (MAU) metric measures the number of unique users who have traded on the Synthetix protocol within a rolling 30-day window. This metric captures trading activity across both spot synthetic asset exchanges and perpetual futures trading, spanning multiple protocol versions (v1 and v2) and blockchain networks (Ethereum and Optimism). The calculation uses HyperLogLog data structures for memory-efficient approximate distinct user counting, enabling accurate MAU calculation at scale while providing dimensional breakdowns by chain, user type, and product.

## 2. Data sources

- **Synthetix v1 Ethereum event logs**: Parsed `SynthExchange` and `AtomicSynthExchange` events capturing spot synthetic asset trading activities, containing user addresses and transaction metadata
- **Synthetix v1 Optimism event logs**: Parsed `FuturesMarket_PositionModified` events for perpetual futures trading and `SynthExchange` events for spot trading, including user addresses and position data
- **Synthetix v2 Optimism event logs**: Parsed `ProxyPerpsV2_PositionModified` and `ProxyPerpsV21_PositionModified` events from the upgraded perpetual futures system, containing enhanced trading data
- **Market configuration data**: Parsed `FuturesMarketManager_MarketAdded` events used to create exclusion lists preventing double-counting between protocol versions
- **Chain availability metadata**: Data quality filters ensuring consistent reporting across supported blockchain networks

## 3. Step-by-step calculation

### Component A: User activity identification
- **Purpose**: Extract and classify all trading activities from Synthetix protocol events across different versions and chains
- **Logic**: Parse trading events from Ethereum and Optimism blockchain logs, extracting user addresses from the `account` field in each event. Classify users into specific categories based on their trading activity: Ethereum users engaging with `SynthExchange` or `AtomicSynthExchange` events are labeled as "Ethereum Spot Trader", Optimism users with `FuturesMarket_PositionModified` activities are "Optimism Perpetual Futures Trader", Optimism users with `SynthExchange` activities are "Optimism Spot Trader", and users interacting with v2 perpetual contracts are "Optimism Perpetual Futures V2 Trader". Apply a denylist filter using market addresses from `FuturesMarketManager_MarketAdded` events to prevent double-counting users who appear in both v1 and v2 systems.
- **Key fields**: `block_timestamp` for temporal analysis, `transaction_hash` for deduplication, `account` addresses for user identification, contract `address` for protocol version detection, and classified `user_type` labels

### Component B: Daily user aggregation
- **Purpose**: Aggregate user activities to daily level while maintaining dimensional breakdown capabilities
- **Logic**: Group all identified user activities by day using timestamp truncation to daily boundaries. Maintain dimensional groupings by `chain`, `user_type`, `market_sector_id`, `business_segment_id`, and `product_id` to enable various analytical breakdowns. Create distinct user counts per day for each dimensional combination while preserving individual user addresses for downstream HyperLogLog processing. Apply chain availability filtering to ensure data quality and consistent reporting across supported networks.
- **Key fields**: Daily `timestamp` boundaries, `chain` identifiers, categorized `user_type` labels, `product_id` for product-level analysis, and deduplicated `user_address` values

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user sets into HyperLogLog sketches for memory-efficient approximate distinct counting
- **Logic**: Initialize HyperLogLog sketches from daily user address sets using the `hll_count.init` function with precision parameter 15, providing approximately 1.6% standard error for distinct counting. Group sketches by timestamp, chain, user type, and product dimensions to maintain analytical flexibility. This probabilistic data structure enables efficient storage and fast computation of distinct user counts across large datasets while preserving the ability to merge counts across different time periods and dimensions.
- **Key fields**: Daily `timestamp` for temporal alignment, dimensional grouping fields (`chain_id`, `user_type`, `product_id`), and initialized `hll` sketches containing user address information

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for each date to calculate monthly active user counts
- **Logic**: Generate a complete datespine covering the analysis period from the earliest available data through the previous day. For each date in the spine, create a 30-day lookback window by joining with the previous 29 days of data using timestamp array generation. This approach ensures that MAU calculations include a full 30-day period for each reporting date, handling gaps in data and maintaining consistent window sizes. The window construction accounts for incremental processing by dynamically adjusting the date range based on data freshness requirements.
- **Key fields**: Primary reporting `timestamp` for each MAU calculation, `joinday` timestamps representing each day within the 30-day window, and associated dimensional groupings

### Component E: MAU calculation by dimension
- **Purpose**: Calculate monthly active users across multiple dimensional breakdowns using HyperLogLog merge operations
- **Logic**: For each 30-day window, merge HyperLogLog sketches from all days within the window using `hll_count.merge_partial` to combine user sets across the time period. Extract the final distinct user count using `hll_count.extract` to produce the MAU value. Create separate dimensional views: project-level MAU aggregating across all dimensions, chain-level MAU grouping by blockchain network, user-type-level MAU grouping by trader classification, and product-level MAU grouping by specific products. Each dimensional breakdown nullifies non-relevant grouping fields while preserving the specific dimension being analyzed.
- **Key fields**: Rolling `timestamp` for MAU reporting date, `dimensions` field indicating the breakdown type, relevant dimensional identifiers (`chain_id`, `user_type`, `product_id`), and calculated `user_mau` counts

### Final aggregation
- **Combining components**: Union all dimensional MAU breakdowns (project-level, chain-level, user-type-level, and product-level) into a single output table, with each row representing a specific dimensional view of MAU for a given date
- **Currency conversion**: No currency conversion required as this metric counts users rather than monetary values
- **Time aggregation**: MAU calculated as rolling 30-day windows updated daily, with each day's MAU representing unique users active within the trailing 30-day period including that day
- **Final calculation**: The final MAU value for each dimension and date represents the approximate count of distinct user addresses that had trading activity within the 30-day rolling window, calculated through HyperLogLog sketch merging and extraction to provide memory-efficient distinct counting at scale

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

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

SynthetixSNX

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown