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

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with the Hegic options protocol within any 7-day period. This metric helps track user engagement and protocol adoption by counting distinct addresses that either purchase new options or exercise existing options. The calculation uses HyperLogLog data structures to efficiently compute unique user counts across rolling 7-day windows, providing multiple dimensional breakdowns including project-level, chain-level, user-type, and product-level perspectives.

## 2. Data sources

- **Arbitrum blockchain event logs**: Parsed smart contract events from Hegic v1 protocol deployed on Arbitrum
- **OperationalTreasury events**: `Paid` events that capture option exercise transactions with user account information
- **PositionsManager events**: `Transfer` events that track option purchases, specifically filtering for transfers from the null address to identify new option minting
- **Transaction metadata**: Block timestamps from Arbitrum transactions to establish temporal boundaries for daily and weekly aggregations

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Identify and classify unique users interacting with Hegic protocol
- **Logic**: Extract user addresses from two types of Arbitrum events. For option exercisers, parse the `account` field from `OperationalTreasury` `Paid` events. For option buyers, parse the `to` field from `PositionsManager` `Transfer` events, but only include transfers where the `from` address is the null address (0x0000000000000000000000000000000000000000), indicating new option creation rather than secondary transfers. Each user interaction is tagged with metadata including chain (Arbitrum), market sector (derivatives), business segment (option), and user type (Option Exerciser or Option Buyer).
- **Key fields**: `user_address` (extracted from event parameters), `user_type` (Option Exerciser or Option Buyer), `block_timestamp` (transaction timing), `chain` (always Arbitrum for Hegic v1)

### Component B: Daily active user aggregation
- **Purpose**: Convert individual user interactions into daily unique user counts while preserving dimensional attributes
- **Logic**: Group all user interactions by calendar day using timestamp truncation to day boundaries. For each day, maintain lists of unique user addresses along with their associated dimensions including chain, user type, market sector, business segment, and product ID. Apply chain availability filters to ensure data quality and completeness.
- **Key fields**: `timestamp` (daily boundary), `user_dau` (unique user address), `chain`, `user_type`, `product_id`, `timestamp_grain` (set to 'day')

### Component C: HyperLogLog initialization and 7-day window creation
- **Purpose**: Prepare daily user data for efficient weekly unique counting using probabilistic data structures
- **Logic**: Convert each day's unique user list into a HyperLogLog data structure using 15-bit precision for memory-efficient set operations. Create a comprehensive datespine covering all days from the earliest data to the current date. For each day in the datespine, generate a 7-day lookback window by creating timestamps for the current day plus the previous 6 days. Join this 7-day window with the daily HLL data to create overlapping weekly periods.
- **Key fields**: `hll` (HyperLogLog structure containing user addresses), `timestamp` (current day), `joinday` (each day in the 7-day window)

### Component D: Weekly unique user calculation by dimension
- **Purpose**: Calculate weekly active users across different dimensional breakdowns while maintaining data structure consistency
- **Logic**: For each 7-day window, merge the HyperLogLog structures from all 7 days and extract the unique user count. Create separate calculations for four dimensional perspectives: project-level (aggregating across all dimensions), chain-level (preserving chain breakdown), user-type-level (preserving user type classification), and product-level (preserving product ID breakdown). For each breakdown, set non-relevant dimensional fields to null to maintain consistent schema structure.
- **Key fields**: `user_wau` (weekly unique user count), `dimensions` (breakdown type identifier), `chain_id`, `user_type`, `product_id`

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, ensuring each row represents a specific combination of timestamp, dimensional perspective, and metric value
- **Time aggregation**: Apply 7-day rolling windows where each day's WAU represents unique users active in that day plus the previous 6 days
- **Final calculation**: Extract unique user counts from merged HyperLogLog structures using `hll_count.extract(hll_count.merge_partial(hll))` to get precise weekly active user counts
- **Schema standardization**: Apply the `finalize_metric_user_wau` macro to standardize output schema, add project metadata, and fill missing time periods with zero values to ensure complete time series

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

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

HegicHEGIC

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown