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

Ramses is a non-custodial exchange protocol built on Arbitrum. Ramses was founded by pseudonyms Dog and North in 2023.

RAM tokenholders own and govern the protocol. They vote which pools they wish to earn trading fees from (revenue).

github

twitter

discord

etherscan

website

Exchanges (DEX)

Ramses Exchange

# Ramses Exchange Revenue Methodology

## 1. Overview

Ramses revenue measures the daily USD value of fees earned by the Ramses decentralized exchange protocol on Arbitrum. The metric combines revenue from both Ramses v1 (legacy pairs) and v2 (concentrated liquidity pools) products. For v1, all collected fees are treated as protocol revenue. For v2, the protocol retains 80% of collected fees as revenue, with the remaining 20% distributed to liquidity providers. This metric answers how much daily revenue the Ramses protocol generates from trading activity across its different product offerings.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Arbitrum blockchain event logs**: Parsed `Claim` events from Ramses v1 `LegacyPair` contracts that capture fee collections with token amounts and fee collector addresses
- **Arbitrum blockchain event logs**: Parsed `FeesCollected` events from Ramses v2 `FeeCollector` contracts containing fee distribution amounts and treasury amounts for both tokens in trading pairs
- **Arbitrum blockchain event logs**: Parsed `PairCreated` events from Ramses v1 Factory contracts that establish trading pair registries with token addresses
- **Arbitrum blockchain event logs**: Parsed `PoolCreated` events from Ramses v2 Factory contracts that create concentrated liquidity pools with token pair information
- **End-of-day token price feeds**: Daily USD price data for tokens traded on Ramses pairs and pools
- **Token metadata**: Token decimal precision and symbol information for proper amount calculations and display names

## 3. Step-by-step calculation

### Component A: V1 fee collection events
- **Purpose**: Captures fee claims from Ramses v1 legacy trading pairs
- **Logic**: Extracts all `Claim` events from `LegacyPair` contracts on Arbitrum. Each event contains the trading pair contract address, fee collector address (`sender`), and raw token amounts for both tokens in the pair (`amount0` and `amount1`). Events are normalized with product identifier as "legacypair" and version as "v1"
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for uniqueness, `address` as the trading pair contract, `sender` as fee collector, `amount0` and `amount1` as raw fee amounts

### Component B: V2 fee collection events  
- **Purpose**: Captures fee collections from Ramses v2 concentrated liquidity pools
- **Logic**: Extracts all `FeesCollected` events from `FeeCollector` contracts on Arbitrum. For each event, combines fee distribution amounts (`feeDistAmount0/1`) and treasury amounts (`treasuryAmount0/1`) to calculate total fees collected for both tokens. The pool address is captured from the event parameters, and the fee collector contract address provides the collection source. Events are normalized with product identifier as "concentratedliquiditypool" and version as "v2"
- **Key fields**: `block_timestamp` for timing, `pool` as the trading pool address, fee collector contract as `address`, combined `feeDistAmount` + `treasuryAmount` for total fee amounts per token

### Component C: Trading pair registry
- **Purpose**: Provides essential metadata for all Ramses trading pairs and pools
- **Logic**: Combines pair creation events from both versions to build a comprehensive registry. For v1, extracts `PairCreated` events from Factory contracts to get legacy pair addresses and token pairs. For v2, extracts `PoolCreated` events to get concentrated liquidity pool addresses and token pairs. Joins with token metadata to obtain decimal precision and symbols for both tokens in each pair. Creates display names by concatenating token symbols with hyphens
- **Key fields**: Trading pair/pool `account_address`, `token0_address` and `token1_address`, `token0_decimals` and `token1_decimals` for amount correction, `account_name` for display

### Component D: Fee processing and USD conversion
- **Purpose**: Processes raw fee amounts and converts to standardized USD values
- **Logic**: Combines v1 and v2 fee events through union operation. Truncates timestamps to daily boundaries for aggregation. Joins with trading pair registry to obtain token addresses and decimal information. Corrects raw token amounts by dividing by 10 raised to the token's decimal precision to get actual token quantities. Joins with end-of-day price feeds for both tokens using timestamp, chain, and token address matching. Multiplies corrected token amounts by USD prices and sums the values to get total daily fees in USD for each trading pair
- **Key fields**: Daily `timestamp`, `chain` (Arbitrum), `product_id` (legacypair or concentratedliquiditypool), `version` (v1 or v2), trading pair `account_address`, calculated `fees` in USD

### Final aggregation
- **Combining components**: Uses the processed fee data from Component D, which already combines v1 and v2 sources and converts to USD
- **Protocol revenue calculation**: Applies version-specific revenue rules - for v1 pairs, treats all fees as protocol revenue (100% share), for v2 pools, multiplies fees by 0.8 to reflect the protocol's 80% fee share while 20% goes to liquidity providers
- **Time aggregation**: Data is aggregated at daily level with timestamps truncated to day boundaries
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds matched by date, chain, and token address
- **Final calculation**: Revenue equals fees multiplied by protocol fee share (100% for v1, 80% for v2), summed across all trading pairs and aggregated by day, chain, market sector (exchanges), business segment (dex), and product type

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

Ramses ExchangeRAM

Revenue

Revenue

Competitive landscape

Chain breakdown