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

## 1. Overview

The Orca Monthly Active Users (MAU) metric measures the number of unique users who have executed trades on the Orca protocol within a rolling 30-day period. This metric provides insights into user engagement and platform adoption for Orca's decentralized exchange services on Solana. The calculation uses HyperLogLog sketches to efficiently compute distinct user counts across overlapping time windows, creating multiple dimensional views of user activity.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Solana DEX trade events**: Parsed trading events from the Solana blockchain containing transaction details, user identifiers, and program interactions
- **Orca protocol program addresses**: Specific on-chain program identifiers for Orca's trading products (`whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc` for Whirlpools and `9W959DqEETiGZocYWCQPaJ6sBmUzgfxXfqGeTEdp3aQP` for Orca Token Swap v2)
- **Solana transaction signers**: User wallet addresses that initiated trading transactions
- **Block timestamps**: Solana blockchain timestamps for temporal aggregation
- **Token mint addresses**: Solana token mint addresses for traded token pairs

## 3. Step-by-step calculation

### Component A: Trade data filtering and classification
- **Purpose**: Identifies and classifies Orca-specific trading activity from raw Solana DEX data
- **Logic**: The system filters DEX trading events to include only transactions involving Orca protocol programs. It examines both `inner_program` and `outer_program` fields to catch all Orca-related activity. Transactions are classified into product categories: `whirlpools` for the Whirlpools AMM product and `Orca Token Swap V2` for the legacy Orca Token Swap v2 product. The system extracts key trade details including user signer addresses, token mint addresses (`base_mint` and `quote_mint`), trade amounts, pool addresses, and block timestamps.
- **Key fields**: `signer` (user wallet address), `product_id` (whirlpools or Orca Token Swap V2), `block_timestamp`, `base_mint`, `quote_mint`, `base_amount`, `quote_amount`

### Component B: Daily active user aggregation
- **Purpose**: Calculates daily distinct active users from the filtered trade data
- **Logic**: For each day, the system identifies unique users by extracting distinct `signer` addresses from all Orca trades. Users are classified with a `user_type` of 'Trader' since the metric focuses on trading activity. The aggregation groups users by day (`timestamp_grain` = 'day'), chain ('solana'), and `product_id` to maintain granular breakdowns. Each unique signer address becomes a `user_dau` record for the corresponding day.
- **Key fields**: `timestamp` (daily truncated), `user_type` ('Trader'), `product_id`, `user_dau` (unique signer address)

### Component C: HyperLogLog sketch preparation
- **Purpose**: Converts daily user lists into HyperLogLog sketches for efficient set operations
- **Logic**: The system transforms daily user counts into HyperLogLog (HLL) sketches using BigQuery's `hll_count.init()` function with a precision of 15. This probabilistic data structure allows for memory-efficient storage and merging of large sets of unique users. Each day's user list is converted to an HLL sketch that can be combined with other days to calculate rolling window metrics without storing individual user identifiers.
- **Key fields**: `hll` (HyperLogLog sketch of daily users), maintaining dimensions for `chain_id`, `user_type`, `product_id`

### Component D: Rolling window generation
- **Purpose**: Creates 30-day rolling windows for MAU calculation
- **Logic**: The system generates a complete datespine covering all days from the earliest available data to the present. For each day in this datespine, it creates a 30-day window by joining with the 29 previous days plus the current day. This is accomplished by generating timestamp arrays that span from 29 days before each target date to the target date itself. The resulting `jointables` structure maps each target date to all days within its 30-day window. These windows are then joined with the daily HLL sketches to collect all user data within each rolling period.
- **Key fields**: `timestamp` (target date), `joinday` (days within the 30-day window), `hll` (user sketches for each day in the window)

### Component E: MAU calculation by dimension
- **Purpose**: Computes monthly active users across different dimensional breakdowns
- **Logic**: For each 30-day window, the system merges HyperLogLog sketches using `hll_count.merge_partial()` to combine user sets from all days in the window, then extracts the distinct count using `hll_count.extract()`. This process is repeated for four different dimensional views: project-level (overall MAU across all Orca products), chain-level (MAU by blockchain, though only Solana applies), user_type-level (MAU by user classification, though only 'Trader' applies), and product_id-level (MAU by Orca product: whirlpools vs Orca Token Swap V2). Each breakdown nullifies non-relevant dimension fields while preserving the target dimension for grouping.
- **Key fields**: `user_mau` (distinct user count), `dimensions` (breakdown type), relevant dimension fields (`chain_id`, `product_id`, `user_type`)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a unified dataset containing MAU metrics across all dimension types. Each row represents a specific date, dimension type, and dimension value combination with its corresponding MAU count.
- **Time aggregation**: The metric uses daily granularity with 30-day rolling windows, meaning each day shows the count of unique users who were active at any point during the 30-day period ending on that date.
- **Final calculation**: The final MAU value for any given day represents the distinct count of users who executed at least one trade on Orca within the 30-day period ending on that date. The `finalize_metric_user_mau` macro applies standardized schema formatting, fills missing days with zero values, and adds metadata fields required for downstream consumption.

The methodology ensures accurate, non-duplicated user counts across overlapping time periods while maintaining flexibility for different analytical perspectives through multiple dimensional breakdowns.

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

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

OrcaORCA

Active users (monthly)

Active users (monthly)

Competitive landscape