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

## 1. Overview

Weekly Active Users (WAU) for Ramses measures the distinct number of users who executed trades on the Ramses DEX protocol within rolling 7-day windows. This metric provides insight into user engagement and platform activity by tracking unique traders across both Ramses V1 (LegacyPair) and V2 (Pool) products. The calculation uses HyperLogLog data structures for efficient distinct user counting and provides breakdowns across multiple dimensions including chain, product type, and user classification.

## 2. Data sources

The calculation relies on several key data sources:
- **Ramses protocol events**: Parsed `Swap` events from both Ramses V1 LegacyPair contracts and Ramses V2 Pool contracts deployed on Arbitrum
- **Arbitrum transaction records**: Blockchain transaction data providing user addresses and transaction metadata  
- **Table modification timestamps**: System metadata for incremental processing and data freshness tracking
- **Protocol metadata**: Launch date information (March 14, 2023) and product classification data

## 3. Step-by-step calculation

### Component A: Trade fact extraction
- **Purpose**: Identifies all trading activity on Ramses protocol from raw blockchain events
- **Logic**: Extracts `Swap` events from two distinct Ramses contract types on Arbitrum. For V1 LegacyPair contracts, calculates token amount changes by subtracting `amount0Out` from `amount0In` and `amount1Out` from `amount1In`. For V2 Pool contracts, directly uses the `amount0` and `amount1` values. Joins swap events with Arbitrum transaction records to obtain the actual user address (`from_address`) performing the trade, as opposed to the contract address that emitted the event. Applies launch date filtering to exclude pre-launch data and incremental processing logic for efficiency.
- **Key fields**: `block_timestamp` for trade timing, `user_address` for trader identification, `product_id` distinguishing between 'legacypair' (V1) and 'concentratedliquiditypool' (V2), `chain` set to 'arbitrum', and token amount calculations

### Component B: Daily active user aggregation  
- **Purpose**: Converts individual trades into daily distinct user counts
- **Logic**: Aggregates trade facts by truncating `block_timestamp` to day boundaries and identifying distinct `user_address` values within each day. Classifies all users as 'Trader' user type since they performed trading activity. Applies business categorization with `market_sector_id` as 'exchanges' and `business_segment_id` as 'dex' to reflect the DEX nature of Ramses. Maintains chain and product-level dimensions for downstream analysis.
- **Key fields**: `timestamp` truncated to day, `user_dau` containing distinct user addresses, `user_type` standardized as 'Trader', product and chain identifiers

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily user sets into efficient data structures for distinct counting across time windows
- **Logic**: Transforms daily active user lists into HyperLogLog sketches using BigQuery's `hll_count.init()` function with precision parameter 15. This probabilistic data structure enables efficient storage and merging of large distinct user sets without storing individual user addresses. Groups by all dimensional attributes while creating HLL sketches from the daily user sets.
- **Key fields**: `hll` containing the HyperLogLog sketch, dimensional grouping fields preserved from daily aggregation

### Component D: Rolling window creation
- **Purpose**: Generates the 7-day rolling window structure needed for WAU calculation
- **Logic**: Creates a datespine covering all dates from the earliest data through yesterday, then expands each date into a 7-day window by generating timestamps from 6 days prior through the current date. This creates join keys that allow each target date to connect with 7 days of historical daily data. Uses `generate_timestamp_array()` functions to create both the base datespine and the rolling window expansions. Applies incremental processing logic to limit the date range when updating existing data.
- **Key fields**: `timestamp` for the target date, `joinday` for each day within the 7-day window

### Component E: WAU window assembly
- **Purpose**: Combines the rolling window structure with daily HLL data to create complete 7-day datasets
- **Logic**: Joins the rolling window structure with daily HLL sketches, matching each `joinday` in the window to corresponding daily data via `timestamp` equality. This creates a dataset where each target date has associated HLL sketches for up to 7 days of historical user activity. Maintains all dimensional attributes from the daily data for subsequent breakdown calculations.
- **Key fields**: Target `timestamp`, dimensional fields (`chain_id`, `user_type`, `product_id`), and associated `hll` sketches for the window period

### Component F: Dimensional breakdowns
- **Purpose**: Calculates WAU across four different dimensional views
- **Logic**: Creates four separate aggregation levels by grouping the windowed data differently. Project-level aggregation merges all HLL sketches regardless of other dimensions. Chain-level preserves `chain_id` while nullifying other dimensions. User-type-level preserves `user_type` classification. Product-level preserves `product_id` distinctions. Each aggregation uses `hll_count.merge_partial()` to combine HLL sketches across the grouped dimensions, then `hll_count.extract()` to get the final distinct count estimate.
- **Key fields**: `dimensions` indicating the breakdown level, preserved dimensional fields based on aggregation level, `user_wau` containing the final weekly active user count

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single result set using `UNION ALL`, creating a comprehensive view with different levels of granularity in the same table
- **Time aggregation**: Maintains daily grain with each record representing the WAU for the 7-day window ending on that date
- **Final calculation**: The metric value represents the distinct count of users who traded within any 7-day rolling window, calculated by merging HyperLogLog sketches and extracting the approximate distinct count
- **Schema standardization**: Applies the `finalize_metric_user_wau` macro to ensure consistent output schema, handle missing date filling with zeros, and apply any additional business logic for user WAU metrics

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

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

Ramses ExchangeRAM

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown