website

twitter

discord

Exchanges (DEX)

Etherex

# Etherex Revenue Methodology

## 1. Overview

Etherex revenue represents the total protocol revenue earned by Etherex decentralized exchange across its v2 and v3 implementations on the Linea blockchain. The metric combines two revenue streams: trading fee revenue from swap transactions and voting bribe revenue from governance incentives. Trading fee revenue is calculated by multiplying daily trading volumes by applicable fee tiers and protocol fee splits, while voting bribe revenue captures direct incentive payments made to influence governance votes.

## 2. Data sources

The calculation uses multiple blockchain data sources and external feeds:
- **Swap events**: Parsed Linea blockchain `Pair_Swap` events from Etherex v2 pairs and `Pool_Swap` events from Etherex v3 pools
- **Transaction records**: Linea blockchain transaction data to identify swap initiators and context
- **Governance events**: Parsed Linea blockchain `VotesIncentivized` events from fee distributor contracts
- **Pool configuration events**: Parsed Linea blockchain events tracking pool and pair creation, fee tier changes, and protocol fee split adjustments
- **Token metadata**: Token contract information including decimal places and symbols for normalization
- **Price feeds**: End-of-day token price feeds for USD conversion across all tokens involved in swaps and bribes

## 3. Step-by-step calculation

### Component A: Trading fee revenue

- **Purpose**: Calculate protocol revenue from trading fees charged on swap transactions
- **Logic**: Extract swap events from both Etherex v2 pairs and v3 pools on Linea blockchain. For v2 swaps, calculate token amounts as the difference between input amounts and output amounts from the `Pair_Swap` event fields. For v3 swaps, use direct `amount0` and `amount1` values from `Pool_Swap` events. Join swap events with transaction records to identify the user addresses initiating swaps. Combine swap data with trading pair metadata to determine the two tokens being swapped and their decimal places. Apply pool-specific fee configurations by joining with dimension tables that track fee tiers and protocol fee splits over time using temporal ordering based on block numbers and log indices
- **Key fields**: `token0_amount` and `token1_amount` representing the absolute values of tokens exchanged, `fee_tier` indicating the swap fee percentage, `fee_split` representing the protocol's share of fees, `account_address` identifying the trading pair contract

### Component B: Trading volume USD conversion

- **Purpose**: Convert raw trading volumes to standardized USD values for revenue calculation
- **Logic**: Take the processed trading volumes with corrected decimals from component A and join with end-of-day price feeds for both tokens in each swap. Apply anti-manipulation logic by calculating USD values for both `token0_amount` and `token1_amount` separately, then taking the minimum of the two USD values to prevent inflated volumes from price manipulation or oracle attacks. Aggregate these minimum USD trading volumes daily by chain, product, version, fee tier, and fee split configuration
- **Key fields**: `trading_volume` representing the daily USD trading volume, `timestamp` truncated to day boundaries, `chain` and `product_id` for grouping

### Component C: Voting bribe revenue

- **Purpose**: Capture protocol revenue from governance incentive payments
- **Logic**: Extract `VotesIncentivized` events from fee distributor contracts on Linea blockchain, which represent payments made to incentivize specific governance votes. Apply token address normalization by converting xREX token addresses to REX addresses for consistent pricing. Correct raw amounts using token decimal places and convert to USD using end-of-day price feeds. Aggregate these bribe amounts daily by chain and product
- **Key fields**: `amount` representing the bribe payment amount, `token_address` identifying the bribe token, `address` indicating the fee distributor contract

### Final aggregation

- **Combining components**: Union the trading fee revenue and voting bribe revenue streams into a single dataset, ensuring both have consistent field structures including timestamp, chain, product, and revenue amount fields
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds matched by timestamp, chain, and token address. The USD conversion applies decimal correction by dividing raw token amounts by 10 raised to the power of the token's decimal places
- **Time aggregation**: All events are aggregated to daily boundaries using timestamp truncation, with revenue amounts summed within each day
- **Final calculation**: Trading fee revenue equals daily trading volume in USD multiplied by the fee tier percentage multiplied by the protocol fee split percentage. Voting bribe revenue equals the USD value of incentive payments. Total revenue is the sum of these two components, with zero-filling applied for dates with no activity to ensure continuous time series data

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

EtherexREX

Archived

Revenue

Revenue

Competitive landscape