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 Trade count Methodology

## 1. Overview

Trade count measures the number of unique transactions that executed swaps on the Ramses decentralized exchange (DEX) protocol on Arbitrum. This metric tracks daily trading activity by counting distinct transaction hashes that contain swap events, providing insight into user engagement and protocol adoption. The calculation aggregates swap events from both Ramses v1 (Legacy Pairs) and v2 (Concentrated Liquidity Pools) into daily trade counts.

## 2. Data sources

The calculation uses the following raw blockchain data sources:
- **Swap events**: Parsed `LegacyPair_Swap_event` logs from Ramses v1 and `Pool_Swap_event` logs from Ramses v2 on Arbitrum
- **Factory events**: `Factory_PairCreated_event` logs from Ramses v1 and `Factory_PoolCreated_event` logs from Ramses v2 to identify trading pairs
- **Transaction records**: Arbitrum transaction data to obtain user addresses and transaction metadata
- **Token metadata**: Token registry data containing symbols and decimal places for token normalization

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract all swap events from both Ramses protocol versions
- **Logic**: Parse swap events from Ramses v1 `LegacyPair_Swap_event` and v2 `Pool_Swap_event` logs on Arbitrum. Filter events to include only those occurring on or after the protocol launch date of March 14, 2023. For v1 swaps, calculate token amount changes using `amount0In - amount0Out` and `amount1In - amount1Out` logic. For v2 swaps, use the direct `amount0` and `amount1` values. Join with Arbitrum transaction data to obtain the transaction sender's address as the user address
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, pool/pair `address`, `sender` (contract user), transaction `from_address` (actual user), token amounts, and version/product identifiers

### Component B: Trading pair identification
- **Purpose**: Map pool/pair addresses to their underlying token pairs and metadata
- **Logic**: Extract trading pair creation events from Ramses factory contracts. Use `Factory_PairCreated_event` logs from v1 to identify Legacy Pairs and `Factory_PoolCreated_event` logs from v2 to identify Concentrated Liquidity Pools. Extract the token addresses (token0 and token1) for each trading pair. Join with token metadata to obtain decimal places and symbols for proper token amount normalization and pair naming
- **Key fields**: Pool/pair `address`, `token0_address`, `token1_address`, `decimals` for both tokens, and constructed `account_name` using token symbols

### Component C: Trade processing and normalization
- **Purpose**: Combine raw trades with trading pair metadata and normalize token amounts
- **Logic**: Join swap events with trading pair data using the pool/pair address and chain. Normalize token amounts by dividing the absolute values by 10 raised to the power of each token's decimal places. Truncate timestamps to daily boundaries using day-level granularity. Filter trades to include only those from the protocol launch date onward
- **Key fields**: Daily `timestamp`, `transaction_hash`, `log_index`, `chain`, `product_id`, user addresses, token addresses, and normalized `token0_amount` and `token1_amount`

### Final aggregation
- **Combining components**: Group processed trades by timestamp (day), chain, market sector ('exchanges'), business segment ('dex'), and product type (Legacy Pair or Concentrated Liquidity Pool)
- **Trade counting**: Count distinct transaction hashes within each group to determine the number of unique trading transactions per day. This ensures that transactions containing multiple swap events are counted only once
- **Metric finalization**: Apply the standard metric finalization process including zero-filling for days with no trades and chain availability filtering to ensure consistent time series data
- **Final calculation**: The trade count represents the total number of distinct transaction hashes that executed swaps on Ramses protocol for each day, segmented by product type

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Number of trades executed on a decentralized exchange.

Ramses ExchangeRAM

Trade count

Trade count

Competitive landscape

Chain breakdown