Liquidity providers deposit funds into Aerodrome and stake their LP tokens to receive AERO tokens in proportion to their share of the votes (token incentives).

Aerodrome is a non-custodial exchange protocol built on Base. Aerodrome was launched by the Velodrome team in 2023.

AERO tokenholders own and govern the protocol. They vote which pools they wish to earn trading fees from (revenue), while the pools' unstaked liquidity providers earn the remainder of the trading fees (supply-side fees).

github

twitter

discord

etherscan

website

Exchanges (DEX)

Aerodrome

# Aerodrome Revenue Methodology

## 1. Overview

Revenue measures the portion of fees and incentives that are retained by the protocol and distributed to veAERO holders. For Aerodrome, this metric is composed of trading fees collected from liquidity pools and voting incentives paid by third-party protocols. These revenue streams are generated across V1, V2, Slipstream, and Ignition products. This metric is utilized to evaluate the economic viability and the strength of the protocol's incentive flywheel.

## 2. Data sources

- **Blockchain events**: `Claim` events from `Pool` contracts, `CollectFees` events from `CLPool` contracts, `NotifyReward` events from `BribeVotingReward` and `CLBribeVotingReward` contracts, `GaugeCreated` events from `Voter` contracts, and `IgnitionEvent` events from `IgnitionRegistry` contracts, covering Base and Arc
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Trading fee collection

- **Purpose**: Capture trading fees collected from V1, V2, and Slipstream pools
- **Logic**: `Claim` events from `Pool` contracts (for V1 and V2) and `CollectFees` events from `CLPool` contracts (for Slipstream) are parsed to extract the collected fee amounts for both assets in a trading pair. These fee events are filtered to only include those where the fee collector address matches a registered liquidity incentive account. These incentive accounts are identified as the gauge addresses emitted in `GaugeCreated` events from `Voter` contracts. The extracted fee amounts are normalized by decimal precision using asset metadata and converted to USD using end-of-day price feeds.
- **Key fields**: `token0_amount`, `token1_amount`, `fee_collector_address`, `account_address`

### Component B: Voting incentives tracking

- **Purpose**: Capture voting incentives (bribes) paid to voters
- **Logic**: `NotifyReward` events from `BribeVotingReward` (for V1) and `CLBribeVotingReward` (for Slipstream) contracts are parsed to extract the incentive asset address and amount. These events are filtered to ensure the emitting contract address matches a valid bribe voting reward address, which is identified from `GaugeCreated` events from `Voter` contracts associated with the respective gauge factories. The incentive amounts are normalized by decimal precision using asset metadata and converted to USD using end-of-day price feeds.
- **Key fields**: `token_address`, `amount`, `account_address`

### Component C: Ignition launchpad categorization and fallback pricing

- **Purpose**: Categorize Ignition launchpad incentives and apply fallback pricing for newly launched assets
- **Logic**: Voting incentives are matched against Ignition launchpad pools, which are identified via `IgnitionEvent` events from `IgnitionRegistry` contracts or manual overrides (such as the MEZO Ignition launch). If a match is found, the product is categorized as Ignition; otherwise, it is categorized as Voting Incentives. For Ignition incentives where an event-date price is unavailable, a fallback price is applied using a pre-computed time-weighted average price (TWAP) over the first 24 hours of trading, provided the first-day trading volume is greater than or equal to the total incentive value.
- **Key fields**: `incentive_address`, `product_id`, `first_price_usd`, `first_day_volume_usd`

### Component D: Aggregation and finalization

- **Purpose**: Combine all revenue streams and format the final metric
- **Logic**: The USD-denominated trading fees and voting incentives are summed on a daily basis. The aggregated values are grouped by timestamp, chain, and product. A finalization process is applied to ensure schema consistency, validate chain and project identifiers, and fill days with no activity with zeros.
- **Key fields**: `revenue`, `timestamp`, `chain_id`, `product_id`

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

AerodromeAERO

Revenue

Revenue

Competitive landscape

Chain breakdown