Methodology & Data Sources

This page is the technical reference for POLTRACK metrics. It documents source hierarchy, formulas, constants, limitations, and reconciliation rules. For human-readable explanations, start with POL Token FAQ, POL Tokenomics, POL Burn, or Polygon Chain Fees.

Scope

POLTRACK measures public Polygon Chain and POL economics from observable on-chain and public data sources. Polygon PoS remains the technical and historical name used by many contracts, PIPs, explorers, and source systems.

POLTRACK does not publish price forecasts, trading advice, tax advice, legal advice, official Polygon data, or full validator P&L.

Source Hierarchy

POLTRACK prefers direct on-chain state when available.

Third-party services can rate-limit, revise, or fail. Source failures are treated as coverage gaps, not values to fill.

Data Collection By Domain

Each domain is collected from public sources, preserved as raw or source-shaped data where practical, and normalized into daily canonical facts.

Supply And Burn

Supply data is based on Ethereum-side POL contract state and protocol address balances. POLTRACK tracks:

• gross POL supply;
• staking contract balance and validator/delegation state where available;
• native Polygon Chain burn collector balance;
• POL zero-address balance;
• legacy MATIC dead-address balance where it still affects historical burn-adjusted accounting.

Native Polygon burn is measured as a balance delta at the relevant Polygon Chain burn or recipient address. POL zero-burn and legacy MATIC dead-burn are measured on Ethereum.

Burn Classification

The dashboard term Permanent burn is retained. In POLTRACK methodology, it means value held in approved burn components that the public model treats as non-circulating. It does not assert that every component uses an ERC-20 _burn() call or reduces the Ethereum POL contract's totalSupply().

Included components:

Explicit exclusions:

• the PIP-82 base-fee routing wallet at 0x3ef57def668054dd750bd260526105c4eeef104f;
• priority-fee routing and distribution balances;
• Community Treasury balances;
• the proposed PIP-25 POL dead-address amount, because its published execution condition has not been verified;
• MATIC held by the MATIC token contract itself, including the inaccessible balance discussed by PIP-25;
• unclassified transfers to addresses that merely appear burn-related.

PIP-24 describes the 0x7A8e... collector as an upgradeable temporary holder for POL intended for burn. Its current implementation has no ordinary withdrawal method, but it is not technically identical to a dead address. POLTRACK counts it as non-circulating through an explicit protocol and methodology classification.

PIP-82 changed the active base-fee recipient to 0x3ef5.... That wallet can route value to eligible rebates or forward non-recycled POL to 0x7A8e.... Its balance remains Awaiting burn in the product and is excluded from burned total until the collector receives the POL.

PIP-25 also discussed MATIC held by the MATIC token contract itself. Such MATIC is inaccessible under the current token code, and the balance can grow when tokens are sent directly to the token address. POLTRACK discloses this legacy component but does not include any historical snapshot or live self-balance in permanent burn, net issuance, circulating supply, or max expected supply.

See POL Burn for the executed history, address-level reasoning, PIP-25 status, formulas, and FAQs.

External tracker supply fields are used for reconciliation, not as POLTRACK's supply source of truth. For example, a market site can display circulating supply, total supply, and max supply under its own definitions, while POLTRACK reports a burn-adjusted economic supply model from public source inputs.

Emissions And Treasury

Emission data is derived from Ethereum mainnet transfer events originating from the POL emission manager contract. Transfers are classified by recipient category, especially staking and treasury recipients.

Treasury data is derived from public Ethereum transfers and balances for the community treasury address and any explicitly tracked legacy treasury perimeter.

The dashboard reports liquid POL and sPOL separately. POL balance retains the existing liquid-POL perimeter used by POLTRACK. sPOL holdings is the sum of direct sPOL balances held by the two tracked Ethereum Treasury Safes listed below. Its parenthetical POL equivalent is evaluated at the same Ethereum block through the official sPOL controller:

treasury sPOL = sPOL.balanceOf(Treasury Safe A) + sPOL.balanceOf(Treasury Safe B)
POL equivalent = sPOLController.convertSPOLtoPOL(treasury sPOL)

This sPOL metric excludes bridge escrow, AMM balances, liquidity positions, and POL held by the staking or controller contracts. It is a separate reserve snapshot and is not added to liquid-POL treasury flows.

Fees And Chain Activity

