website

twitter

Infrastructure

GMGN

# GMGN Average revenue per user (ARPU) Methodology

## 1. Overview

Average revenue per user (ARPU) measures the daily revenue generated per active user for GMGN, a cross-chain trading bot platform. This metric reflects the protocol's ability to monetize its user base through trading fees across various blockchain environments. Revenue is calculated from trading fees collected on both EVM-compatible chains and Solana, while the active user component is derived from distinct daily participants identified on-chain.

## 2. Data sources

- **Revenue**: Derived from the Revenue metric
- **Active users (daily)**: Derived from the Active users (daily) metric
- **Blockchain events**: Native token inflows (call inflows) to designated fee accounts and native Solana `Transfer` instructions, covering Solana, Ethereum, BSC, Base, and Monad
- **External data**: End-of-day price feeds for native assets (ETH, SOL, BNB, MON)

## 3. Step-by-step calculation

### Component A: EVM fee collection

- **Purpose**: Capture trading fees generated from activity on EVM-compatible blockchains.
- **Logic**: Native token inflows are monitored for designated GMGN fee accounts. These inflows are filtered to include only `call_inflow` categories with a value greater than zero. Data is captured across Ethereum, BSC, Base, and Monad, with starting dates specific to the platform's deployment on each respective chain.
- **Key fields**: `account_address` (fee recipient), `value` (fee amount), `block_timestamp`.

### Component B: Solana fee collection

- **Purpose**: Capture trading fees generated from activity on the Solana program.
- **Logic**: Native `Transfer` instructions to a set of identified GMGN fee accounts are parsed. Transactions where the transaction signer is one of the fee accounts themselves are excluded to prevent the inclusion of internal treasury movements. All valid SOL inflows to these accounts are classified as trading fees.
- **Key fields**: `to_address` (fee recipient accounts), `transaction_signer` (user), `amount` (fee quantity).

### Component C: Active user identification

- **Purpose**: Determine the number of unique daily users interacting with the platform.
- **Logic**: Active users are identified as the daily distinct count of transaction signers captured within the Solana fee dataset. Due to limitations in identifying unique end-users versus router programs on certain EVM chains, the user count is specifically derived from Solana transaction signers to ensure data quality.
- **Key fields**: `signer` (transaction-level user identifier), `block_timestamp`.

### Component D: USD conversion and revenue aggregation

- **Purpose**: Normalize fee data into a consistent currency for comparison and aggregation.
- **Logic**: Fee amounts from all supported chains are normalized by their respective decimal precision. These values are multiplied by end-of-day price feeds for the native assets used to pay the fees. Daily revenue is then aggregated across all chains using UTC day boundaries.
- **Key fields**: `amount`, `token_address`, `price_usd`.

### Component E: ARPU calculation

- **Purpose**: Calculate the final average revenue generated per individual user.
- **Logic**: Total daily revenue is divided by the number of active users (daily). The metric is calculated on a daily basis, and in the event of missing data for either component, the value is filled with zero to maintain a continuous time series.
- **Key fields**: `revenue`, `user_dau`.

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

GMGN

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape