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

## 1. Overview

ApolloX revenue represents the protocol's share of trading fees from its decentralized derivatives trading platform. The metric combines revenue from two distinct trading modes: traditional perpetual futures trading and "Dumb Mode" betting on short-term price movements. Revenue is calculated by extracting the protocol's portion of trading fees from various ApolloX smart contract events across Arbitrum, BSC, and Base blockchains.

## 2. Data sources

- **Blockchain events**: Parsed ApolloX smart contract event logs from Arbitrum, BSC, and Base blockchains
- **Trading events**: `OpenFee` and `CloseFee` events from ApolloX perpetual trading contracts (versions ApolloX2, ApolloX3, ApolloX4)
- **Dumb mode events**: `SettlePredictionSuccessful` and `PredictionCloseFee` events from ApolloX5 prediction contracts
- **External data**: End-of-day token price feeds for USD conversion
- **Token metadata**: Token decimal information for accurate amount calculations

## 3. Step-by-step calculation

### Component A: Perpetual trading revenue
- **Purpose**: Captures protocol revenue from perpetual futures trading fees
- **Logic**: Extracts revenue from `OpenFee` and `CloseFee` events emitted by ApolloX trading contracts. The revenue calculation varies by contract version due to different fee sharing models. For ApolloX2 and ApolloX3 contracts on Arbitrum and BSC, revenue equals the sum of `daoAmount` and `brokerAmount` fields. For ApolloX4 contracts on Arbitrum, BSC, and Base, revenue equals `totalFee` minus `alpPoolAmount` (representing the portion not allocated to liquidity providers)
- **Key fields**: `totalFee` (total trading fee), `daoAmount` (protocol treasury share), `brokerAmount` (broker share), `alpPoolAmount` (liquidity provider share), `token` (fee token address)

### Component B: Dumb mode trading revenue  
- **Purpose**: Captures protocol revenue from prediction-based trading fees
- **Logic**: Extracts revenue from ApolloX's "Dumb Mode" feature where users bet on minute-by-minute price movements. Data comes from two event types: `SettlePredictionSuccessful` events track total fees collected, while `PredictionCloseFee` events track the protocol's revenue portion. Revenue is calculated as the sum of `daoAmount` and `brokerAmount` from `PredictionCloseFee` events, representing the protocol's share of prediction trading fees
- **Key fields**: `closeFee` (total prediction fee), `daoAmount` (protocol treasury share), `brokerAmount` (broker share), `token` (fee token address)

### Final aggregation
- **Combining components**: Both perpetual trading and dumb mode revenue streams are unioned together with identical schema structure, aggregated by day, chain, and token
- **Currency conversion**: Token amounts are converted to USD using end-of-day price feeds, with decimal correction applied based on token metadata
- **Time aggregation**: All revenue data is aggregated to daily boundaries using timestamp truncation to day level
- **Final calculation**: The final metric represents the total daily USD value of protocol revenue across all trading modes, calculated as the sum of all revenue amounts after decimal correction and USD conversion

*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.

APX V2APX

Revenue

Revenue

Competitive landscape

Chain breakdown