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 Supply-side fees Methodology

## 1. Overview

Fees supply side represents the portion of total trading fees that goes to liquidity providers and other supply-side participants in the ApolloX protocol. This metric is calculated by subtracting protocol revenue from total trading fees, with the remainder representing fees distributed to supply-side participants who provide liquidity and other services to the platform. The calculation covers both regular perpetual trading and ApolloX's "Dumb Mode" trading feature across Arbitrum, BNB Chain, and Base networks.

## 2. Data sources

The methodology relies on several key data sources:
- **ApolloX smart contract events**: Parsed `OpenFee` and `CloseFee` events from ApolloX contracts (versions 2-5) on Arbitrum, BNB Chain, and Base networks containing trading fee information
- **ApolloX5 Dumb Mode events**: Parsed `SettlePredictionSuccessful` and `PredictionCloseFee` events from ApolloX5 contracts on Arbitrum and BNB Chain for Dumb Mode trading fees
- **Token metadata**: Contract information including decimal places for proper amount calculation
- **End-of-day price feeds**: Daily token price data for USD conversion of fee amounts

## 3. Step-by-step calculation

### Component A: Perpetual trading fees extraction
- **Purpose**: Captures fees from regular perpetual trading activities across ApolloX contract versions
- **Logic**: Extracts both `OpenFee` and `CloseFee` events from ApolloX contracts on Arbitrum, BNB Chain, and Base. For ApolloX2 and ApolloX3 contracts, the `totalFee` field contains the complete trading fee while `daoAmount` plus `brokerAmount` represents the protocol revenue portion. For ApolloX4 and ApolloX5 contracts, `totalFee` minus `alpPoolAmount` calculates the protocol revenue portion. Each event is processed to extract the fee amount, revenue amount, token address, timestamp, and chain information.
- **Key fields**: `totalFee` (total trading fee), `daoAmount` and `brokerAmount` (revenue components for v2/v3), `alpPoolAmount` (liquidity provider allocation for v4/v5), `token` (fee token address), `block_timestamp` (transaction timing)

### Component B: Dumb mode trading fees extraction
- **Purpose**: Captures fees from ApolloX's Dumb Mode trading feature where users bet on minute-by-minute price fluctuations
- **Logic**: Processes `SettlePredictionSuccessful` events to capture total Dumb Mode trading fees via the `closeFee` field, and `PredictionCloseFee` events to capture protocol revenue portions via `daoAmount` plus `brokerAmount`. These events are only available on Arbitrum and BNB Chain for ApolloX5 contracts. The extracted data follows the same structure as perpetual trading fees for consistent processing.
- **Key fields**: `closeFee` (total Dumb Mode trading fee), `daoAmount` and `brokerAmount` (protocol revenue portions), `token` (fee token address), `block_timestamp` (event timing)

### Component C: Total fees aggregation
- **Purpose**: Combines all fee data and converts to standardized daily USD amounts
- **Logic**: Unions perpetual trading fees and Dumb Mode fees, then groups by day, chain, and token address. Applies decimal correction based on token metadata and converts all amounts to USD using end-of-day exchange rates. Aggregates fee amounts across all transactions within each day-chain-token combination. Applies zero-filling to ensure continuous daily time series even when no trading activity occurs.
- **Key fields**: Aggregated `fees` amounts in USD, daily `timestamp` boundaries, `chain_id` identifiers

### Component D: Total revenue aggregation  
- **Purpose**: Combines all protocol revenue data using the same aggregation logic as total fees
- **Logic**: Unions revenue portions from both perpetual trading and Dumb Mode events, applying the same daily aggregation, decimal correction, USD conversion, and zero-filling processes as the total fees component. This ensures both metrics use consistent time boundaries and currency conversion methods.
- **Key fields**: Aggregated `revenue` amounts in USD, daily `timestamp` boundaries, `chain_id` identifiers

### Final aggregation
- **Combining components**: Joins the total fees and total revenue metrics on timestamp and chain dimensions, ensuring both metrics cover the same time periods and chains
- **Currency conversion**: Both components use end-of-day token prices for USD conversion, applied after decimal correction but before daily aggregation
- **Time aggregation**: All events are truncated to daily boundaries using the event's block timestamp, with aggregation occurring at the day-chain level
- **Final calculation**: Supply-side fees equals total fees minus total revenue for each day and chain combination, representing the portion of trading fees that flows to liquidity providers and other supply-side participants rather than being retained as protocol revenue

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

Portion of fees distributed to service providers or supply-side participants.

APX V2APX

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown