On Cryptex v1, overcollateralized investors deposit funds into Cryptex and mint TCAP tokens. On Cryptex v2, traders trade leveraged perpetual contracts against liquidity pools supplied by liquidity providers.

Cryptex v1 is non-custodial asset management protocol built on Ethereum, while Cryptex v2 is an exchange for perpetual contracts on Arbitrum. Cryptex was founded by Joe Sticco, Preston Van Loon & Thomas Matzner and launched in 2021.

CTX token holders own and govern the protocol. They currently take all of the total withdrawal fees paid by investors and trading fees paid by traders (revenue).

github

twitter

discord

etherscan

website

Asset management

Cryptex

# Cryptex Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Cryptex measures the number of unique users who interacted with Cryptex's TCAP (Total Crypto Market Cap Token) vault system within any 30-day rolling period. This metric tracks user engagement with the protocol by counting distinct addresses that either minted or burned TCAP tokens through various collateral vault handlers. The calculation uses HyperLogLog algorithms for efficient distinct user counting across multiple dimensional breakdowns.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Ethereum blockchain event logs**: Parsed event data from Cryptex vault handler smart contracts
- **Vault handler contract events**: Specific events from multiple Cryptex vault handlers including AAVE, LINK, DAI, ETH, USDC, and WBTC vault handlers
- **TokensMinted events**: Blockchain events capturing when users mint TCAP tokens using collateral
- **TokensBurned events**: Blockchain events capturing when users burn TCAP tokens to withdraw collateral
- **Contract interaction data**: Transaction and block timestamp information from Ethereum blockchain

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Identify unique users and classify their interaction types with the Cryptex protocol
- **Logic**: Extract user addresses from parsed Ethereum event logs for multiple Cryptex vault handler contracts. Each vault handler manages different collateral types (AAVE, LINK, DAI, ETH, USDC, WBTC) and emits either `TokensMinted` or `TokensBurned` events. Users are classified as either 'TCAP Minter' when they mint tokens or 'TCAP Burner' when they burn tokens. The system captures the `owner` parameter from these events as the user address along with transaction metadata.
- **Key fields**: `owner` (user address), `block_timestamp`, `transaction_hash`, `log_index`, event type classification

### Component B: Daily active user aggregation
- **Purpose**: Aggregate user activity into daily snapshots with efficient distinct counting
- **Logic**: Group all user interactions by day using timestamp truncation to the day level. For each day, collect all unique user addresses that performed any vault operations. Initialize HyperLogLog data structures for each daily user set to enable efficient distinct counting in later steps. Maintain dimensional attributes including chain, user type, and product identifiers.
- **Key fields**: `timestamp` (daily grain), `user_address`, `chain`, `user_type`, HLL initialization for distinct counting

### Component C: Rolling window construction
- **Purpose**: Create 30-day rolling windows for MAU calculation using complete time coverage
- **Logic**: Generate a complete datespine covering all days from the first recorded activity to the current date minus one day. For each day in the datespine, create associations with the previous 30 days (including the current day) to form rolling windows. Join this window structure with the daily user HLL data to ensure every day has visibility into the full 30-day historical period, even if some days had no activity.
- **Key fields**: `timestamp` (target date), `joinday` (days within the 30-day window), daily HLL data

### Component D: Monthly active user calculation
- **Purpose**: Calculate distinct users active within each 30-day period using HLL operations
- **Logic**: For each target date, merge the HyperLogLog structures from all days within the 30-day rolling window. Use HLL partial merge operations to combine daily distinct user sets, then extract the final distinct count. This approach efficiently handles the overlap of users who were active on multiple days within the window without double-counting them.
- **Key fields**: Merged HLL structures, extracted distinct user counts

### Component E: Dimensional breakdowns
- **Purpose**: Provide MAU metrics across multiple analytical dimensions
- **Logic**: Calculate separate MAU aggregations for different dimensional views: project-level (overall protocol MAU), by chain (currently Ethereum only), by user type (separating minters from burners), and by product identifier. Each breakdown uses the same HLL merge and extract operations but groups by different dimensional attributes. Null values are used for dimensions not relevant to each specific breakdown.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`, `user_mau` (final count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, with each row representing MAU for a specific date and dimensional combination
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily grain with 30-day rolling windows, partitioned by month for efficient incremental processing
- **Final calculation**: The final MAU value for each date represents the count of distinct users who performed any vault operation (minting or burning TCAP tokens) within the 30-day period ending on that date, calculated using HyperLogLog extract operations on merged daily user sets

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

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

CryptexCTX

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown