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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active user on the Cryptex protocol. This metric divides total daily revenue by the number of daily active users to understand revenue efficiency and user monetization. The calculation combines revenue from two product lines: Cryptex v1 asset management fees and Cryptex v2 perpetual trading fees, divided by users who interact with either product.

## 2. Data sources

- **Ethereum vault events**: Parsed `TokensMinted` and `TokensBurned` events from Cryptex v1 vault handler contracts (AAVE, LINK, DAI, ETH, USDC, WBTC handlers)
- **Arbitrum perpetual trading events**: Parsed trading events (`MakeOpened`, `MakeClosed`, `TakeOpened`, `TakeClosed`) from Cryptex v2 Product contracts 1-4 for TCAP and PERPE tokens
- **Arbitrum oracle price feeds**: Parsed `NewTransmission` events from `AccessControlledOffchainAggregator` contracts providing TCAP and PERPE price updates
- **Ethereum native transfers**: Native ETH transfer traces and flows to identify vault management fee payments
- **End-of-day token price feeds**: Token price data for USD conversion of fee amounts
- **Token metadata**: Token decimal and symbol information for amount normalization

## 3. Step-by-step calculation

### Component A: Revenue calculation

- **Purpose**: Calculates total daily revenue from both Cryptex v1 and v2 operations
- **Logic**: Revenue combines two distinct fee streams. For Cryptex v1, it captures native ETH transfers from vault accounts to the treasury address, representing asset management fees. These transfers are identified by matching outbound native flows from predefined vault addresses with inbound flows to the treasury address using transaction identifiers. For Cryptex v2, it calculates trading fees as a percentage of notional trading volume. The percentage applied is 0.15% for dates before 2023-10-08 and 0.2125% for dates after. All fees are converted to USD using end-of-day token prices and aggregated by day.
- **Key fields**: `amount` from transfer events, `fees` calculated from notional volume, `timestamp` for daily aggregation

### Component B: Notional trading volume calculation

- **Purpose**: Calculates USD value of perpetual trading volume for v2 fee calculation
- **Logic**: Extracts trade amounts from Arbitrum perpetual trading events across four Product contracts. Trade amounts are captured from `MakeOpened`, `MakeClosed`, `TakeOpened`, and `TakeClosed` events, with amounts converted from wei to decimal by dividing by 10^18. These trade amounts are joined with corresponding daily average token prices from oracle price feed updates. Oracle prices come from `AccessControlledOffchainAggregator` `NewTransmission` events, with prices normalized by dividing by 10^18. Daily average prices are calculated and forward-filled for missing days. The final notional volume multiplies trade amounts by their respective token prices.
- **Key fields**: `amount` from trading events, `price_amount` from oracle feeds, `token_symbol` for joining trades to prices

### Component C: Daily active users calculation

- **Purpose**: Counts distinct users who interact with Cryptex protocols each day
- **Logic**: Identifies active users from Ethereum-based mint and burn operations on Cryptex v1 vault handlers. Users are captured from `TokensMinted` and `TokensBurned` events across multiple vault handler contracts including AAVE, LINK, DAI, ETH, USDC, and WBTC handlers. Each user interaction extracts the user address from the `owner` parameter. Users are classified as either 'TCAP Minter' or 'TCAP Burner' based on the event type. Distinct user addresses are counted per day using HyperLogLog aggregation for efficiency. The aggregation creates multiple dimensional views including project-level, chain-level, and user-type-level breakdowns.
- **Key fields**: `owner` as user address, `block_timestamp` for daily grouping, `user_type` for classification

### Final aggregation

- **Combining components**: Revenue and user count are calculated independently and then combined using the ARPU macro. Revenue represents the sum of all daily fees from both v1 vault management and v2 trading activities. User count represents the distinct number of users who performed any mint or burn operation on any supported vault handler.
- **Currency conversion**: All fee amounts are converted to USD using end-of-day token price feeds. Native ETH transfers use ETH prices, while trading fees use the underlying token prices (TCAP or PERPE) from oracle feeds.
- **Time aggregation**: Both revenue and user metrics are aggregated to daily boundaries using timestamp truncation. Missing data points are filled with zeros to ensure complete time series.
- **Final calculation**: ARPU equals total daily revenue divided by daily active users. The calculation uses the standard formula: Daily Revenue ÷ Daily Active Users = ARPU. Days with zero active users result in null ARPU values rather than division by zero errors.

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

CryptexCTX

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape