# Polygon Transactions per second Methodology

## 1. Overview

Transactions per second (TPS) measures the average number of transactions processed by the Polygon blockchain per second over a daily period. This metric provides insight into network throughput and usage patterns by calculating the daily transaction volume divided by the number of seconds in a day (86,400). The metric helps assess blockchain performance, network congestion, and adoption trends.

## 2. Data sources

- **Polygon blockchain transactions**: Complete transaction records from the Polygon network including transaction hashes, block timestamps, from/to addresses, gas usage, and gas prices
- **Account labels database**: Curated labels and titles for Polygon addresses to identify known contracts, protocols, and services
- **Token metadata**: Reference data for WPOL (Wrapped Polygon) token address used for gas price calculations

## 3. Step-by-step calculation

### Component A: Raw transaction extraction
- **Purpose**: Extract all Polygon transactions with essential metadata and gas information
- **Logic**: Selects distinct transactions from Polygon blockchain data, capturing `transaction_hash`, `block_timestamp`, `from_address`, `to_address`, `receipt_gas_used`, and `receipt_effective_gas_price`. Gas prices are converted from wei to ETH by dividing by 10^18. Each transaction is classified under the 'blockchains_l1' market sector and 'blockchain' business segment. The WPOL token address is assigned as the reference token.
- **Key fields**: `transaction_hash` for unique identification, `block_timestamp` for temporal aggregation, `receipt_gas_used` and `receipt_effective_gas_price` for gas analysis

### Component B: Daily transaction aggregation
- **Purpose**: Count unique transactions per day grouped by destination address
- **Logic**: Aggregates transactions using daily timestamp truncation of `block_timestamp`. Counts distinct `transaction_hash` values to ensure no duplicates are included in the count. Groups results by day, chain identifier, market sector, business segment, and `to_address`. This creates a daily transaction count broken down by receiving address.
- **Key fields**: `timestamp` (truncated to day), `transaction_count` (distinct count of hashes), `to_address` for grouping

### Component C: Account label enrichment
- **Purpose**: Enrich transaction counts with human-readable contract names
- **Logic**: Performs a left join between daily transaction counts and the account labels dimension table using `to_address` and `account_address`. Assigns contract titles where available, defaulting to 'Unlabeled' for addresses without known labels. This helps categorize transactions by destination type (known protocols vs unknown addresses).
- **Key fields**: `contract_name` derived from account titles, maintaining all original transaction count fields

### Component D: Transaction count finalization
- **Purpose**: Standardize the schema and ensure data completeness
- **Logic**: Applies the `finalize_metric_transaction_count` macro to validate identifiers, ensure consistent schema structure, and fill gaps in the time series with zero values where no transactions occurred. The fill strategy uses 'fill_zeros' to maintain continuous daily data.
- **Key fields**: Standardized metric schema with validated `chain_id`, `product_id`, and other dimension fields

### Final aggregation
- **Combining components**: The transaction count data is aggregated by summing `transaction_count` across all destination addresses for each day, providing total daily transaction volume
- **Currency conversion**: No currency conversion required as this is a count-based metric
- **Time aggregation**: Data is maintained at daily granularity with timestamp boundaries set at day truncation
- **Final calculation**: Transactions per second is calculated by dividing the daily transaction count by 86,400 (the number of seconds in a day) using a safe division function to handle potential zero denominators. The `finalize_metric_transactions_per_second` macro ensures consistent schema and fills any gaps with zero values for continuous time series data.

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

Average confirmed user transactions added per second.

Transactions per second

Polygon

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.

Polygon POL

Transactions per second

Transactions per second

Competitive landscape

Chain breakdown