# Constant Product Revenue Methodology

## 1. Overview

Revenue measures the portion of trading fees retained by the protocol and the value of incentives provided to voters. For Constant Product, revenue is generated through a protocol take rate (fee split) applied to swap fees and through voting bribes distributed to incentivized participants. This metric reflects the protocol's earnings before the distribution of incentives or operating expenses.

## 2. Data sources

- **Blockchain events**: `Swap` events from `Pair` contracts, `PairCreated` events from `Factory` contracts, `SetPairFee`, `SetFee`, and `SetPairFeeSplit` events from `PairFactory` contracts, and `VotesIncentivized` events from `FeeDistributor` contracts, covering Linea
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Constant Product trading volume calculation

- **Purpose**: Calculate the base trading volume for each liquidity pool to determine the surface area for fee collection.
- **Logic**: `Swap` events are parsed from `Pair` contracts to identify the change in token balances for each trade. Volume is determined by taking the lesser USD value between the two assets involved in the swap to mitigate the impact of price manipulation or low-liquidity price spikes. Daily volumes are aggregated by contract address and chain.
- **Key fields**: `token0_amount`, `token1_amount`, `account_address` (pool address)

### Component B: Protocol take rate and fee tier configuration

- **Purpose**: Establish the specific fee percentages and protocol shares applied to the trading volume.
- **Logic**: Fee tiers are extracted from `SetPairFee` and `SetFee` events from `PairFactory` contracts, with a default value of 0.3% applied if no event-based configuration is present. The protocol take rate is extracted from `SetPairFeeSplit` events. These configurations are tracked using block-level ordering to ensure the correct rates are applied to swaps occurring at any specific timestamp.
- **Key fields**: `fee_tier` (swap fee), `fee_split` (protocol take rate)

### Component C: Voting bribe revenue capture

- **Purpose**: Capture revenue generated through incentivized voting mechanisms.
- **Logic**: `VotesIncentivized` events are parsed from `FeeDistributor` contracts. The value of reward assets distributed as bribes is identified. For specific assets like xREX, the value is mapped to the underlying REX asset to ensure accurate pricing.
- **Key fields**: `reward` (asset address), `amount` (quantity)

### Component D: Final aggregation and USD conversion

- **Purpose**: Combine all revenue components and normalize them into a single USD-denominated metric.
- **Logic**: Protocol revenue from swaps is calculated by multiplying trading volume by the active fee tier and the protocol fee split. This is summed with the value of voting bribes. All amounts are normalized by decimal precision and converted to USD using end-of-day price feeds. Daily totals are aggregated using UTC day boundaries.
- **Key fields**: `revenue` (final USD value)

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

Constant Product

Archived

Revenue

Revenue