website

twitter

Infrastructure

GMGN

# GMGN Revenue Methodology

## 1. Overview

Revenue measures the portion of trading fees that is retained by GMGN. As a trading bot platform, GMGN collects fees from users for executing swaps and managing positions across multiple networks. Because the protocol does not distribute a portion of these fees to external supply-side participants like liquidity providers or lenders, revenue is equivalent to the total fees collected by the project. Revenue is calculated by aggregating native asset inflows to designated fee recipient accounts and converting those values to USD.

## 2. Data sources

- **Blockchain events**: Native asset transfers and `call_inflow` records to designated fee accounts, covering Solana, Ethereum, BSC, Base, and 1 other chain
- **External data**: End-of-day price feeds for native assets including ETH, SOL, and BNB

## 3. Step-by-step calculation

### Component A: EVM fee extraction

- **Purpose**: Capture trading fees collected across supported EVM-compatible networks
- **Logic**: Native token inflows are identified from account activity records for designated GMGN fee recipient accounts on Ethereum, BSC, Base, and Monad. Only transactions categorized as `call_inflow` with a positive value are included. Amounts are normalized by the decimal precision of the respective native assets (e.g., 18 decimals for ETH and BNB).
- **Key fields**: `block_timestamp`, `account_address`, `value`, `token_address`

### Component B: Solana fee extraction

- **Purpose**: Capture trading fees collected on the Solana network
- **Logic**: Native SOL transfers are parsed from the Solana blockchain. Transfers are filtered where the recipient account matches a known list of GMGN fee accounts. Transactions where the signer is also a fee account are excluded to prevent the inclusion of internal protocol transfers. Amounts are normalized by the 9-decimal precision of SOL.
- **Key fields**: `block_timestamp`, `to_address`, `amount`, `transaction_signer`

### Component C: USD conversion and revenue mapping

- **Purpose**: Normalize fee data into USD and map it to the revenue metric
- **Logic**: Fees from all chains are aggregated at a daily granularity. These amounts are multiplied by the end-of-day price feeds for the respective native assets. Revenue is set equal to 100% of the calculated fees, reflecting the protocol's current take rate where all collected user fees are retained by the project.
- **Key fields**: `timestamp`, `fees`, `price_usd`

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

GMGN

Revenue

Revenue

Competitive landscape

Chain breakdown