Validators process transactions and receive fees from users (supply-side fees).

Polygon is a smart contract platform for decentralized applications & interoperability platform for blockchains. Polygon was founded by Jaynti Kanani, Sandeep Nailwal & Anurag Arjun and launched in 2017.

MATIC holders own and govern the protocol. They currently take a cut of the total transaction fees paid by users (revenue). Polygon’s investors include Coinbase Ventures, ZBS Capital, MiH Ventures, etc.

github

twitter

discord

etherscan

website

Blockchains (L1)

Polygon

# Polygon Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique addresses that have sent at least one transaction on the Polygon network within any 30-day period. This metric uses a rolling 30-day window approach, where each day's MAU represents the count of unique transaction senders over the current day plus the previous 29 days. The calculation employs HyperLogLog sketches for efficient cardinality estimation and provides dimensional breakdowns by project, chain, user type, and product.

## 2. Data sources

- **Polygon blockchain transaction records**: Raw transaction data from the Polygon network including timestamps, transaction hashes, sender addresses, receiver addresses, gas usage, and gas prices
- **Chain availability configuration**: Data quality filters that determine when Polygon chain data is considered complete and reliable for analysis

## 3. Step-by-step calculation

### Component A: Transaction processing
- **Purpose**: Extract and standardize raw Polygon transaction data
- **Logic**: Process all transactions from Polygon blockchain records, extracting key fields including block timestamps, transaction hashes, sender addresses (`from_address`), and receiver addresses (`to_address`). Add standardized business metadata including market sector identifier as 'blockchains_l1', business segment as 'blockchain', and token address set to the wrapped POL address `0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270`. Calculate gas metrics by converting `receipt_gas_used` and `receipt_effective_gas_price` from wei to standard decimal format.
- **Key fields**: `block_timestamp`, `from_address`, `to_address`, `transaction_hash`, `gas_used`, `effective_gas_price`

### Component B: Daily active users aggregation  
- **Purpose**: Identify unique transaction senders per day
- **Logic**: Group processed transactions by day using timestamp truncation to daily granularity. Extract unique sender addresses (`from_address`) for each day, classifying them as 'Transaction sender' user type. Apply chain availability filters to ensure only reliable data periods are included. Preserve metadata fields including market sector, business segment, and product identifiers for dimensional analysis.
- **Key fields**: `timestamp` (daily), `user_dau` (sender address), `user_type`, `chain`, `product_id`

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user lists into efficient cardinality estimation structures
- **Logic**: Transform daily unique user lists into HyperLogLog sketches with 15-bit precision using the `hll_count.init` function. Group sketches by timestamp, timestamp grain, chain ID, user type, and product ID to maintain dimensional structure for later breakdowns.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: 30-day sliding window construction
- **Purpose**: Create rolling 30-day periods for MAU calculation
- **Logic**: Generate a comprehensive datespine covering all days from the earliest available data to the current date minus one day. For each day in the datespine, create a 30-day window by generating timestamp arrays spanning from 29 days before through the current day. Join the datespine with daily HLL sketches to create window-day combinations, ensuring all possible 30-day periods are covered.
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within window), `hll` (daily sketches)

### Component E: Window aggregation and dimensional breakdown
- **Purpose**: Calculate unique user counts across 30-day windows with multiple dimensional views
- **Logic**: For each 30-day window, merge all HLL sketches within the period using `hll_count.merge_partial` and extract the final cardinality estimate using `hll_count.extract`. Create four separate dimensional breakdowns: project level (overall MAU with no dimensional filters), chain level (grouped by chain ID), user type level (grouped by user classification), and product level (grouped by product ID). Each breakdown maintains the same MAU calculation logic but applies different grouping criteria.
- **Key fields**: `user_mau` (unique user count), `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project, chain, user type, product) into a single result set using `UNION ALL`, creating a comprehensive view of MAU across all dimensional cuts
- **Currency conversion**: Not applicable for this user-based metric
- **Time aggregation**: Uses daily timestamps with 30-day rolling windows, partitioned by month for efficient storage and querying
- **Final calculation**: Apply the `finalize_metric_user_mau` macro with 'polygon' as data ID and 'fill_zeros' strategy to standardize schema, fill missing time periods with zero values, and ensure consistent output formatting across all dimensional breakdowns

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

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

PolygonPOL

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown