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

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who performed at least one trade on Curve protocol within any 7-day period. This metric provides insight into user engagement and protocol adoption by tracking distinct addresses that actively use Curve's decentralized exchange functionality across different time windows. The calculation uses HyperLogLog data structures for efficient approximate counting across rolling 7-day windows, ensuring accurate unique user counts even with large datasets.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Curve contract events**: Parsed `TokenExchange`, `TokenExchangeV2`, and `TokenExchangeUnderlying` events from Curve protocol smart contracts on Ethereum, including events from `TwoCryptoPool`, `TriCryptoPool`, and `StablePool` contract types across different protocol versions (v1 and v2)
- **Ethereum transaction data**: Transaction records that provide the originating user address (`from_address`) for each trade, which represents the actual user performing the trading activity
- **Contract metadata**: Information about Curve pool contracts, versions, and business classifications used for dimensional breakdowns

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Identifies all trading activity on Curve protocol by extracting exchange events from various pool types
- **Logic**: Collects `TokenExchange`, `TokenExchangeV2`, and `TokenExchangeUnderlying` events from different Curve pool contracts including `TwoCryptoPool`, `TriCryptoPool`, and `StablePool` across protocol versions. Each event represents a user swap transaction and includes details like token amounts, token IDs, and contract addresses. The events are joined with Ethereum transaction data to identify the actual user who initiated the transaction through the `from_address` field
- **Key fields**: `block_timestamp` for daily grouping, `user_address` from transaction `from_address` for user identification, `chain` for blockchain classification, `version` for protocol version tracking

### Component B: Daily active user aggregation  
- **Purpose**: Converts raw trading events into daily unique user counts while preserving dimensional metadata
- **Logic**: Groups trading events by daily boundaries using `timestamp_trunc` on `block_timestamp`. Extracts unique `user_address` values per day and classifies all users as `user_type` 'Trader' since they performed trading activity. Preserves dimensional information including `chain`, `market_sector_id` as 'exchanges', `business_segment_id` as 'dex', and `product_id` for further breakdown analysis
- **Key fields**: `timestamp` as daily boundary, `user_dau` containing unique user addresses, `user_type` set to 'Trader', dimensional classification fields

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily user sets into efficient probabilistic data structures for scalable distinct counting
- **Logic**: Transforms daily active user data into HyperLogLog (HLL) structures using `hll_count.init` with precision parameter 15. This allows approximate but highly efficient counting of distinct users across time windows without storing individual user addresses. Groups data by `timestamp`, `chain_id`, `user_type`, and `product_id` to maintain dimensional granularity
- **Key fields**: `hll` containing the probabilistic user count structure, all dimensional grouping fields preserved

### Component D: Continuous time series generation
- **Purpose**: Creates a complete daily datespine to ensure no gaps in the time series for accurate rolling window calculations
- **Logic**: Generates a continuous array of daily timestamps from the earliest available trade date through yesterday using `generate_timestamp_array`. This datespine ensures that periods with no trading activity are still represented in the final dataset, which is critical for consistent weekly window calculations
- **Key fields**: `timestamp` representing each day in the continuous series

### Component E: Rolling window creation
- **Purpose**: Establishes 7-day rolling windows for each day to define the periods over which weekly active users are calculated
- **Logic**: For each day in the datespine, generates the 7 preceding days (including the current day) using `generate_timestamp_array` with 6-day lookback. Creates a mapping table where each `timestamp` is associated with 7 `joinday` values representing the days to include in that week's calculation. This approach ensures consistent 7-day windows regardless of data gaps
- **Key fields**: `timestamp` as the window end date, `joinday` as each day within the 7-day window

### Component F: Window data aggregation
- **Purpose**: Combines the rolling window structure with daily HLL data to prepare for weekly user count calculation
- **Logic**: Joins the 7-day window mappings with daily HLL data by matching `joinday` with daily `timestamp` values. This creates a dataset where each weekly window period contains all the daily HLL structures needed for that week. Preserves all dimensional information including `chain_id`, `user_type`, and `product_id` for breakdown calculations
- **Key fields**: `timestamp` as weekly window identifier, `hll` containing daily user data, dimensional breakdown fields

### Component G: Weekly active user calculation by dimensions
- **Purpose**: Calculates WAU across different dimensional breakdowns to support various analysis perspectives
- **Logic**: Performs separate WAU calculations for four dimensional levels:
  - **Project level**: Aggregates all users across all dimensions using `hll_count.merge_partial` to combine daily HLL structures within each 7-day window, then `hll_count.extract` to get final unique user count
  - **Chain level**: Groups by `chain_id` and calculates WAU separately for each blockchain
  - **User type level**: Groups by `user_type` (currently only 'Trader') for user classification analysis  
  - **Product level**: Groups by `product_id` to analyze WAU by specific Curve products or pool types
Each calculation merges HLL structures across the 7-day window and extracts the approximate distinct user count
- **Key fields**: `user_wau` containing the weekly unique user count, `dimensions` indicating breakdown type, relevant dimensional identifier fields

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using `UNION ALL` to create a unified dataset containing WAU metrics at project, chain, user type, and product levels. Each row represents a specific dimensional view of weekly active users for a given time period
- **Schema standardization**: The `finalize_metric_user_wau` macro applies standard schema formatting, ensures consistent field naming and types, and implements a fill strategy of 'fill_zeros' to populate missing periods with zero values rather than NULL
- **Time boundaries**: For incremental updates, the calculation includes a safety margin by processing data from 29 days plus configurable lookback days before the last modified time to ensure data completeness and handle late-arriving events
- **Final calculation**: The metric represents the approximate count of unique user addresses that performed at least one trade on Curve protocol within any 7-day rolling window, calculated using HyperLogLog probabilistic counting for efficiency and scalability

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

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

CurveCRV

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown