Polynomial Protocol builds on top of Synthetix to create a synthetic perpetuals trading platform. Traders on Polynomial trade futures against the liquidity provided by liquidity providers on Synthetix, with liquidity providers receiving trading fees (supply-side fees).

Polynomial Protocol is a non-custodial exchange for perpetual contracts built on Optimism. Polynomial Protocol was founded by Gautham Santhosh, Salman Naseer Ahmed, & Mubaris NK, and their flagship product Polynomial Trade was launched in 2023.

The Polynomial team own and govern the protocol. Polynomial’s investors include Archetype, Genblock Capital, Caballeros Capital, etc.

github

twitter

discord

website

Derivative exchanges

Polynomial Protocol

# Polynomial Protocol Active users (monthly) Methodology

## 1. Overview

The Polynomial MAU (Monthly Active Users) metric measures the number of unique users who interact with Polynomial Protocol's perpetual futures trading platform over rolling 30-day periods. This metric captures user engagement by tracking addresses that execute trades through Polynomial's integration with Synthetix's perpetual futures contracts on Optimism. The calculation uses HyperLogLog data structures to efficiently count unique users across overlapping time windows and provides breakdowns by chain, user type, and product dimensions.

## 2. Data sources

The calculation relies on these underlying raw data sources:

- **Synthetix perpetual futures events**: Parsed `PerpsTracking` events from Synthetix V2 perpetual futures proxy contracts on Optimism, capturing user trading activity across multiple contract versions (ProxyPerpsV2, ProxyPerpsV21, ProxyPerpsV22)
- **Position modification events**: Parsed `PositionModified` events from the same Synthetix perpetual contracts, indicating when users open, modify, or close trading positions
- **Polynomial limit order events**: Parsed events from Polynomial's limit order contracts including `ExecuteRequest`, `ExecuteLimitOrder`, and `ExecutePairOrder` events from SynthetixLimitOrders and AdvancedOrders contracts
- **Optimism blockchain data**: Transaction hashes, block timestamps, and event logs from Optimism network
- **Tracking code filtering**: Events filtered by Polynomial's specific tracking code (`0x706f6c796e6f6d69616c00000000000000000000000000000000000000000000`) to isolate protocol-specific activity

## 3. Step-by-step calculation

### Component A: User event identification
- **Purpose**: Identifies valid user trading activity specific to Polynomial Protocol
- **Logic**: Extracts user addresses from two types of trading events on Optimism. First, captures market order activity by parsing `PerpsTracking` and `PositionModified` events from Synthetix perpetual futures contracts across multiple versions. Second, captures limit order activity from Polynomial's dedicated limit order execution contracts. All events are validated by checking that the transaction contains Polynomial's specific tracking code, ensuring only protocol-attributable activity is included. Each user is classified as a 'Trader' type engaging with 'derivatives' in the 'perpetual' business segment.
- **Key fields**: `account` and `user` addresses from events, `block_timestamp` for timing, `transaction_hash` for deduplication, `trackingCode` for protocol filtering

### Component B: Daily active user calculation  
- **Purpose**: Aggregates identified users into daily unique counts
- **Logic**: Groups all valid user events by day using timestamp truncation, then counts distinct user addresses per day. Maintains dimensional attributes including chain identifier, user type classification, and product categorization. Each day produces a set of unique user addresses who performed at least one trading action through Polynomial Protocol.
- **Key fields**: `timestamp` truncated to day grain, distinct `user_address` as `user_dau`, `chain`, `user_type`, `product_id`

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily user sets into HyperLogLog data structures for efficient unique counting
- **Logic**: Takes the daily active user data and initializes HyperLogLog sketches for each day's user set. Uses precision parameter of 15 bits to balance memory efficiency with counting accuracy. This probabilistic data structure allows efficient merging of user counts across multiple days without storing individual user identifiers.
- **Key fields**: `hll` structures initialized from daily `user_dau` sets, maintaining timestamp and dimensional groupings

### Component D: Rolling window generation
- **Purpose**: Creates 30-day rolling windows for MAU calculation
- **Logic**: Generates a complete datespine covering all days from the earliest user activity to the current date. For each day in this spine, creates joins to the previous 29 days (plus the current day) to form 30-day windows. This approach ensures every day has a complete 30-day lookback period, even if some intermediate days had no user activity. The windowing handles incremental processing by focusing on recent time periods while maintaining lookback safety margins.
- **Key fields**: `timestamp` for the MAU measurement date, `joinday` for the days included in each 30-day window

### Component E: MAU aggregation by dimensions
- **Purpose**: Calculates unique monthly active users across different dimensional breakdowns
- **Logic**: For each 30-day window, merges the HyperLogLog structures from all days in that window and extracts the final unique user count. Creates separate breakdowns for: project-level totals (all dimensions nulled), chain-level (grouped by chain), user-type-level (grouped by user type), and product-level (grouped by product). Each breakdown maintains the appropriate dimensional attributes while nulling out irrelevant dimensions. The HyperLogLog merge operation efficiently handles overlapping users across the 30-day period.
- **Key fields**: `user_mau` as the final unique count, `dimensions` indicating breakdown type, dimension-specific fields (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project-level, chain-level, user-type-level, product-level) into a single result set, creating a comprehensive view of MAU across all relevant dimensions
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Each record represents a 30-day rolling window ending on the specified date, with daily granularity for the measurement periods
- **Final calculation**: The `user_mau` field contains the count of unique users who were active within the 30-day period ending on each date, calculated by merging and extracting HyperLogLog structures. Missing periods are filled with zeros, and incremental processing maintains data freshness with appropriate lookback periods for recalculation.

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

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

Polynomial Protocol

Active users (monthly)

Active users (monthly)

Competitive landscape