website

twitter

Infrastructure

Calyx

# Calyx Active users (monthly) Methodology

## 1. Overview

The Calyx Monthly Active Users (MAU) metric measures the number of unique users who have interacted with Calyx token launchpads on the NEAR blockchain within a rolling 30-day window. This metric answers the business question: "How many distinct users are actively participating in token launches through the Calyx platform over the past month?" The calculation uses HyperLogLog (HLL) sketches for efficient approximate counting and supports multiple dimensional breakdowns including project-level, chain-level, user type, and product-specific views.

## 2. Data sources

- **NEAR blockchain transaction records**: Transaction data containing user signatures, timestamps, and function call parameters for all NEAR network activity
- **NEAR blockchain receipt logs**: Execution receipts showing function call results, success/failure status, and detailed execution context
- **NEAR contract deployment data**: Contract creation receipts containing launchpad configuration parameters encoded in base64 format
- **Token launchpad metadata**: Sale token account identifiers and launchpad addresses extracted from contract deployment arguments

## 3. Step-by-step calculation

### Component A: Launchpad identification
- **Purpose**: Identifies valid Calyx launchpad contract addresses and their associated sale tokens
- **Logic**: Scans NEAR blockchain receipts for contract deployment transactions where the function call method is `new` and the receiver is a known Calyx factory contract. Extracts the `sale_token_account_id` from base64-decoded function call arguments in the receipt data. Only includes successfully executed transactions (non-FAILURE status) from October 6, 2025 onwards when the Calyx factory was deployed.
- **Key fields**: `launchpad_address` from receipt receiver, `sale_token_address` from decoded arguments, `block_timestamp` for temporal filtering

### Component B: User transaction detection
- **Purpose**: Captures all user interactions with identified Calyx launchpads through two transaction types
- **Logic**: Processes both classic NEAR transfers and intent-based transactions. For classic transfers, identifies transactions where users send tokens directly to launchpad addresses by parsing the `receiver_id` field from base64-decoded transaction arguments. For intent-based transactions, decodes signed message payloads to extract withdrawal intents targeting launchpad addresses, then matches these with corresponding `ft_on_transfer` function calls in the receipt logs. Excludes transactions where the signer is the sale token contract address itself.
- **Key fields**: `signer_account_id` as user address, `receiver_id` as launchpad target, `transaction_hash` for correlation, `block_timestamp` for timing

### Component C: Transaction validation and user classification
- **Purpose**: Filters valid transactions and classifies users by type
- **Logic**: Validates that transactions executed successfully by checking receipt execution status is not FAILURE. Correlates transactions with their corresponding receipts using transaction hash matching. Classifies all interacting users as 'Investor' type since they are depositing funds to participate in token launches. Excludes any transactions where the user address matches the sale token contract address to avoid counting contract operations as user activity.
- **Key fields**: `user_address` from signer account, `user_type` as 'Investor', `launchpad_address` for context

### Component D: Daily active user aggregation
- **Purpose**: Creates daily distinct user counts as the foundation for MAU calculation
- **Logic**: Groups validated user transactions by day using timestamp truncation to daily boundaries. Deduplicates users within each day to ensure each user is counted only once per day regardless of transaction volume. Creates records with daily granularity including chain identifier ('near'), user type, and user addresses for subsequent HLL processing.
- **Key fields**: `timestamp` truncated to day, `timestamp_grain` as 'day', `chain` as 'near', `user_dau` containing user address

### Component E: HyperLogLog window preparation
- **Purpose**: Converts daily user data to HLL sketches and creates 30-day rolling windows
- **Logic**: Initializes HLL sketches for each day's user set with 15-bit precision for approximate distinct counting. Generates a complete date spine covering the full time range to avoid gaps in the rolling window calculation. Creates join tables that associate each day with the preceding 29 days (30-day total window) using timestamp arithmetic and array generation. Joins the HLL sketches with the windowed date ranges to prepare for aggregation.
- **Key fields**: `hll` containing user sketches, `timestamp` for window calculation, dimensional fields for grouping

### Final aggregation
- **Combining components**: Merges HLL sketches across each 30-day window using `hll_count.merge_partial()` function, then extracts the final distinct count with `hll_count.extract()` to produce approximate MAU values
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 30-day rolling windows calculated daily, with each day's MAU representing unique users over the trailing 30 days including that day
- **Final calculation**: Groups the windowed HLL data by multiple dimensions (project-level, chain, user type, product) and applies the merge-extract pattern to produce MAU counts for each dimensional breakdown, then unions all breakdowns into a unified result set with standardized schema through the `finalize_metric_user_mau` macro

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

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

Calyx

Active users (monthly)

Active users (monthly)

Competitive landscape