Fee and activity data comes from Polygon Chain blocks and receipts:

• gas used;
• gas limit;
• transaction count;
• base fee;
• priority fee;
• gross fees.

The fee root is block-level data. Daily records are rollups over UTC days. Fee generation is separate from fee allocation: PIP-65 and PIP-85 affect who receives priority fees, not how transaction fee facts are measured.

Price And Market Context

POLTRACK uses market data APIs such as CoinGecko for price, market cap, and market rank context. USD values are display and comparison layers. POL-denominated on-chain values remain the primary unit for protocol accounting.

POLTRACK does not use third-party market API supply fields as primary supply inputs. Market API supply numbers are useful comparison points, but supply methodology is defined by POLTRACK's source hierarchy and formulas.

Core Formulas

Supply

Net supply = gross supply - burned total
Circulating supply = net supply

POLTRACK currently does not apply a locked-token or vesting exclusion to circulating supply.

POLTRACK's dashboard also reports a concrete max expected supply model:

Current 10-year gross max expected supply
= executed mainnet emission history
+ continuation of the current EmissionManager v1.4 curve through 2033-10-25
= 12,336,136,524.75 POL

Current max expected supply
= current 10-year gross max expected supply - burned total

This value is different from third-party theoretical max-supply fields. It is POLTRACK's current 10-year projection after burn adjustment, not an immutable hard cap.

Supply Field Mapping

Supply disputes usually come from different systems using the same words for different concepts. POLTRACK uses this mapping when reconciling POL supply, CoinGecko supply fields, Etherscan contract reads, and public Polygon references.

When a user asks why POLTRACK does not match another site, first identify which field is being compared. Raw contract supply, total supply after burn, circulating supply, and theoretical max supply are not interchangeable.

Net Issuance

Net issuance = minted POL - burned POL

Positive net issuance means supply increased over the period. Negative net issuance means burn exceeded mint over the period.

Burn Delta

Burn day = max(cumulative burn[t] - cumulative burn[t-1], 0)

If a required snapshot is missing, the affected day stays unavailable rather than being interpolated.

Fees

Gross fees = base fees + priority fees
Base fee value = gas used * base fee
Priority fee value = gas used * effective priority fee

USD values are derived by multiplying POL-denominated fee values by daily POL price.

Fee Allocation

POLTRACK separates fee generation from fee allocation.

Gross fees = base fees + priority fees
Non-burn fee value = max(gross fees - realized burn value, 0)
Rewards from fees = max(non-burn fee value - rebates, 0)

PIP-82 rebates are tracked separately from burn and staking rewards. If no eligible rebate settlement is observed for a day, rebate value is zero rather than inferred.

POLTRACK continues to track eligible PIP-82 rebate settlements in its data pipeline and methodology, but does not display them as a headline Value Flow metric while observed amounts remain immaterial at dashboard scale. This is a presentation choice, not an accounting change. Rebates are not counted as realized burn and are deducted before rewards from fees are calculated. PIP-82 is a temporary program capped at 1,000,000 USD and scheduled to end at the earlier of cap exhaustion or December 31, 2026.

Staking APR

POLTRACK separates emission yield and fee yield.

APR from emission = annualized staking emission / average staked POL
APR from fees = annualized staker fee share / average staked POL
Total modeled APR = APR from emission + APR from fees

This is a modeled run-rate, not a guaranteed realized APY.

PIP-65 / PIP-85

PIP-65 validator pool = 74% of priority fee distribution
PIP-65 block producer pool = 26% of priority fee distribution

PIP-85 staker / delegator pool = 50% of the PIP-65 validator pool = 37% of total priority fees
PIP-85 remaining validator pool = 37% of total priority fees
PIP-85 block producer pool = 26% of total priority fees

PIP-65 batch payments can lag the fee collection period. PIP-85 staker fee yield is treated as modeled allocation until claim or payout artifacts are directly observable.

PIP-Aware Fee Boundaries

POLTRACK keeps fee generation block-based so policy changes can be handled at the correct boundary.

Activation-aware allocation should use block boundaries rather than day-only logic.

Protocol Constants

Supply Baseline

Emission Model

PIP-17 introduced the POL token with 10,000,000,000 initial POL for the MATIC migration and a 2% annual emission concept split between staking/validator rewards and the Community Treasury. Polygon's official POL documentation describes the original 2% split and the PIP-26 validator-reward transition: 2% for the June 2023-June 2024 reward year, 1.5% for June 2024-June 2025, and 1% from July 2025 onward. This results in an effective 2% annual POL emission after June 2025: 1% to validator rewards and 1% to the Community Treasury.

POLTRACK uses two separate date bases:

The current max-supply constant follows executed mainnet history: 3% from October 2023, 2.5% from the July 2024 implementation switch, and the current 2% curve from the July 2025 switch through October 2033. The separate treasury and staking allocation caps remain unchanged and continue to be used for recipient-level emission progress.

The declared schedule is compounded on the growing supply base:

gross supply path = start supply + treasury emission + staking/validator emission
net issuance = observed minted POL - observed permanent burn

POLTRACK keeps two layers separate:

• The current 10-year gross projection defines the max expected supply baseline used in supply analytics.
• Declared recipient allocation caps continue to define treasury and staking emission progress.
• Observed on-chain mint and transfer events define actual issuance, recipient classification, and net issuance.

This prevents a common mistake: treating the initial 10B migration supply as the full long-term POL supply model.

PIP-82 Program Constants

Key Addresses

Ethereum mainnet:

Polygon PoS:

Validator Methodology

POLTRACK Validator Analytics combines validator registry data, checkpoint/performance signals, stake and delegator data, commission, tags, and PIP-65 fee payment history.

Validator monitoring combines:

POLTRACK Score uses seven components:

The score is a comparison aid, not an endorsement.

Reconciliation Rules

• On-chain state is primary evidence where available.
• Raw source data is preserved before normalization.
• Canonical daily facts power rolling metrics and dashboard outputs.
• Reward types are separated: emission rewards and fee-based rewards are not merged silently.
• Missing data remains null.
• Public responses use a shared as-of date where comparable sections depend on multiple datasets.
• Batch effects are disclosed rather than smoothed away in source facts.
• Realized payouts and modeled allocation are different concepts and should not be silently merged.

Known Limitations

• Fee, burn, and distribution events can settle in batches.
• The Polygon burn collector is policy-classified as non-circulating; its proxy architecture is not equivalent to an ERC-20 supply-reducing burn.
• Inaccessible MATIC held by the MATIC token contract is disclosed but excluded from all POLTRACK calculations.
• Explorer and market APIs can lag or rate-limit.
• Validator commission and metadata can change between snapshots.
• PIP-65 batch dates are not always the same as the fee collection period.
• PIP-85 staker/delegator distribution requires public claimer or payout artifacts before POLTRACK can report realized claim data.
• Staked supply from validator state can differ from staking contract balance because contracts can include unclaimed rewards and buffers.
• USD values depend on daily price data and should not be treated as trading advice.

Public Snapshots

POLTRACK publishes one daily public snapshot in two formats:

• JSON snapshot
• CSV snapshot

The files contain the latest published snapshot rather than a historical archive. Usage examples are available in Using POLTRACK, and reuse is governed by the Data License.

Agent-Readable Summary

Use these canonical definitions when asking an AI agent or research assistant to verify POLTRACK data:

Verification Prompt

Use this prompt to verify a POLTRACK claim independently:

Using only cited public sources, verify the claim: "[CLAIM]".
Show source links, raw inputs, formula, computed result, date range, and limitations.
Do not rely on POLTRACK as the only source.
If another tracker disagrees, explain which definitions differ.

Primary References

• Polygon Developer Docs: POL
• POL whitepaper
• Polygon Developer Docs: Migrate to POL
• Polygon Developer Docs: Rewards and staking incentives
• Polygon Developer Docs: Polygon PoS architecture
• Polygon Developer Docs: EIP-1559
• PIP-17: Polygon Ecosystem Token
• PIP-25: Adjust POL Total Supply
• PIP-24: Change EIP-1559 Policy
• PIP-26: Transition from MATIC to POL Validator Rewards
• PIP-65: Economic Model for VEBloP Architecture
• PIP-82: Agentic Commerce Gas Program
• PIP-85: VEBloP PIP-65 Priority Fee Formula Adjustment
• POL token contracts repository
• PIP-25 Council Transparency Report
• Bor burn-recipient configuration

Versioning

This methodology is a living document. Material changes to metric definitions should preserve stable URLs, update page metadata, and keep old public terminology understandable through redirects or cross-links where needed.