Liquidity providers deposit funds into Curve and receive trading fees from traders (supply-side fees).

Curve is a non-custodial exchange protocol built originally on Ethereum. Curve was founded by Michael Egorov and launched in 2020.

CRV tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). 

governance

github

twitter

discord

etherscan

website

Exchanges (DEX)

Curve

# Curve Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Curve protocol measures the number of unique users who executed at least one trade on Curve DEX within a rolling 30-day window. This metric uses a sliding window approach where each date shows the count of distinct users who traded in the current day plus the previous 29 days. The calculation uses HyperLogLog probabilistic data structures to efficiently count distinct users across multiple dimensions while maintaining accuracy for large datasets.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Curve smart contract events**: Parsed `TokenExchange`, `TokenExchangeV2`, and `TokenExchangeUnderlying` events from Curve v1 Ethereum pools including TwoCryptoPool, TriCryptoPool, and StablePool contracts
- **Ethereum transaction records**: Transaction metadata to identify user addresses (`from_address`) who initiated trades
- **Token metadata**: Information about tokens being traded including token IDs and contract addresses from Curve pool configurations
- **Blockchain transaction traces**: Complete transaction execution data to link events to user addresses

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Identifies all trading activity across Curve pools to determine user interactions
- **Logic**: Extracts swap events from multiple Curve pool types on Ethereum including stable pools, crypto pools, and tricrypto pools. Captures different exchange event types (`TokenExchange`, `TokenExchangeV2`, `TokenExchangeUnderlying`) to handle various pool configurations. Joins event data with transaction records to identify the originating user address. Filters for exchange-related activity and classifies all users as 'Trader' type
- **Key fields**: `block_timestamp` for timing, `user_address` from transaction `from_address`, `chain` identifier, `token0_id` and `token1_id` for traded tokens, `token0_amount` and `token1_amount` for swap quantities

### Component B: Daily active user aggregation
- **Purpose**: Converts trading activity into daily unique user counts while preserving user identity for MAU calculations
- **Logic**: Groups trading events by day using `timestamp_trunc` to daily boundaries. Identifies distinct users per day while maintaining user address information for downstream distinct counting. Applies chain availability filtering and categorizes all activity under 'Trader' user type. Creates the foundation dataset with proper time boundaries for MAU window calculations
- **Key fields**: `timestamp` truncated to day, `timestamp_grain` set to 'day', `chain` identifier, `user_type` as 'Trader', `user_dau` containing user addresses

### Component C: HyperLogLog sketch creation
- **Purpose**: Converts daily user lists into probabilistic data structures for efficient distinct counting across time windows
- **Logic**: Transforms daily user address lists into HyperLogLog sketches using `hll_count.init` with precision 15. Groups by timestamp, chain, user type, and product dimensions. Creates compressed representations of user sets that can be efficiently merged across time periods while maintaining distinct count accuracy
- **Key fields**: `hll` containing compressed user sketches, dimensional grouping fields for later breakdown analysis

### Component D: Rolling window construction
- **Purpose**: Creates 30-day sliding windows for MAU calculation using a datespine approach
- **Logic**: Generates a continuous date spine from earliest trading date to current date using `generate_timestamp_array`. For each date in the spine, creates join relationships to the previous 29 days using nested `unnest` operations. This ensures every date has a complete 30-day lookback window even if some days had no trading activity. Handles incremental processing with appropriate lookback periods for model refreshes
- **Key fields**: `timestamp` for the target date, `joinday` for each day in the 30-day window

### Component E: Window-based HLL merging
- **Purpose**: Combines HyperLogLog sketches across 30-day windows to calculate distinct user counts
- **Logic**: Joins the datespine windows with daily HLL sketches to create 30-day data collections for each target date. For dates with missing activity, the window may contain fewer than 30 days of data. Maintains dimensional groupings (chain, user type, product) throughout the windowing process to support multiple breakdowns
- **Key fields**: `timestamp` for target date, `hll` sketches for each day in window, dimensional grouping fields

### Component F: Dimensional MAU calculation
- **Purpose**: Calculates MAU across different analytical dimensions while maintaining distinct user counts
- **Logic**: Creates four separate MAU calculations: project-level (all users combined), chain-level breakdown, user type breakdown, and product ID breakdown. For each dimension, merges HLL sketches using `hll_count.merge_partial` across the 30-day window, then extracts the final distinct count using `hll_count.extract`. Sets unused dimensions to null to maintain consistent schema across breakdowns
- **Key fields**: `user_mau` containing final distinct counts, `dimensions` indicating breakdown type, `chain_id`, `product_id`, `user_type` for dimensional analysis

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project, chain, user type, product) into a single result set with consistent schema structure
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily timestamps with 30-day rolling windows, meaning each date represents MAU for that date plus the previous 29 days
- **Final calculation**: The `user_mau` field contains the exact count of distinct users who traded within the 30-day window ending on each date, calculated using HyperLogLog merge operations that maintain accuracy while enabling efficient computation across large datasets and multiple dimensions

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

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

CurveCRV

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown