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 Active users (daily) Methodology

## 1. Overview

Daily active users (DAU) for Ramses measures the count of unique user addresses that executed at least one trade on the Ramses decentralized exchange protocol within a given day. This metric captures trading activity across both Ramses V1 (legacy pairs) and V2 (concentrated liquidity pools) deployed on Arbitrum. The calculation identifies distinct trader addresses per day to understand user engagement and protocol adoption.

## 2. Data sources

- **Ramses V1 swap events**: Parsed `Swap` events from Ramses V1 LegacyPair contracts on Arbitrum, containing trade execution data including token amounts and sender addresses
- **Ramses V2 swap events**: Parsed `Swap` events from Ramses V2 concentrated liquidity Pool contracts on Arbitrum, with concentrated liquidity-specific trade data
- **Arbitrum transaction data**: Arbitrum blockchain transaction records containing transaction metadata including sender addresses (`from_address`) needed to identify the actual users initiating trades

## 3. Step-by-step calculation

### Component A: Ramses V1 trade extraction
- **Purpose**: Extracts trade events from Ramses V1 legacy pair contracts
- **Logic**: Retrieves all `Swap` events from Ramses V1 LegacyPair contracts on Arbitrum since the launch date of March 14, 2023. For each swap, calculates the net token amount changes by subtracting amounts out from amounts in for both `token0` and `token1`. Joins with Arbitrum transaction data to identify the actual user address who initiated the transaction (the `from_address` field from transaction data rather than the contract-level sender)
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for joining with transaction data, `amount0In`/`amount0Out` and `amount1In`/`amount1Out` for token flow calculations, and `from_address` from transaction data as the actual user identifier

### Component B: Ramses V2 trade extraction  
- **Purpose**: Extracts trade events from Ramses V2 concentrated liquidity pools
- **Logic**: Retrieves all `Swap` events from Ramses V2 Pool contracts on Arbitrum since the launch date. For V2 pools, uses direct `amount0` and `amount1` values as the token amounts (no subtraction needed due to different event structure). Similarly joins with Arbitrum transaction data to resolve the actual user address initiating the trade
- **Key fields**: `block_timestamp`, `transaction_hash`, `amount0`/`amount1` for direct token amounts, and `from_address` from joined transaction data

### Component C: Trade data unification
- **Purpose**: Combines V1 and V2 trade data into a unified dataset
- **Logic**: Unions the V1 and V2 trade extractions, standardizing field names and adding protocol version identifiers. V1 trades are tagged with `product_id` as 'legacypair' and version 'v1', while V2 trades use 'concentratedliquiditypool' and version 'v2'. All records are classified as 'arbitrum' chain, 'Trader' user type, 'exchanges' market sector, and 'dex' business segment
- **Key fields**: `user_address` as the primary identifier for DAU counting, `block_timestamp` for daily aggregation, and classification fields for metric categorization

### Final aggregation
- **Combining components**: Uses the unified trade dataset from Component C as the single input
- **Time aggregation**: Truncates `block_timestamp` to daily boundaries using day-level timestamp truncation, creating a `timestamp` field representing each day
- **User counting**: Groups data by the daily timestamp and counts distinct `user_address` values per day
- **Final calculation**: The daily active user count is the number of unique `user_address` values that executed at least one trade (either V1 or V2) within each calendar day, with each unique address counted only once per day regardless of the number of trades they executed

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

Unique revenue-generating users over a fixed 24-hour window.

Ramses ExchangeRAM

Active users (daily)

Active users (daily)

Competitive landscape

Chain breakdown