The option buyers pay premiums (revenue) to HEGIC stakers, who collateralize the option positions and cover the buyers' potential profits from their collateral.

Hegic is a non-custodial options exchange built on Arbitrum. Hegic was founded by Molly Wintermute and launched in 2020.



HEGIC tokenholders own and govern the protocol. They charge a premium (revenue) for each option that is bought on the platform.

github

twitter

discord

etherscan

website

Derivative exchanges

Hegic

# Hegic Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Hegic measures the number of unique users who interacted with the Hegic options protocol within any 30-day rolling period. This metric answers the business question: "How many distinct users are actively trading options on Hegic each month?" The calculation uses probabilistic counting with HyperLogLog algorithms to efficiently aggregate daily active users across sliding 30-day windows, providing breakdowns by chain, user type, and product dimensions.

## 2. Data sources

The metric relies on these raw blockchain data sources:
- **Arbitrum smart contract events**: Parsed `OperationalTreasury_Paid_event` and `PositionsManager_Transfer_event` logs from Hegic v1 protocol contracts
- **Transaction metadata**: Block timestamps and transaction hashes from Arbitrum blockchain
- **Chain availability data**: Configuration data determining which blockchain networks are included in calculations

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Extracts and classifies user interactions from Hegic smart contract events
- **Logic**: Processes two types of Arbitrum events to identify user activity. For option exercises, extracts the `account` parameter from `OperationalTreasury_Paid_event` logs and classifies these users as "Option Exerciser". For option purchases, extracts the `to` parameter from `PositionsManager_Transfer_event` logs where the `from` address is the null address (indicating new position creation) and classifies these users as "Option Buyer". Each interaction captures the block timestamp, transaction hash, chain identifier, and user address.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for uniqueness, `user_address` for user identification, `user_type` for classification, `chain` for network identification

### Component B: Daily active user aggregation  
- **Purpose**: Aggregates user interactions into daily active user counts
- **Logic**: Groups the classified user interactions by day using timestamp truncation to the daily level. Creates distinct counts of active users for each day, grouped by chain, user type, market sector, business segment, and product dimensions. Applies chain availability filtering to ensure only supported networks are included. Uses "day" as the timestamp grain for downstream processing.
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain`, `chain`, `user_type`, `product_id`, `user_dau` (distinct user address)

### Component C: HyperLogLog initialization
- **Purpose**: Prepares daily user data for efficient probabilistic counting in MAU windows
- **Logic**: Initializes HyperLogLog sketches from the daily active user data with a precision of 15 bits. Groups data by timestamp, timestamp grain, chain, user type, and product to create HLL objects that can be efficiently merged across time windows. This probabilistic approach enables accurate distinct counting across large datasets without storing individual user identifiers.
- **Key fields**: `hll` (HyperLogLog sketch), all grouping dimensions preserved from DAU data

### Component D: Rolling window creation
- **Purpose**: Establishes 30-day sliding windows for MAU calculation
- **Logic**: Creates a datespine covering all days from the earliest user activity to the current date. For each day in the spine, generates a 30-day lookback period using timestamp arrays. Joins each day with its corresponding 30-day historical window to create the foundation for rolling MAU calculations. Handles incremental processing by applying lookback margins based on last modified times.
- **Key fields**: `timestamp` (current day), `joinday` (days within the 30-day window)

### Component E: Window aggregation and HLL merging
- **Purpose**: Combines HyperLogLog sketches across 30-day windows to calculate MAU
- **Logic**: Joins the rolling window structure with the HLL daily data, matching each window day with its corresponding HLL sketch. For each 30-day period, merges all HLL sketches within that window to create a combined distinct user count. This approach captures all users who were active on any day within each 30-day period.
- **Key fields**: `hll` (merged across window), dimensional groupings maintained

### Component F: Dimensional breakdowns
- **Purpose**: Creates MAU metrics across different business dimensions
- **Logic**: Generates four separate breakdown views: project-level (aggregating all dimensions), chain-level (breaking down by blockchain network), user-type-level (separating Option Exercisers and Option Buyers), and product-level (separating by specific products). Each breakdown uses HLL merge operations to combine sketches appropriately and extracts the final distinct count. Non-applicable dimensions are set to null for each breakdown.
- **Key fields**: `dimensions` (breakdown type), `user_mau` (extracted HLL count), relevant dimension values

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a comprehensive view with multiple breakdown perspectives in a single dataset
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 30-day rolling windows with daily granularity, creating continuous MAU measurements rather than discrete monthly periods
- **Final calculation**: The final MAU value is extracted from merged HyperLogLog sketches using the `hll_count.extract` function, providing probabilistically accurate distinct user counts across each 30-day window. The `finalize_metric_user_mau` macro applies standardized schema formatting and zero-filling for missing time periods.

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

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

HegicHEGIC

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown