Users are able to use the Orca protocol to transact with digital assets on a peer-to-peer or peer-to-protocol basis by trading against liquidity  pools, which are created and seeded by other users providing liquidity of a pair of tokens into such liquidity pools in exchange for a stake of the liquidity and trading fees generated by such pools.

Orca is a non-custodial automated market maker (AMM) protocol built on Solana. Orca was founded by Yutaro Mori and Grace Kwan and launched in 2021.

ORCA tokenholders govern the Orca protocol treasury, which receives a portion of the trading fees paid by users of the protocol.

website

governance

github

twitter

discord

etherscan

Exchanges (DEX)

Orca

Orca | Data Breakdown

# Orca Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of distinct users who executed trades on Orca DEX within any 7-day rolling window. This metric answers the business question of user engagement and platform usage over weekly time periods. The calculation uses HyperLogLog (HLL) approximation algorithms to efficiently count distinct users across rolling 7-day windows, providing dimensional breakdowns by project, chain, user type, and product ID.

## 2. Data sources

The methodology relies on the following raw data sources:
- **Solana DEX trade events**: Parsed trade transactions from Solana blockchain containing swap details, user addresses, and transaction metadata
- **Orca program instructions**: Specific program addresses identifying Orca protocol transactions (`whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc` for Whirlpools and `9W959DqEETiGZocYWCQPaJ6sBmUzgfxXfqGeTEdp3aQP` for Orca Token Swap V2)
- **Transaction signer data**: User wallet addresses that initiated trading transactions
- **Token metadata**: Base and quote token mint addresses for traded asset pairs
- **Pool and swap data**: Trading pool addresses and swap amounts for transaction classification

## 3. Step-by-step calculation

### Component A: Trade data extraction and filtering
- **Purpose**: Extract and classify Orca-specific trading activity from Solana DEX data
- **Logic**: Filter all Solana DEX trades to include only transactions where the outer or inner program matches Orca's specific program addresses. Extract key transaction details including the signer address (user), base and quote token mint addresses, trading pool address, and swap amounts. Classify trades by product type based on the program address - transactions involving `whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc` are classified as 'whirlpools', while those involving `9W959DqEETiGZocYWCQPaJ6sBmUzgfxXfqGeTEdp3aQP` are classified as 'Orca Token Swap V2'
- **Key fields**: `signer` (user address), `block_timestamp` (transaction time), `product_id` (whirlpools or Orca Token Swap V2), `chain` (solana), token addresses, and swap amounts

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily distinct active users from the filtered trade data
- **Logic**: Group the filtered trade data by day (truncating timestamps to daily boundaries), chain, and product ID. For each day-chain-product combination, count distinct signer addresses to determine daily active users. Classify all users as 'Trader' user type since the data represents trading activity. This creates the foundation dataset of daily user activity that will be used for weekly rolling window calculations
- **Key fields**: `timestamp` (daily boundary), `timestamp_grain` (day), `chain`, `user_type` (Trader), `product_id`, and `user_dau` (distinct signer addresses)

### Component C: HLL initialization and daily aggregation
- **Purpose**: Convert daily user sets into HyperLogLog data structures for efficient weekly calculations
- **Logic**: Take the daily active user data and initialize HLL data structures for each day-chain-product combination. HLL structures enable approximate distinct counting that can be efficiently merged across time windows. Group by timestamp, timestamp grain, chain, user type, and product ID, then initialize HLL with precision 15 for each daily user set
- **Key fields**: `hll` (HyperLogLog data structure containing daily user approximations), along with grouping dimensions

### Component D: Rolling window creation with datespine
- **Purpose**: Create 7-day rolling windows ensuring no missing dates in the time series
- **Logic**: Generate a complete datespine covering all dates from the earliest available data to yesterday. For each date in the datespine, create a 7-day lookback window by generating an array of the current date plus the 6 preceding days. This creates a joinable structure where each target date maps to all 7 days that should be included in its weekly calculation, ensuring consistent 7-day windows even when some days have no activity
- **Key fields**: `timestamp` (target date), `joinday` (each of the 7 days in the rolling window)

### Component E: WAU window construction
- **Purpose**: Combine the rolling window structure with daily HLL data to prepare for weekly aggregation
- **Logic**: Join the datespine rolling window structure with the daily HLL data, matching each day in the 7-day windows to its corresponding daily HLL structure. This creates a dataset where each target date has up to 7 HLL structures representing the daily user activity for each day in its rolling window. Apply incremental processing filters to limit the data range for efficiency
- **Key fields**: `timestamp` (target date), dimensional grouping fields, and `hll` (daily HLL structures for the window)

### Component F: Dimensional WAU calculations
- **Purpose**: Calculate weekly active users across different dimensional breakdowns
- **Logic**: Create four separate dimensional aggregations from the WAU window data. For each dimension (project level, chain, user type, product ID), group the data appropriately and merge the HLL structures across the 7-day windows. Extract the final distinct user counts from the merged HLL structures. Project-level aggregation nulls all dimension fields, chain-level keeps only chain ID, user type keeps only user type, and product-level keeps only product ID. Each aggregation results in weekly active user counts for that specific dimensional breakdown
- **Key fields**: `dimensions` (breakdown type), relevant dimension fields, and `user_wau` (extracted distinct count from merged HLL)

### Final aggregation
- **Combining components**: Union all dimensional breakdown results into a single dataset containing weekly active users across all dimension types
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 7-day rolling windows with daily granularity, meaning each date represents the count of distinct users active in that date plus the 6 preceding days
- **Final calculation**: The final `user_wau` value represents the approximate distinct count of users who were active in any of the 7 days ending on the given timestamp, extracted from merged HyperLogLog structures and processed through the finalize_metric_user_wau macro with zero-filling for missing periods

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

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

OrcaORCA

Active users (weekly)

Active users (weekly)

Competitive landscape