# Concentrated Liquidity Revenue Methodology

## 1. Overview

Revenue measures the portion of fees that is retained by the project, as determined by its specific take rate, alongside additional income generated from voting incentives. For Concentrated Liquidity, revenue is derived from a protocol-level fee split applied to trading activities and the collection of voting bribes. This metric represents the project's earnings before the distribution of supply-side fees to liquidity providers and other participants.

## 2. Data sources

- **Blockchain events**: `PoolCreated` events from `Factory` contracts, `FeeAdjustment` events from `PoolFactory` contracts, `Swap` and `SetFeeProtocol` events from `Pool` contracts, and `VotesIncentivized` events from `FeeDistributor` contracts, covering Sonic
- **External data**: End-of-day price feeds for asset metadata and valuation

## 3. Step-by-step calculation

### Component A: Protocol trading revenue calculation

- **Purpose**: To determine the protocol's share of fees generated from swaps within Concentrated Liquidity pools.
- **Logic**: `Swap` events are parsed to extract the volume of assets exchanged in each transaction. The applicable fee tier for each pool is tracked via `PoolCreated` and `FeeAdjustment` events, while the protocol's take rate is identified through `PoolCreated` and `SetFeeProtocol` events. Trading volume is calculated by taking the lesser USD value of the two assets in a swap to mitigate price manipulation. Protocol revenue is then calculated as the product of the trading volume, the pool's fee tier, and the protocol's fee split percentage.
- **Key fields**: `token0_amount`, `token1_amount`, `fee_tier`, `fee_split`

### Component B: Voting bribe revenue extraction

- **Purpose**: To capture revenue generated from incentives paid to voters within the governance ecosystem.
- **Logic**: `VotesIncentivized` events are parsed from `FeeDistributor` contracts to identify the assets and amounts distributed as bribes. These incentives are treated as a direct revenue stream for the project's ecosystem.
- **Key fields**: `amount`, `token_address`, `reward`

### Component C: USD normalization and aggregation

- **Purpose**: To standardize all revenue components into a single currency for cross-chain and cross-asset comparison.
- **Logic**: All extracted amounts are normalized by their respective decimal precision. Asset values are converted to USD using end-of-day price feeds. Trading-based revenue and voting bribe revenue are summed to produce the final revenue metric. Values are aggregated at a daily granularity using UTC day boundaries.
- **Key fields**: `block_timestamp`, `revenue`, `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.