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 Revenue Methodology

## 1. Overview

Cryptex revenue represents the total fees earned by the Cryptex protocol from two distinct business lines: asset management fees from Cryptex v1 vaults and trading fees from Cryptex v2 perpetual trading products. The metric answers how much revenue the protocol generates daily by combining vault management fees (collected as native ETH transfers) with trading fees (calculated as a percentage of notional trading volume). Revenue is calculated by setting total fees equal to revenue, aggregated daily in USD.

## 2. Data sources

- **Ethereum native transaction flows**: Native ETH transfer data tracking outflows from Cryptex vault accounts to the treasury address
- **Arbitrum parsed event logs**: `MakeOpened`, `MakeClosed`, `TakeOpened`, and `TakeClosed` events from Cryptex Product contracts (Product, Product2, Product3, Product4) representing perpetual trading activity for TCAP and PERPE tokens
- **Oracle price feed events**: `NewTransmission` events from AccessControlledOffchainAggregator contracts on Arbitrum providing TCAP and PERPE token price updates
- **End-of-day token price feeds**: USD price data for converting ETH vault fees to USD
- **Token metadata**: Decimal precision information for proper amount normalization

## 3. Step-by-step calculation

### Component A: Vault management fees (Cryptex v1)
- **Purpose**: Captures asset management fees from Cryptex v1 vaults paid to the protocol treasury
- **Logic**: Identifies native ETH transfers from eight predefined vault account addresses to the treasury address `0xa54074b2cc0e96a43048d4a68472f7f046ac0da8`. The system tracks outflows from vault accounts using Ethereum native flow data and matches them with corresponding inflows to the treasury address using transaction unique identifiers. Only matched transfers are considered valid fee payments.
- **Key fields**: `block_timestamp` for daily aggregation, `amount` representing ETH fee amounts, `account_address` for vault identification, `unique_id` for matching transfers

### Component B: Perpetual trading data (Cryptex v2)
- **Purpose**: Captures all perpetual trading activity on Cryptex v2 for TCAP and PERPE tokens
- **Logic**: Extracts trade data from parsed Arbitrum event logs across multiple Product contracts. Includes opening and closing events for both maker and taker positions (`MakeOpened`, `MakeClosed`, `TakeOpened`, `TakeClosed` events). Trade amounts are normalized by dividing by 10^18 to account for token decimals. Data spans Product, Product2 (TCAP), Product3, and Product4 (PERPE) contracts.
- **Key fields**: `block_timestamp` for timing, `amount` for trade size, `token_symbol` for TCAP/PERPE identification, `account_address` for contract identification

### Component C: Oracle price feeds
- **Purpose**: Provides market prices for TCAP and PERPE tokens to value trading activity
- **Logic**: Processes `NewTransmission` events from AccessControlledOffchainAggregator oracle contracts on Arbitrum. Price values are normalized by dividing by 10^18. Daily average prices are calculated from all transmission events within each day. Missing price data is forward-filled using the most recent available price to ensure continuous price coverage.
- **Key fields**: `block_timestamp` for daily grouping, `answer` field containing raw price data, `token_symbol` for price association

### Component D: Notional trading volume calculation
- **Purpose**: Converts raw trade amounts into USD-denominated notional values
- **Logic**: Multiplies trade amounts from perpetual trading data with corresponding daily average token prices. Joins trade data with oracle price feeds using daily timestamps and token symbols (TCAP or PERPE). Results in USD notional trading volume for each trade.
- **Key fields**: `amount` from trades, `price_amount` from oracle feeds, calculated `notional_trading_volume`

### Component E: Trading fee calculation
- **Purpose**: Applies fee percentages to notional trading volume to determine trading fees
- **Logic**: Multiplies notional trading volume by time-based fee percentages. Uses 0.15% fee rate for trades before October 8, 2023, and 0.2125% fee rate for trades on or after this date. The fee percentage change reflects a protocol governance decision to increase trading fees.
- **Key fields**: `notional_trading_volume` as base amount, time-based fee percentage multipliers, resulting `fees`

### Final aggregation
- **Combining components**: Vault management fees (converted to USD) are combined with calculated trading fees using union operation. Both fee streams are aggregated daily by chain, maintaining separate identification for different fee sources.
- **Currency conversion**: Vault fees in ETH are converted to USD using end-of-day price feeds and proper decimal correction. Trading fees are already in USD from the notional volume calculation.
- **Time aggregation**: All data is aggregated to daily boundaries using timestamp truncation to day level. Missing days are filled with zeros to maintain continuous time series.
- **Final calculation**: Revenue equals the sum of vault management fees and trading fees, aggregated daily by chain and product identifiers. The finalization process applies schema validation, ensures no gaps in the time series through zero-filling, and applies chain availability filtering.

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

CryptexCTX

Revenue

Revenue

Competitive landscape

Chain breakdown