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 (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Polygon network during a 7-day period. This metric uses a sliding window approach where each day represents a new weekly period looking back 7 days. The calculation employs HyperLogLog probabilistic counting to efficiently handle large volumes of address data while maintaining accuracy for distinct counting across overlapping time windows. This metric answers the business question of user engagement and network adoption by tracking unique transaction initiators over weekly timeframes.

## 2. Data sources

The calculation relies on:
- **Polygon blockchain transactions**: Complete transaction records from the Polygon network including transaction hashes, block timestamps, sender addresses, recipient addresses, and gas usage data
- **Chain availability data**: Configuration data that defines when Polygon network data is considered available and reliable for metric calculations
- **Daily processing schedules**: Timestamp boundaries and processing schedules that define daily aggregation windows and incremental update patterns

## 3. Step-by-step calculation

### Component A: Transaction extraction
- **Purpose**: Extract all Polygon blockchain transactions and identify transaction initiators
- **Logic**: Retrieves all transaction records from Polygon blockchain data, focusing on sender addresses (`from_address`) as the key identifier for active addresses. Each transaction is associated with block timestamp information and categorized under the 'blockchains_l1' market sector. The gas token is identified as WPOL (Wrapped Polygon token at address `0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270`). All transactions are marked with 'blockchain' as the business segment and classified under 'Transaction sender' user type.
- **Key fields**: `from_address` (transaction sender), `block_timestamp` (transaction timing), `transaction_hash` (unique transaction identifier), `gas_used` and `effective_gas_price` (gas consumption data)

### Component B: Daily active user calculation  
- **Purpose**: Aggregate unique transaction senders by day to create daily active user counts
- **Logic**: Groups transaction data by day using timestamp truncation to daily boundaries. For each day, calculates distinct count of sender addresses (`from_address`) to identify unique users who initiated transactions. Each unique sender address on a given day represents one daily active user. Results maintain dimensional attributes including chain identifier, user type classification, and product categorization.
- **Key fields**: `timestamp` (daily boundary), `user_dau` (distinct daily active user address), `user_type` (classification as 'Transaction sender'), `chain` (Polygon network identifier)

### Component C: HyperLogLog sketch creation
- **Purpose**: Create probabilistic data structures for efficient distinct counting across time windows
- **Logic**: Transforms daily active user data into HyperLogLog sketches using precision level 15 for accurate distinct counting. Each day's unique user addresses are processed into HLL sketches that enable efficient merging and distinct counting operations. This approach handles large address volumes while maintaining counting accuracy across overlapping time periods. Sketches are grouped by timestamp, chain, user type, and product dimensions.
- **Key fields**: `hll` (HyperLogLog sketch of daily unique addresses), `timestamp_grain` (daily granularity marker), dimensional grouping fields

### Component D: Weekly sliding window creation
- **Purpose**: Build 7-day sliding windows for each day using datespine approach
- **Logic**: Creates a comprehensive datespine covering the full date range from earliest available data to current date. For each date in the spine, generates a 7-day window by creating join relationships with the previous 6 days plus the current day. This creates overlapping weekly cohorts where each day represents the end of a unique 7-day period. The datespine approach ensures no missing dates and handles gaps in source data systematically.
- **Key fields**: `timestamp` (window end date), `joinday` (each day within the 7-day window), window boundary definitions

### Component E: Weekly distinct address calculation
- **Purpose**: Calculate distinct weekly active addresses using HLL sketch merging
- **Logic**: Joins the sliding window structure with daily HLL sketches to create weekly address counts. For each 7-day window, merges HLL sketches from all 7 days using HLL merge operations, then extracts the final distinct count. This approach efficiently handles address overlaps across the week - if the same address was active on multiple days within the week, it counts only once in the weekly total. Processing handles multiple dimensional breakdowns simultaneously.
- **Key fields**: `user_wau` (weekly active user count), merged HLL sketches, dimensional breakdown fields

### Component F: Multi-dimensional breakdowns
- **Purpose**: Create different analytical perspectives of weekly active addresses
- **Logic**: Produces four distinct dimensional breakdowns of the weekly active address metric. Chain-level breakdown provides network-specific counts with chain identifier. Project-level breakdown aggregates across all dimensions for overall project metrics. User-type breakdown segments by transaction sender categories. Product-level breakdown provides product-specific active address counts. Each breakdown maintains timestamp and metric value while setting non-relevant dimensional fields to null.
- **Key fields**: `dimensions` (breakdown type identifier), `chain_id`, `product_id`, `user_type` (dimensional attributes), `user_wau` (weekly active count for each dimension)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a comprehensive dataset with multiple analytical perspectives of the same underlying weekly active address metric
- **Schema standardization**: Applies finalization macro processing to ensure consistent schema structure, data types, and field naming conventions across all dimensional breakdowns
- **Missing data handling**: Implements fill-with-zeros strategy for periods with no activity, ensuring continuous time series data without gaps
- **Final calculation**: Renames the `user_wau` field to `active_addresses_weekly` to match the target metric definition, applies chain availability filters to ensure data quality, and filters results to include only chain-level and project-level dimensional breakdowns for the final metric output

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

Unique active addresses over a rolling 7-day window.

PolygonPOL

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown