Liquidity providers deposit funds into Thetanuts and receive option premiums from traders (supply-side fees).

Thetanuts is a non-custodial DeFi Options Vault (DOV) protocol built on Ethereum, Fantom, Polygon, and other blockchains. Thetanuts was founded by Dexter Song and launched in Dec 2021.

Thetanuts team own and govern the protocol. Their investors include Deribit Exchange, QCP Capital, Jump Crypto, etc.

twitter

discord

website

Asset management

Thetanuts

# Thetanuts Active users (weekly) Methodology

## 1. Overview

Weekly active users (WAU) measures the number of unique users who interact with Thetanuts' covered call yield strategies within any 7-day period. This metric answers how many distinct users are actively depositing to or withdrawing from Thetanuts' automated options strategies across multiple blockchains. The calculation uses a rolling 7-day window approach with HyperLogLog probabilistic counting to efficiently handle large-scale unique user identification across chains.

## 2. Data sources

The calculation relies on the following blockchain data sources:
- **Thetanuts smart contract events**: Parsed `Deposit` and `Withdraw` events from covered call contracts across six blockchains
- **Multi-chain blockchain event logs**: Event logs from Arbitrum, Avalanche, BSC, Ethereum, Fantom, and Polygon networks
- **Contract interaction data**: Transaction hashes, block timestamps, log indices, and user addresses from covered call contract interactions
- **Chain-specific contract events**: `CoveredCallArb_Deposit_event`, `CoveredCallAvax_Deposit_event`, `CoveredCallBnb_Deposit_event`, `CoveredCallEthA_Deposit_event`, `CoveredCallFtm_Deposit_event`, `CoveredCallMatic_Deposit_event` and their corresponding withdrawal events

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identifies all user interactions with Thetanuts covered call contracts across multiple blockchains
- **Logic**: Extracts `Deposit` and `Withdraw` events from six different covered call contracts, one per supported blockchain. For each event, captures the user address from the `from` parameter, classifying users as either 'Depositor' or 'Withdrawer' based on the event type. Includes transaction metadata such as block timestamp, transaction hash, and log index. Assigns market sector as 'asset_management' and business segment as 'yield_aggregator' for all interactions.
- **Key fields**: `block_timestamp` for timing, `user_address` for user identification, `chain` for blockchain source, `user_type` for interaction classification, `transaction_hash` and `log_index` for uniqueness

### Component B: Daily active user aggregation  
- **Purpose**: Converts raw user interactions into daily active user counts
- **Logic**: Groups user interactions by day using timestamp truncation to day boundaries. Counts distinct user addresses within each day, chain, user type, and product combination. Creates daily snapshots that serve as the foundation for weekly rolling calculations.
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing distinct user addresses, `chain` for blockchain grouping, `user_type` for interaction type grouping

### Component C: HyperLogLog initialization
- **Purpose**: Prepares daily user data for efficient unique counting across time windows
- **Logic**: Initializes HyperLogLog sketches for each daily user set using `hll_count.init` with precision parameter 15. This probabilistic data structure enables efficient approximate counting of unique users when merging across multiple days. Groups by timestamp, chain, user type, and product dimensions.
- **Key fields**: `hll` containing HyperLogLog sketch for each day's unique users, dimensional grouping fields for later breakdowns

### Component D: Complete datespine generation
- **Purpose**: Creates a comprehensive time series covering all days from earliest data to present
- **Logic**: Generates a complete array of daily timestamps from the minimum timestamp in the DAU data to yesterday using `generate_timestamp_array`. This ensures the rolling window calculation doesn't skip days that have no activity. For incremental updates, starts from a calculated lookback period to handle late-arriving data.
- **Key fields**: `timestamp` containing every day in the analysis period

### Component E: Rolling window construction
- **Purpose**: Creates 7-day sliding windows for each target date
- **Logic**: For each day in the datespine, generates an array of 7 days (6 days prior plus the target day) using `generate_timestamp_array` with interval 1 day. Creates a cross-product between the datespine and these joinday arrays, resulting in multiple rows per target date that represent the days included in that date's 7-day window.
- **Key fields**: `timestamp` for the target date, `joinday` for each day included in that date's 7-day window

### Component F: Window data joining
- **Purpose**: Combines the 7-day windows with actual daily user data
- **Logic**: Joins the rolling window structure with the HyperLogLog daily data on matching joinday timestamps. This creates a dataset where each target date has multiple rows representing the daily user data for all days in its 7-day window. Includes incremental processing filters to handle updates efficiently.
- **Key fields**: `timestamp` for target date, `hll` for daily user sketches, dimensional breakdown fields

### Component G: Dimensional WAU calculations
- **Purpose**: Calculates weekly active users across four different dimensional breakdowns
- **Logic**: Merges HyperLogLog sketches across 7-day windows using `hll_count.merge_partial`, then extracts final unique user counts with `hll_count.extract`. Creates separate aggregations for:
  - Project level: Overall WAU across all chains and user types  
  - Chain level: WAU breakdown by individual blockchain
  - User type level: WAU breakdown by Depositor vs Withdrawer
  - Product level: WAU breakdown by product (currently null for Thetanuts)
- **Key fields**: `user_wau` containing unique user count, `dimensions` indicating breakdown type, relevant dimension fields populated while others set to null

### Final aggregation
- **Combining components**: Unions all dimensional breakdown results into a single table using `union all` operations, creating a comprehensive view with different dimension perspectives in separate rows
- **Currency conversion**: Not applicable for user counting metrics
- **Time aggregation**: Uses 7-day rolling windows where each day's WAU represents unique users active in that day plus the 6 preceding days
- **Final calculation**: Applies the `finalize_metric_user_wau` macro to standardize the schema, add metadata fields like `data_id` set to 'thetanuts', and fill missing days with zero values. The final metric value represents the approximate count of unique users who interacted with Thetanuts contracts within any 7-day period ending on the specified date.

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

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

Thetanuts

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown