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

ApeSwap is a non-custodial exchange protocol built originally on BNB Chain. ApeSwap was founded by an anonymous team and launched in 2021.

BANANA tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

governance

github

twitter

discord

etherscan

website

Exchanges (DEX)

ApeSwap

# ApeSwap Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for ApeSwap measures the distinct number of users who performed at least one trade on the ApeSwap decentralized exchange within a rolling 30-day window. This metric answers how many unique traders are actively using ApeSwap across multiple blockchain networks on a monthly basis. The calculation uses a rolling window approach where each day's MAU represents the count of distinct users who traded in the current day plus the previous 29 days, providing a smooth trend indicator of user engagement.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Blockchain event logs**: Parsed `ApePair_Swap_event` logs from ApeSwap DEX contracts across Ethereum, Polygon, Arbitrum, and BSC networks
- **Transaction data**: Blockchain transaction records from Ethereum, Polygon, Arbitrum, and BSC containing transaction metadata and user addresses
- **Chain availability data**: Configuration data that defines which blockchain networks are available and supported for each time period

## 3. Step-by-step calculation

### Component A: Trade extraction
- **Purpose**: Extract all trading activity from ApeSwap DEX contracts across supported blockchain networks
- **Logic**: Process `ApePair_Swap_event` logs from ApeSwap v1 contracts on Ethereum, Polygon, Arbitrum, and BSC. Join swap events with corresponding transaction records to obtain complete trade information including user addresses and transaction context. Filter for trades occurring after February 10, 2021. Calculate token amounts by taking the difference between input and output amounts for both tokens in each trading pair. Standardize all trades with consistent business metadata including business line as 'Exchange AMM', market sector as 'exchanges', and business segment as 'dex'
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for unique identification, `user_address` from transaction records for user identification, `token0_amount` and `token1_amount` calculated as amount differences, `chain` identifier for network classification

### Component B: Daily active user calculation  
- **Purpose**: Aggregate trading activity to identify distinct active users on a daily basis
- **Logic**: Take the extracted trade data and truncate all block timestamps to daily granularity. Extract distinct user addresses for each day and classify all users as 'Trader' type since they performed trading activities. Maintain dimensional attributes including chain, user type, and product identifiers for downstream aggregation. Apply chain availability filters to ensure data quality and exclude periods when specific chains were not properly supported
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing distinct user addresses, `chain` for network identification, `user_type` standardized as 'Trader', `product_id` for product-level breakdowns

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user sets into HyperLogLog sketches for memory-efficient distinct counting across time windows
- **Logic**: Initialize HyperLogLog sketches from the daily distinct user data with precision parameter 15. Group by timestamp, timestamp grain, chain, user type, and product to maintain dimensional structure. HyperLogLog sketches allow efficient merging across time periods while maintaining approximate distinct counts without storing full user lists
- **Key fields**: `hll` sketches initialized from daily user sets, dimensional grouping fields preserved for aggregation logic

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for each date to calculate monthly active users
- **Logic**: Generate a complete datespine covering all dates from the first recorded trade to yesterday. For each date in the datespine, create a 30-day lookback window by generating an array of dates from 29 days prior to the current date (inclusive). This creates joinday combinations that map each target date to its corresponding 30-day window of source dates. Join these window combinations with the HyperLogLog sketches to gather all daily user data within each 30-day period
- **Key fields**: `timestamp` for target dates, `joinday` for source dates within the window, dimensional attributes maintained through joins

### Component E: Dimensional aggregation
- **Purpose**: Create MAU breakdowns across different analytical dimensions
- **Logic**: Group the windowed HyperLogLog data by different dimensional combinations. Create four separate breakdowns: project-level (all dimensions null), chain-level (grouped by chain), user type-level (grouped by user type), and product-level (grouped by product). For each breakdown, merge all HyperLogLog sketches within the same dimensional group and 30-day window. Extract the final distinct count from the merged HyperLogLog sketches to get the MAU value for that dimension and time period
- **Key fields**: `dimensions` indicating the breakdown type, dimensional fields with null values for unused dimensions, `user_mau` containing the extracted distinct user count from merged HLL sketches

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set containing project-level, chain-level, user type-level, and product-level MAU calculations
- **Standardization**: Apply the finalize metric macro to standardize the output schema, handle missing dates with zero-fill strategy, and ensure consistent formatting across all metrics
- **Time boundaries**: Use monthly partitioning with incremental processing that includes a safety margin for late-arriving data and processes complete 30-day windows
- **Final calculation**: Each MAU value represents the approximate distinct count of users who performed at least one trade within the trailing 30-day period ending on the given date, calculated using merged HyperLogLog sketches for memory efficiency

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

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

ApeSwapABOND

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown