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 (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who traded on the Ramses decentralized exchange during any 30-day rolling window. This metric uses HyperLogLog probabilistic data structures to efficiently count distinct users over time, providing insights into user engagement and platform adoption. The calculation identifies unique trader addresses from swap transactions and aggregates them using rolling 30-day windows to produce daily MAU values with multiple dimensional breakdowns.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Blockchain event logs**: Parsed `Swap` events from Ramses V1 LegacyPair contracts and Ramses V2 Pool contracts deployed on Arbitrum
- **Transaction data**: Arbitrum blockchain transaction records containing user addresses and transaction metadata
- **Smart contract events**: Ramses protocol swap events including token amounts, sender addresses, and transaction identifiers

## 3. Step-by-step calculation

### Component A: Trade data extraction
- **Purpose**: Extract all swap transactions from Ramses V1 and V2 contracts on Arbitrum
- **Logic**: Parse `Swap` events from both Ramses V1 LegacyPair contracts and V2 Pool contracts. For V1 events, calculate token amounts using the difference between `amount0In` minus `amount0Out` and `amount1In` minus `amount1Out`. For V2 events, use the direct `amount0` and `amount1` values. Join swap events with Arbitrum transaction records to extract the `from_address` field as the user address. Filter data to include only transactions from the protocol launch date of March 14, 2023 onwards. Classify V1 trades under 'legacypair' product ID and V2 trades under 'concentratedliquiditypool' product ID.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for unique identification, `from_address` as the trader address, token amounts for trade validation, and `address` as the contract address

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily distinct active users from trade data
- **Logic**: Group trade data by day using timestamp truncation to daily granularity. Extract distinct `user_address` values for each day, creating a daily active user count. Classify all users as 'Trader' type and categorize under 'exchanges' market sector and 'dex' business segment. Maintain dimensional attributes including chain, product ID, and user type for downstream aggregation.
- **Key fields**: `timestamp` truncated to day, `user_address` as the unique user identifier, `chain` set to 'arbitrum', `user_type` set to 'Trader', and `product_id` from the underlying trades

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user counts into probabilistic data structures for efficient aggregation
- **Logic**: Initialize HyperLogLog sketches for each day's unique user count using 15-bit precision. Group by timestamp, timestamp grain, chain, user type, and product ID to maintain dimensional breakdown capability. The HLL data structure enables efficient merging of user counts across time windows without double-counting users who appear on multiple days.
- **Key fields**: `hll` sketch containing the probabilistic representation of daily distinct users, dimensional grouping fields for downstream aggregation

### Component D: Rolling window creation
- **Purpose**: Generate 30-day rolling windows for MAU calculation
- **Logic**: Create a datespine covering all days from the minimum trade date to yesterday. For each day in the datespine, generate a 30-day window by creating timestamps for the current day and the previous 29 days using timestamp array generation. Join the window days with the daily HLL data to collect all user activity within each 30-day period.
- **Key fields**: `timestamp` for the window end date, `joinday` for each day within the 30-day window, HLL sketches from matching days

### Component E: Dimensional MAU aggregation
- **Purpose**: Calculate MAU across different dimensional breakdowns
- **Logic**: For each 30-day window, merge all HLL sketches within the window using HLL merge operations, then extract the final distinct count. Create four separate dimensional views: project-level (overall MAU), chain-level (by blockchain), user-type-level (by user classification), and product-level (by V1/V2 version). For each breakdown, group by the relevant dimensions and set unused dimensions to null using safe casting.
- **Key fields**: `user_mau` as the final distinct user count, `dimensions` indicating the breakdown type, dimensional fields (`chain_id`, `product_id`, `user_type`) with appropriate null values

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project, chain, user type, product) into a single result set with consistent schema structure
- **Time aggregation**: Use daily timestamps as the primary time dimension, with each day representing the end of a 30-day rolling window
- **Final calculation**: Extract distinct user counts from merged HLL sketches using HLL count extraction, providing probabilistic estimates of unique monthly active users
- **Finalization**: Apply the finalize metric macro with zero-filling strategy to ensure complete time series data with no gaps in the daily MAU values

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

Unique revenue-generating users over a rolling 30-day window.

Ramses ExchangeRAM

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown