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

Pangolin is a non-custodial exchange protocol built on Avalanche (originally a fork of Uniswap). Pangolin was founded by an anonymous team and launched in 2020.

PNG 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)

Pangolin

# Pangolin Active users (monthly) Methodology

## 1. Overview

The Pangolin MAU metric measures the number of unique users who have executed trades on the Pangolin DEX over a rolling 30-day period. This metric answers the business question "How many distinct users are actively trading on Pangolin each month?" The calculation uses a rolling window approach combined with HyperLogLog sketches for efficient approximate distinct counting across multiple dimensions.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Pangolin V1 swap events**: Parsed `Swap` events from Pangolin V1 `Pair` contracts on the Avalanche blockchain, containing trade execution details including token amounts, sender addresses, and transaction context
- **Avalanche transaction records**: Transaction-level data from the Avalanche blockchain providing user addresses (`from_address`) and timestamps for each transaction
- **Table modification timestamps**: Metadata tracking when data was last updated to support incremental processing and determine appropriate lookback windows

## 3. Step-by-step calculation

### Component A: Trade fact extraction
- **Purpose**: Extract and standardize trade events from raw Pangolin swap data
- **Logic**: Parse Pangolin V1 `Swap` events from `Pair` contracts on Avalanche blockchain. Calculate net token amounts for each trade by subtracting output amounts from input amounts for both `token0` and `token1`. Join swap events with Avalanche transaction records to identify the actual user address executing the trade (from the transaction `from_address` field rather than the contract sender). Filter data to include only trades from February 8, 2021 onwards when Pangolin launched.
- **Key fields**: Captures `block_timestamp`, `transaction_hash`, `log_index`, user address from transaction records, token amounts calculated as net changes, and standardized metadata including chain (`avalanche`), business classification (`Exchange AMM`, `exchanges`, `dex`), and version (`v1`)

### Component B: Daily active user calculation  
- **Purpose**: Aggregate trade facts into daily distinct user counts
- **Logic**: Group trade facts by day using timestamp truncation to day granularity. Count distinct user addresses per day who executed at least one trade. Classify all users as `Trader` type since the metric focuses on trading activity. Initialize HyperLogLog sketches for efficient distinct counting in downstream aggregations.
- **Key fields**: Produces daily timestamps, user addresses as distinct identifiers, user type classification, and dimensional attributes like `chain`, `product_id`, and business segment classifications

### Component C: Rolling window construction
- **Purpose**: Create 30-day rolling windows for MAU calculation
- **Logic**: Generate a complete date spine covering all days from the earliest trade date to yesterday to ensure no gaps in the time series. For each date in the spine, create a 30-day lookback window by generating an array of the current day plus the previous 29 days. Join this expanded date range with the daily active user data to capture all users active within each rolling window period.
- **Key fields**: Maintains timestamp relationships between window dates and constituent days, preserves all dimensional attributes from daily data, and retains HLL sketches for efficient aggregation

### Component D: HyperLogLog aggregation
- **Purpose**: Efficiently count distinct users across the 30-day rolling windows
- **Logic**: For each rolling window, merge HyperLogLog sketches from all constituent days using BigQuery's `hll_count.merge_partial()` function. Extract the approximate distinct count using `hll_count.extract()`. This approach provides memory-efficient approximate distinct counting that scales well for large user bases while maintaining reasonable accuracy.
- **Key fields**: Produces estimated distinct user counts for each 30-day window while preserving all dimensional breakdowns

### Component E: Multi-dimensional breakdowns
- **Purpose**: Generate MAU metrics across different analytical dimensions
- **Logic**: Create separate aggregations for different analytical perspectives: project-level MAU (overall Pangolin performance), chain-level MAU (currently only Avalanche), user-type MAU (all traders), and product-level MAU (if multiple products exist). Each breakdown aggregates the HLL sketches appropriately while nullifying irrelevant dimension fields.
- **Key fields**: Each breakdown produces timestamp, dimension type identifier, relevant dimension value, and the MAU count, with other dimension fields set to null for clarity

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, creating a comprehensive view of MAU across all analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 30-day windows calculated daily, with monthly partitioning for efficient storage and querying
- **Final calculation**: The final MAU value represents the approximate count of distinct users who executed at least one trade on Pangolin within any 30-day period, calculated using HyperLogLog sketches for computational efficiency and broken down by project, chain, user type, and product dimensions

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

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

PangolinPNG

Active users (monthly)

Active users (monthly)

Competitive landscape