Uniswap Labs collects fees from trades conducted through its interfaces.

Uniswap Labs, established by Hayden Adams in 2018, is a software development company that specializes in creating products for the Uniswap Protocol. This includes the development and maintenance of various applications like the Uniswap web app, a mobile wallet, and an NFT aggregator.

Uniswap Labs acts as a developer and maintainer of the Uniswap Protocol. The company functions independently from the decentralized governance of the protocol.

governance

github

twitter

discord

website

Exchanges (DEX)

Uniswap Labs

# Uniswap Labs Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for UniswapLabs measures the unique number of users who generated fees through trading activity within a 30-day rolling window. This metric captures trader engagement across UniswapLabs' decentralized exchange ecosystem, including both traditional AMM swaps and UniswapX Dutch auction orders. The calculation uses HyperLogLog approximation for efficient computation of distinct user counts across multiple blockchain networks and provides breakdowns by chain, user type, and product dimensions.

## 2. Data sources

The calculation relies on the following blockchain data sources:
- **UniswapX Dutch auction events**: Parsed `UniswapXDutchOrderReactor_Fill_event` logs from Ethereum containing order execution details
- **Multi-chain token transfer events**: Parsed `Transfer` events from Ethereum, Arbitrum, Avalanche, Base, BSC, Polygon, and Optimism capturing fee payments
- **Transaction records**: Multi-chain transaction data providing user addresses and timestamps for activity tracking
- **Chain availability metadata**: Information about which chains should be included in the final output
- **Smart contract addresses**: Predefined lists of router addresses (transaction originators) and collector addresses (fee recipients) for each supported blockchain

## 3. Step-by-step calculation

### Component A: UniswapX fee identification
- **Purpose**: Identify fee-generating transactions from UniswapX Dutch auction orders
- **Logic**: Extract `UniswapXDutchOrderReactor_Fill_event` logs from Ethereum to identify completed Dutch auction orders. Match these events with corresponding token transfer records where tokens are sent to specific collector addresses. The user address is taken from the `swapper` field in the Fill event, and fees are captured from token transfers within the same transaction to collector addresses `0x37a8f295612602f2774d331e562be9e61b83a327` and `0x6460d14dbaeb27aefec8ebef85db35defa31c3b9`
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for transaction linking, `swapper` for user identification, and `value` for fee amounts

### Component B: Traditional AMM fee identification  
- **Purpose**: Identify fee-generating transactions from traditional Uniswap AMM swaps
- **Logic**: Capture token transfers across seven blockchains where tokens flow from known router addresses to known collector addresses. Router addresses are the smart contracts that facilitate swaps, while collector addresses are where interface fees are sent. The user address comes from the transaction's `from_address` field. Fee collection is limited to transactions before December 25, 2025, when the UNIfication proposal eliminated interface fees
- **Key fields**: `from_address` from transaction records for user identification, `to_address` and `from_address` from transfers for fee flow tracking, `value` for fee amounts, and `token_address` for asset identification

### Component C: Fee consolidation and filtering
- **Purpose**: Combine all fee sources and apply data quality filters
- **Logic**: Union the UniswapX and traditional AMM fee data while excluding transfers involving the denylisted token address `0x63b420fb3294ba1d300ce5d3ba4bbca0f4fe5e3b`. Each fee transaction is classified with business metadata including `business_line` as 'Exchange AMM', `market_sector_id` as 'exchanges', and `business_segment_id` as 'dex'
- **Key fields**: All fee transactions are standardized with common fields for `user_address`, `token_address`, `amount`, `chain`, and business classification

### Component D: Daily active user calculation
- **Purpose**: Transform fee transactions into daily active user records
- **Logic**: Group fee transactions by date (truncated to day) and extract unique user addresses. Each user is classified as user type 'Trader' since they performed fee-generating trading activity. The result includes daily records of active users grouped by chain, user type, and product dimensions
- **Key fields**: `timestamp` truncated to day granularity, `user_address` as the unique identifier, `chain` for blockchain identification, and `user_type` set to 'Trader'

### Component E: HyperLogLog sketch creation
- **Purpose**: Create approximate distinct count data structures for efficient MAU calculation
- **Logic**: Convert daily active user sets into HyperLogLog sketches using BigQuery's `hll_count.init` function with 15-bit precision. Group sketches by timestamp, chain, user type, and product to prepare for rolling window aggregation
- **Key fields**: `hll` containing the HyperLogLog sketch of daily users, along with all dimensional grouping fields

### Component F: Rolling window construction
- **Purpose**: Create 30-day rolling windows for MAU calculation
- **Logic**: Generate a complete date spine covering the full time range, then for each date, create joins to the previous 29 days using `generate_timestamp_array` with 1-day intervals. This ensures every day has access to the full 30-day historical window needed for MAU calculation, even when some days have no activity
- **Key fields**: `timestamp` for the current date and `joinday` for each day in the 30-day window

### Component G: Window aggregation
- **Purpose**: Combine daily HLL sketches across 30-day windows
- **Logic**: Join the rolling window structure with daily HLL sketches, matching on the join dates. For each target date, collect all HLL sketches from the current day and previous 29 days. This creates the foundation for merging user sets across the monthly window
- **Key fields**: Target `timestamp`, dimensional fields (`chain_id`, `user_type`, `product_id`), and `hll` sketches for each day in the window

### Final aggregation
- **Combining components**: Merge HLL sketches within each 30-day window using BigQuery's `hll_count.merge_partial` function, then extract the final distinct count using `hll_count.extract`. Create separate aggregations for four dimension breakdowns: project-wide (all dimensions nulled), by chain, by user type, and by product level
- **Time aggregation**: Use daily timestamps with 30-day rolling windows, where each day represents the MAU for that day and the previous 29 days
- **Final calculation**: The MAU value is the distinct count of users who generated fees within any of the 30 days ending on the target date, calculated using HyperLogLog approximation for computational efficiency. Results are combined across all dimension breakdowns and processed through the `finalize_metric_user_mau` macro for standardized formatting and zero-filling of missing periods

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

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

Uniswap Labs

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown