# Constant Product Revenue Methodology

## 1. Overview

Revenue measures the portion of trading fees that Constant Product retains, as determined by the protocol's take rate. These earnings represent the protocol's share of economic activity before accounting for operating expenses or token incentives. For Shadow Constant Product, revenue is generated through a specific fee split applied to the total fees collected from liquidity pools.

## 2. Data sources

- **Blockchain events**: `Swap` and `setFeeSplit` function calls from `Pair` contracts, `PairCreated` events from `Factory` contracts, and `SetPairFeeSplit`, `SetPairFee`, and `SetFee` events from `PairFactory` contracts, covering Sonic
- **External data**: End-of-day price feeds for assets traded within the protocol

## 3. Step-by-step calculation

### Component A: Trading volume extraction

- **Purpose**: Identifies and quantifies all trading activity occurring within Constant Product pools.
- **Logic**: `Swap` events are parsed from `Pair` contracts to identify token exchanges. The gross amount for each trade is determined by calculating the absolute change in token balances (the difference between incoming and outgoing amounts) for both assets in the pair. To prevent skewing from price manipulation or extreme volatility, the lower USD value between the two traded assets is utilized as the canonical trading volume for each transaction.
- **Key fields**: `in_amount0In`, `in_amount0Out`, `in_amount1In`, `in_amount1Out`, `account_address` (pool identification).

### Component B: Pool parameter tracking

- **Purpose**: Monitors the specific fee tiers and protocol take rates (fee splits) active for each liquidity pool at any given time.
- **Logic**: Dynamic pool settings are captured by tracking configuration events and function calls. Fee tiers (the total percentage charged to traders) are extracted from `SetPairFee` and `SetFee` events emitted by `PairFactory` contracts, with a default value of 0.3% applied if no specific setting is detected. The protocol's take rate is identified by parsing `SetPairFeeSplit` events from `PairFactory` contracts and `setFeeSplit` function calls directed at `Pair` contracts. These values are mapped to pools using a version-controlled timeline to ensure every trade is associated with the parameters active at the moment of execution.
- **Key fields**: `in_fee` (fee tier), `in__feeSplit` (protocol share), `in_pair` (pool address).

### Component C: Revenue normalization and USD conversion

- **Purpose**: Converts raw on-chain data into standardized USD-denominated revenue metrics.
- **Logic**: Revenue is calculated for each trade by multiplying the trading volume by the applicable fee tier and the protocol fee split. Asset amounts are normalized by decimal precision. Daily revenue is aggregated by multiplying these normalized values by end-of-day price feeds. The final metric is summed by chain and product using UTC day boundaries.
- **Key fields**: `trading_volume`, `fee_tier`, `fee_split`, `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.