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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active user on the Curve protocol. This metric is calculated by dividing total daily revenue by the number of daily active users (DAU). The metric helps assess user monetization efficiency and provides insights into the protocol's revenue generation per participant. ARPU combines revenue from decentralized exchange operations, stablecoin issuance, and governance incentives, divided by the count of unique users who traded on Curve pools each day.

## 2. Data sources

The ARPU calculation relies on multiple blockchain and external data sources:

- **DEX trade events**: Parsed `TokenExchange`, `TokenExchangeV2`, and `TokenExchangeUnderlying` events from Curve's various pool contracts (stable pools, two-crypto pools, tri-crypto pools) across Ethereum
- **Pool state data**: Daily snapshots of pool balances, virtual prices, XCP profits, and protocol fee tiers from Curve pool contracts
- **Fee collection events**: `CollectFees` events from Curve's crvUSD controller contracts
- **Voting incentive data**: Reward token deposits to Curve gauge contracts via `deposit_reward_token` function calls
- **stETH rebase data**: `PostTotalShares` and `TokenRebased` events from Lido contracts for rebasing token APR calculations
- **Transaction records**: Ethereum transaction data to identify user addresses from trade activities
- **External price feeds**: End-of-day token price data for USD conversion
- **Token metadata**: Token symbols, decimals, and addresses for proper value normalization
- **Registry data**: Curve pool and gauge registry information for contract identification and validation

## 3. Step-by-step calculation

### Component A: DEX trading fee revenue
- **Purpose**: Calculate revenue generated from trading fees on Curve DEX pools
- **Logic**: Trading fees are derived from pool APRs multiplied by TVL. For stable pools, APRs are calculated from virtual price changes between consecutive days. For volatile pools, APRs come from XCP profit changes. The calculation takes the previous day's TVL multiplied by the APR to get total fees, then applies the formula: fees × (1 - protocol_fee_tier) to determine supply-side revenue. Protocol fee tiers are extracted from pool state data, with a default of 0 if unavailable. Special handling includes subtracting rebasing token APRs (like stETH) from pool APRs to avoid double-counting yield from underlying assets.
- **Key fields**: Pool addresses (`account_address`), daily snapshots (`timestamp`), virtual prices and XCP profits from state data, protocol fee tiers (`protocol_fee_tier`), and calculated TVL (`net_deposits`)

### Component B: crvUSD fee revenue
- **Purpose**: Capture direct fees from Curve's stablecoin operations
- **Logic**: Fee collection events from the crvUSD controller contract are aggregated daily. These events contain the fee amounts collected by the protocol from crvUSD operations such as minting, borrowing, and liquidations. The raw event data includes amounts that are summed per day and converted to USD.
- **Key fields**: Fee amounts (`amount`) from `CollectFees` events, crvUSD token address, and daily timestamps

### Component C: Voting incentive revenue
- **Purpose**: Track revenue from external reward token deposits to Curve gauges
- **Logic**: External protocols deposit reward tokens to Curve gauges as voting incentives to attract veCRV holders' votes. These deposits are captured from `deposit_reward_token` function calls on gauge contracts. Only deposits to registered gauges in the Curve ecosystem are included, filtering out unrelated contracts. Daily amounts are aggregated and converted to USD.
- **Key fields**: Reward token addresses (`token_address`), deposit amounts (`amount`), gauge addresses (`account_address`), and timestamps

### Component D: Daily active users calculation
- **Purpose**: Count unique users who actively traded on Curve pools each day
- **Logic**: Trade events from all Curve pool types are processed to extract user addresses from transaction records. Users are identified as the `from_address` of transactions containing trade events. Daily distinct user counts are calculated using HyperLogLog sketches to enable accurate counting across different dimensional breakdowns (by chain, user type, product). The system tracks only "Trader" user types from actual trading activity.
- **Key fields**: User addresses (`user_address`) from transaction records, trade event timestamps, and pool identifiers

### Final aggregation
- **Combining components**: Revenue components are summed daily across all sources (DEX fees, crvUSD fees, voting incentives) with appropriate business segment classifications. User counts are aggregated using HyperLogLog merge operations to maintain accuracy across dimensional breakdowns.
- **Currency conversion**: All token amounts are converted to USD using end-of-day price feeds, with decimal adjustments applied based on token metadata. Conversion happens after aggregation but before final ARPU calculation.
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation to day granularity. All events within a calendar day contribute to that day's metrics.
- **Final calculation**: ARPU is calculated as total daily revenue divided by daily active users using the `calculate_arpu` macro. The result undergoes final standardization including zero-filling for days with no activity and proper dimensional labeling through the `finalize_metric_arpu` macro.

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

CurveCRV

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape