Thales deposits liquidity into marketplaces and receive fees from traders (revenue). The funds collected are used to buyback and burn the THALES governance token.

Thales is a non-custodial exchange for parimutuel contracts built on Optimism, Arbitrum and Polygon. Thales was founded by Danijel Gornjakovic and was launched in December 2021.

THALES tokenholders own and govern the protocol. Thales’ investors include Framework Ventures, Apollo Capital, etc.

governance

github

twitter

discord

etherscan

website

Derivative exchanges

Thales

# Thales Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who interact with Thales protocol within any 30-day rolling window. This metric answers the business question: "How many distinct users are actively trading or creating markets on Thales across all supported chains?" The calculation uses HyperLogLog sketches to efficiently count unique users across multiple dimensions including total users, breakdowns by blockchain, user type (buyers vs sellers), and product categories.

## 2. Data sources

- **Blockchain events**: Parsed smart contract events from Arbitrum, Base, Optimism, and Polygon blockchains capturing user interactions with Thales protocol
- **Trading events**: `BoughtFromAmm` and `SoldToAMM` events from ThalesAMM contracts representing binary options trading
- **Ranged market events**: `BoughtFromAmm` and `SoldToAMM` events from RangedMarketsAMM contracts for ranged binary options
- **Sports betting events**: `BoughtFromAmm` and `SoldToAMM` events from SportsAMM contracts, plus `ParlayMarketCreated` events from ParlayAMM contracts
- **Speed market events**: `MarketCreated` events from SpeedMarketsAMM contracts for fast-paced trading
- **Transaction data**: Blockchain transaction timestamps and hashes for temporal ordering
- **Chain metadata**: Network identifiers for multi-chain aggregation

## 3. Step-by-step calculation

### Component A: User event extraction
- **Purpose**: Identify all user interactions with Thales protocol across supported chains
- **Logic**: Extract user addresses from various AMM contract events across Arbitrum, Base, Optimism, and Polygon. Events include trading activities like buying from and selling to AMMs, creating parlay markets, and creating speed markets. Each user address is classified as either a "Buyer" or "Seller" based on the event type, with buyers identified from purchase events and market creation events, while sellers come from selling events. All interactions are categorized under the derivatives market sector and options business segment
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for deduplication, `chain` identifier, `user_type` classification, `user_address` for unique identification

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily unique active users with dimensional attributes
- **Logic**: Aggregate user events by truncating timestamps to day-level granularity and counting distinct user addresses per day. Group users by chain, user type (Buyer/Seller), market sector, business segment, and product to create dimensional breakdowns. This creates a daily snapshot of unique active users across all relevant dimensions
- **Key fields**: `timestamp` truncated to day, `timestamp_grain` set to "day", dimensional attributes like `chain` and `user_type`, `user_dau` containing the unique user address

### Component C: HyperLogLog sketch creation
- **Purpose**: Create memory-efficient data structures for unique user counting across time windows
- **Logic**: Convert daily active user records into HyperLogLog sketches using `hll_count.init()` with precision 15. Group by timestamp, chain, user type, and product to create one HLL sketch per dimensional combination per day. These sketches enable efficient merging across time periods without storing individual user addresses
- **Key fields**: `hll` containing the HyperLogLog sketch, dimensional grouping fields preserved from DAU calculation

### Component D: Rolling window datespine
- **Purpose**: Create a complete timeline framework for 30-day rolling MAU calculations
- **Logic**: Generate a datespine covering all days from the earliest available data to yesterday using `generate_timestamp_array()`. For each day in the datespine, create join relationships with the previous 29 days to establish 30-day windows. This ensures consistent MAU calculation even for days with no user activity, preventing gaps in the time series
- **Key fields**: `timestamp` for the target date, `joinday` representing each day within the 30-day lookback period

### Component E: Rolling window HLL aggregation
- **Purpose**: Merge HLL sketches across 30-day windows to calculate MAU
- **Logic**: Join the datespine with daily HLL sketches to create 30-day rolling windows. For each target date, collect HLL sketches from that date and the previous 29 days. Merge the collected HLL sketches using `hll_count.merge_partial()` and extract the unique count using `hll_count.extract()` to get the MAU value for each dimensional combination
- **Key fields**: Window `timestamp`, dimensional attributes from HLL sketches, merged `hll` sketch containing 30-day user activity

### Component F: Dimensional breakdowns
- **Purpose**: Create multiple views of MAU data across different business dimensions
- **Logic**: Generate four separate dimensional views: total project-level MAU (nullifying chain, product, and user type), chain-level MAU (preserving chain, nullifying others), user type-level MAU (preserving user type classification), and product-level MAU (preserving product categorization). Each breakdown applies the HLL merge and extract operations to the appropriate dimensional grouping
- **Key fields**: `dimensions` indicating the breakdown type, relevant dimensional fields preserved while others set to null, `user_mau` containing the extracted unique user count

### Final aggregation
- **Combining components**: Union all dimensional breakdown views (project-level, chain-level, user type-level, product-level) to create a comprehensive dataset with multiple analytical perspectives in a single table
- **Time aggregation**: Daily calculations with 30-day rolling windows, using day-level timestamp truncation for consistent temporal boundaries
- **Final calculation**: Extract unique user counts from merged HLL sketches representing 30-day rolling windows, producing MAU values for each dimensional combination and timestamp
- **Incremental processing**: Apply month-level partitioning with lookback logic to recalculate recent periods when data updates, using configurable incremental lookback days plus a 29-day safety margin for rolling window completeness

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

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

ThalesTHALES

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown