Liquidity providers deposit funds into APX and receive trading fees from traders (supply-side fees).

APX Finance is a non-custodial exchange for perpetual contracts built on BNB Chain, Arbitrum, and Base.

APX tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). APX's investors include Binance Labs, Kronos Research, etc.

github

twitter

etherscan

website

Derivative exchanges

APX V2

# APX V2 Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for ApolloX measures the number of unique users who performed trading activities on the ApolloX derivatives protocol during any 7-day rolling window. This metric answers the business question of how many distinct traders are actively engaging with ApolloX's perpetual trading and prediction betting features across multiple blockchain networks on a weekly basis. The calculation uses probabilistic counting methods (HyperLogLog) to efficiently handle large-scale user counting while maintaining accuracy, and provides dimensional breakdowns by chain, user type, and product.

## 2. Data sources

- **Blockchain events**: Parsed smart contract events from ApolloX trading protocols deployed on Arbitrum, Base, and BSC networks
- **Transaction data**: Blockchain transaction logs containing ApolloX contract interactions, including trade execution events and prediction betting activities
- **Event types**: Trading events such as `OpenMarketTrade`, `CloseTradeSuccessful`, `ExecuteCloseSuccessful` for perpetual trading, and `PredictAndBet` events for prediction market activities
- **User activity data**: User addresses extracted from trading event parameters along with transaction timestamps and chain identifiers

## 3. Step-by-step calculation

### Component A: User activity identification
- **Purpose**: Identifies all users who interact with ApolloX trading protocols across supported chains
- **Logic**: Collects parsed smart contract events from ApolloX protocols on Arbitrum, Base, and BSC. Events include trade opening, closing, execution, and prediction betting activities. Each event contains a user address parameter that identifies the trader. Users are classified into two types: "Perpetual trader" for users engaging in standard derivatives trading (open/close trade events), and "Dumb Mode trader" for users participating in prediction betting. All events include block timestamp for temporal analysis and chain identifier for multi-chain tracking.
- **Key fields**: `user_address` extracted from event parameters, `block_timestamp` for timing, `chain` identifier, `user_type` classification, `transaction_hash` for deduplication

### Component B: Daily active user aggregation  
- **Purpose**: Creates daily snapshots of unique active users across all chains and user types
- **Logic**: Groups all user activity events by calendar day using timestamp truncation to day boundaries. For each day, creates distinct user counts grouped by chain, user type, market sector, business segment, and product dimensions. Applies chain availability filtering to ensure data quality and completeness. This creates a foundation layer of daily active users that serves as input for weekly calculations.
- **Key fields**: `timestamp` (daily boundary), `user_address` as unique identifier, dimensional attributes (`chain`, `user_type`, `product_id`)

### Component C: HyperLogLog initialization for efficient counting
- **Purpose**: Converts daily user sets into probabilistic data structures for efficient unique counting across rolling windows
- **Logic**: Takes the daily active user data and initializes HyperLogLog (HLL) data structures for each day and dimensional combination. HLL allows for efficient estimation of distinct counts when merging across multiple time periods without storing individual user identifiers. Uses precision parameter of 15 for high accuracy while maintaining computational efficiency.
- **Key fields**: `hll` data structure containing probabilistic user count representation, maintaining all dimensional groupings

### Component D: Rolling window generation
- **Purpose**: Creates complete 7-day rolling windows for every day in the time series without gaps
- **Logic**: Generates a complete datespine covering all days from the earliest data to present, then creates joinable 7-day windows by generating timestamp arrays from 6 days prior to each target date. This ensures that even if certain days have no activity, they are still represented in the weekly calculations. Uses cross join logic to map each day to its corresponding 7-day lookback period.
- **Key fields**: `timestamp` (target day), `joinday` (days within the 7-day window)

### Component E: Weekly aggregation with dimensional breakdowns
- **Purpose**: Merges daily HLL structures across 7-day windows and calculates unique weekly users across multiple dimensional cuts
- **Logic**: Joins the rolling window structure with daily HLL data to collect all user activity within each 7-day period. Merges HLL structures using `hll_count.merge_partial` to combine probabilistic counts while preserving uniqueness across the full window. Creates four dimensional breakdowns: project-level (all chains combined), by individual chain, by user type (Perpetual vs Dumb Mode traders), and by product. Each breakdown nullifies non-relevant dimensional attributes while preserving the target dimension for analysis.
- **Key fields**: `user_wau` (extracted unique count from merged HLL), `dimensions` (breakdown type), dimensional identifiers (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project-level, chain-level, user type, product-level) into a single result set with standardized schema
- **Time aggregation**: Uses daily timestamp boundaries with 7-day rolling windows, ensuring complete coverage without gaps via datespine methodology  
- **Missing data handling**: Applies fill strategy to populate zero values for periods with no user activity, maintaining complete time series continuity
- **Final calculation**: The weekly active user count represents the distinct number of users who performed any ApolloX trading activity (perpetual trading or prediction betting) within any 7-day rolling period, calculated using probabilistic counting methods for computational efficiency while maintaining high accuracy

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

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

APX V2APX

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown