Liquidity providers deposit funds into Clipper and receive returns generated by Clipper’s costless diversified rebalancing liquidity pools (supply-side fees). LP yields are generated from the rebalancing process itself rather than from fees charged to traders.

Clipper is a non-custodial exchange protocol built on Ethereum. Clipper was built by Shipyard Software and launched in 2021.

AdmiralDAO and SAIL token holders own and govern the protocol. They currently receive all trading fees paid by traders (revenue). Clipper's investors include Polychain, Robot Ventures, 0x Labs, etc.

github

twitter

discord

etherscan

website

Exchanges (DEX)

Clipper

# Clipper Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) represents the count of unique users who have executed at least one trade on Clipper DEX within a rolling 30-day window. This metric provides insight into user engagement and platform adoption across Clipper's multi-chain deployment. The calculation uses HyperLogLog data structures to efficiently count unique users across time windows and dimensional breakdowns.

## 2. Data sources

- **Blockchain events**: Parsed `Swapped` events from Clipper's DEX contracts deployed across Ethereum, Polygon, Optimism, and Arbitrum networks. Events are collected from various contract versions including `ApproximateCaravelExchange`, `VerifiedCaravelExchange`, `CaravelExchange`, `ExchangeInterface`, `VerifiedExchange`, `DirectExchange`, `PackedVerifiedExchange`, and `PackedExchange`
- **Transaction data**: Ethereum, Polygon, Optimism, and Arbitrum transaction records to identify user addresses through the `from_address` field
- **Chain availability filters**: Applied to ensure data quality and chain-specific availability constraints

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Identifies all trading activity across Clipper's multi-chain deployment
- **Logic**: Collects parsed `Swapped` events from Clipper contracts across four chains (Ethereum, Polygon, Optimism, Arbitrum). Events are joined with transaction data to extract the user address from the `from_address` field. Each trade is tagged with chain identifier, business classification (Exchange AMM), market sector (exchanges), and version information. The system handles different contract architectures across chains while maintaining consistent data structure
- **Key fields**: `block_timestamp` for timing, `user_address` for user identification, `chain` for network classification, `transaction_hash` and `log_index` for event uniqueness

### Component B: Daily active user calculation
- **Purpose**: Converts raw trades into daily unique user counts using efficient counting structures
- **Logic**: Groups trade events by day using `timestamp_trunc` to daily granularity. Extracts unique user addresses per day and initializes HyperLogLog sketches with 15-bit precision for efficient unique counting. Users are classified as 'Trader' type and data is organized by chain, user type, and product dimensions
- **Key fields**: `timestamp` (daily granularity), `user_dau` (unique user address), `chain`, `user_type`, `product_id`

### Component C: Rolling window construction
- **Purpose**: Creates 30-day rolling windows to calculate monthly active users
- **Logic**: Generates a complete datespine from the earliest trade date to current date minus one day to ensure no missing dates. For each date, creates a 30-day lookback window by generating timestamps for the current date plus the previous 29 days. Uses cross-join between datespine and daily HLL data to create comprehensive time windows that include all days even when no trades occurred
- **Key fields**: `timestamp` (reference date), `joinday` (dates within the 30-day window), `hll` (HyperLogLog sketch from daily data)

### Component D: Dimensional MAU aggregation  
- **Purpose**: Calculates MAU across different analytical dimensions
- **Logic**: Processes the 30-day windows to calculate MAU at four levels: project-wide (all chains combined), chain-specific (individual blockchain networks), user type (currently 'Trader'), and product-specific. Uses HyperLogLog merge operations to combine daily sketches across the 30-day window, then extracts final unique user counts. Each dimension creates separate aggregation groups while maintaining efficient unique counting
- **Key fields**: `dimensions` (breakdown category), `chain_id`, `product_id`, `user_type`, `user_mau` (final unique count)

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project, chain, user type, product) into a single result set with consistent schema
- **Time aggregation**: Uses rolling 30-day windows with daily granularity, ensuring each date represents unique users from that date plus the previous 29 days
- **Final calculation**: Applies `finalize_metric_user_mau` macro to standardize the output schema, apply chain availability filters, and fill missing dates with zero values where appropriate. The final MAU count represents unique users who traded on Clipper within the 30-day window ending on each date

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

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

ClipperSAIL

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown