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 addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that initiated at least one transaction on the Polygon network within a rolling 30-day window. This metric tracks network usage by counting distinct transaction senders, providing insight into user adoption and engagement. The calculation uses HyperLogLog sketches for memory-efficient unique address counting across the rolling window.

## 2. Data sources

- **Polygon blockchain transaction records**: Raw transaction data from the Polygon network including transaction hashes, sender addresses (`from_address`), recipient addresses (`to_address`), block timestamps, gas usage, and transaction status
- **Table modification metadata**: Internal tracking data for incremental processing that records last modification times of dependent tables to optimize data pipeline execution

## 3. Step-by-step calculation

### Component A: Transaction fact extraction
- **Purpose**: Extract and standardize Polygon transaction data with gas information
- **Logic**: Process raw Polygon transaction records to identify key transaction attributes. Filter for successful transactions and extract sender addresses (`from_address`) as potential active users. Include transaction metadata like block timestamp, transaction hash, gas usage, and effective gas price. Apply decimal corrections to gas price values by dividing by 10^18 to convert from wei to POL units. Set static metadata fields including market sector (`blockchains_l1`), business segment (`blockchain`), and token address for wrapped POL (`0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270`)
- **Key fields**: `block_timestamp` for temporal grouping, `from_address` as the active user identifier, `transaction_hash` for uniqueness, gas usage and pricing information

### Component B: Daily active user identification
- **Purpose**: Identify unique transaction senders on a daily basis
- **Logic**: Group transaction data by day using timestamp truncation to day granularity. Extract distinct sender addresses (`from_address`) for each day as daily active users. Classify users by type as "Transaction sender" since these represent addresses initiating transactions. Apply incremental processing logic to only process recent data based on lookback periods from the last pipeline execution
- **Key fields**: `timestamp` truncated to day, `user_dau` containing the sender address, `user_type` classification, chain and product metadata

### Component C: HyperLogLog sketch creation
- **Purpose**: Create memory-efficient cardinality estimation structures for unique address counting
- **Logic**: Transform daily active user data into HyperLogLog sketches using `HLL_COUNT.INIT` with precision parameter 15. Group by timestamp, chain, user type, and product dimensions. These sketches enable efficient approximate counting of unique values while using minimal memory, essential for processing large-scale blockchain data across rolling windows
- **Key fields**: `hll` sketch containing compressed unique address information, dimensional grouping fields for later aggregation

### Component D: Rolling window construction
- **Purpose**: Build 30-day rolling windows for monthly active user calculation
- **Logic**: Create a complete datespine using `GENERATE_TIMESTAMP_ARRAY` from the minimum available date to yesterday. For each target date, generate a corresponding array of the previous 30 days (including the target date) using another `GENERATE_TIMESTAMP_ARRAY` with a 29-day lookback. Use `UNNEST` to expand these arrays into individual date pairs, creating a comprehensive mapping between target dates and their constituent 30-day windows
- **Key fields**: `timestamp` as the target date, `joinday` representing each day within the 30-day window

### Component E: Window-based HLL merging
- **Purpose**: Aggregate unique addresses across 30-day rolling windows
- **Logic**: Join the rolling window structure with daily HLL sketches on matching dates. For each target date, collect all HLL sketches from the corresponding 30-day period. Use `HLL_COUNT.MERGE_PARTIAL` to combine sketches from multiple days, then `HLL_COUNT.EXTRACT` to obtain the final unique address count. This approach efficiently calculates rolling 30-day unique users without storing or processing individual addresses multiple times
- **Key fields**: Merged `hll` sketches, `user_mau` as the extracted unique address count

### Component F: Dimensional breakdown
- **Purpose**: Calculate monthly active users across different analytical dimensions
- **Logic**: Process the windowed data through four parallel aggregation paths. First, aggregate at the project level (`project_dbt_tag` dimension) by merging all HLL sketches regardless of chain or user type. Second, aggregate by chain level maintaining chain identity but merging across user types. Third, aggregate by user type while merging across chains. Fourth, aggregate by product maintaining product distinctions. Each aggregation nullifies non-relevant dimensional fields and uses `UNION ALL` to combine all dimensional views into a single comprehensive dataset
- **Key fields**: `dimensions` indicating the aggregation level, `user_mau` counts for each dimensional combination

### Final aggregation
- **Combining components**: The dimensional breakdown results are combined using `UNION ALL` operations to create a comprehensive view of monthly active users across all analytical dimensions. Each row represents a unique combination of timestamp, dimension type, and applicable dimensional values (chain, product, user type)
- **Currency conversion**: No currency conversion required as this metric counts addresses rather than monetary values
- **Time aggregation**: Uses rolling 30-day windows calculated daily, with each day representing the monthly active address count for the preceding 30-day period including that day
- **Final calculation**: The `user_mau` field from the MAU calculation directly becomes `active_addresses_monthly` since for blockchain networks, active users are equivalent to active addresses. The `finalize_metric_active_addresses_monthly` macro applies final schema standardization, data validation, and fills missing days with zero values where no activity occurred

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

Unique addresses active over a rolling 30-day window.

PolygonPOL

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown