Methodology & Data Sources

This page is the technical reference for POLTRACK metrics. It documents source hierarchy, formulas, constants, limitations, and reconciliation rules. For the plain-language explanation of POL as the native gas and staking token of Polygon PoS, start with the Polygon POL Token FAQ. Broader guides cover POL Tokenomics, POL Burn, and Polygon Chain Fees.

Provenance policy. POLTRACK is independent from Polygon Labs and the Polygon Foundation. Protocol facts are checked against official Polygon documentation, published PIPs, relevant Polygon governance forum records, public Polygon source code and contracts, verified transactions, and direct on-chain state. POLTRACK then normalizes those primary inputs and publishes its own calculations and explanations. Proposals, executed protocol behavior, observed data, and POLTRACK-derived metrics are labeled separately.

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 validator profit after operating expenses.

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:

• on-chain POL supply;
• staking contract balance and validator/delegation state where available;
• native Polygon Chain burn collector balance;
• POL zero-address balance;
• POL dead-address balance on Ethereum;
• 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, POL dead-burn, and legacy MATIC dead-burn are measured on Ethereum. Daily permanent burn is the change in their combined cumulative balance, so a cross-chain transfer from the Polygon collector to the Ethereum dead address is not counted twice.

Burn Classification

The dashboard term Permanent burn is retained for balances already received by approved burn components. It does not assert that every component uses an ERC-20 _burn() call or immediately 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;
• any separately assumed PIP-25 amount not represented by an observed POL balance change at the dead address;
• 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 includes its confirmed balance in the historical burn component of the Burn Adjustment 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 Value Flow view. For Total Supply, POLTRACK instead measures Base Fees accrued toward burn directly from blocks, less observed rebates, so settlement timing does not create artificial supply jumps.

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, Total Supply Change, or Total 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. POLTRACK derives its current supply metrics 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. Value Flow reports the latest 30-calendar-day mint total and its recipient split.

Treasury balances and Treasury flows currently have different published perimeters. They must not be combined into a purported complete opening-balance + inflow - outflow reconciliation.

The current balance inventory includes these tracked addresses and assets:

For the Polygon Charm vault at 0xB788D3bcCeE934648bf670971b47F0Bf7CbE06F2, POLTRACK attributes WPOL (token0) and sPOL (token1) from getTotalAmounts() in proportion to vault shares owned by the Liquidity Safe. The vault shares themselves are not added again as a separate asset value:

Treasury vault underlying[asset]
  = vault.getTotalAmounts()[asset] × Treasury vault shares / vault.totalSupply()

POL balance
  = direct Ethereum POL + direct Polygon native POL + direct Polygon WPOL
  + Treasury vault WPOL underlying

sPOL holdings
  = direct Ethereum sPOL + direct Polygon sPOLChild
  + Treasury vault sPOL underlying

sPOL POL equivalent = sPOLController.convertSPOLtoPOL(sPOL holdings)

Ethereum quantities and sPOL conversion use one pinned Ethereum block; Polygon balances and vault positions use one pinned Polygon block. The two chains have separate cutoffs and are not assumed to share an identical timestamp. The balance snapshot records those block references. Assets outside the listed inventory, general bridge escrow, and underlying assets held by sPOL's staking/controller contracts are not added independently. POL balance is therefore not an exclusively liquid-POL cash balance: it includes WPOL and the attributed vault position. Converting or staking POL, wrapping it, bridging it, or moving it between included addresses is not by itself external revenue or an ecosystem expense. A valuation change is not a transfer.

The flow series remains the legacy Ethereum POL transfer perimeter: the Community Treasury address and Legacy Safe above. inflowPol and outflowPol are address-level transfer activity for that scope, not complete external income and spending for the expanded cross-chain inventory. Transfers within the two-address perimeter can appear on both sides; transfers to execution Safes, bridge routes or staking positions are not classified as final external expenses by these fields. The series does not measure all Polygon flows, vault deposits/withdrawals, or sPOL earnings. Historical zero flow is not evidence of zero activity outside that perimeter.

The API discloses these separately in treasury.scope: expanded balance version treasury-crosschain-inventory-v2 with scoped_inventory_snapshot coverage, and flow version treasury-ethereum-flows-v1 with legacy_account_transfer_scope_only coverage. ethereumBlock, polygonBlock, the balance dates, and meta.sourceTimestamps describe the cutoffs. These coverage labels identify the measured perimeter; they are not attestations that the legacy flow history is complete. Use the scope attached to the actual response, including an explicitly labeled legacy_balance_snapshot_only fallback if the expanded snapshot is unavailable. Current balances can be newer than the closed daily flow cutoff. A complete expanded Treasury flow reconstruction remains outside this dataset's present claim.

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.

sPOL Liquid Staking

The POL Token section reads global sPOL state from the Ethereum sPOL token and controller contracts. Total supply comes from sPOL.totalSupply(). Its POL equivalent and the displayed redemption rate are evaluated at the same pinned Ethereum block:

sPOL POL equivalent = sPOLController.convertSPOLtoPOL(sPOL.totalSupply())
sPOL/POL redemption rate = sPOL POL equivalent / sPOL total supply

Holder counts are reported independently for Ethereum sPOL and Polygon Chain sPOLChild. For each contract, POLTRACK indexes every non-zero address observed in Transfer logs, reads each current balanceOf at a pinned block, and counts positive balances. A snapshot is rejected unless the sum of all indexed balances exactly equals that contract's totalSupply().

The dashboard does not add the two counts or deduplicate addresses across chains. The same hexadecimal address can therefore appear once in each network count. These metrics describe positive-balance on-chain addresses, including contracts and multisigs where applicable; they are not estimates of unique people or beneficial owners.

Observed sPOL return uses daily pinned-block redemption-rate snapshots. On initial collection, POLTRACK backfills 31 UTC end-of-day snapshots and then updates daily. The historical point closest to 30 days before the latest block timestamp is used. Let d be the exact elapsed time between the two blocks in days, and r the observed redemption-rate return as a decimal:

r = latest redemption rate / baseline redemption rate - 1
Observed window return (%) = r × 100
Simple annualized APR (%) = r × 365 / d × 100
Compound annualized APY equivalent (%) = ((1 + r)^(365 / d) - 1) × 100

The API's observedApr30dPct and aprWindowDays retain the simple annualization and exact window. The dashboard shows the observed window return and its compound APY equivalent derived from those same inputs. The visible window label is rounded to whole days; calculations use the unrounded duration. APY assumes the observed rate of growth continues for a year. It is not an observed one-year yield, an advertised rate, or a forecast. These redemption-based metrics exclude gas costs and any secondary-market premium or discount to the on-chain redemption rate. The separate network staking yield is an emission-funded APR, before validator commission; PIP-85 fee modeling is inactive and excluded.

Core Formulas

Supply

On-chain Supply = canonical POL contract supply state

Burn Adjustment
= confirmed historical burn through 2025-12-31
+ Polygon Base Fees accrued toward burn from 2026-01-01, net of confirmed rebates

Total Supply = On-chain Supply - Burn Adjustment

Unmigrated MATIC
= MATIC totalSupply
- MATIC held by the migration contract
- MATIC held by the known dead address

Estimated Liquid Supply
= Total Supply
- staked POL
- unclaimed staking rewards
- unmigrated MATIC (1:1 POL equivalent)

Total Supply is POLTRACK's headline current supply metric. On-chain Supply exposes the contract-state input before the external Burn Adjustment. The adjustment includes confirmed historical burn and protocol Base Fees already accrued toward burn. Because some Base Fees settle through routing contracts later, the adjustment can be ahead of the balance shown as Permanent Burn. POLTRACK does not present a separate market-float or locked-token estimate as circulating supply.

The MATIC-to-POL migration started on October 25, 2023 and operates 1:1. Dead-address MATIC is excluded from the unmigrated balance because it is already included in permanent burn; subtracting it again would understate liquid supply. Unclaimed rewards use the latest complete weekly network snapshot.

The Supply graph extends the observed history to October 25, 2033 so users can inspect a dated supply path under explicit assumptions:

Scenario on-chain supply(t)
= observed on-chain supply at asOf × 1.02^(UTC days since asOf / 365)

Total supply under the 2033 scenario
= scenario on-chain supply - current Burn Adjustment - projected future Base Fee accrual

This calculation belongs only to the projected portion of the Supply graph. It is not a current supply definition, protocol limit, target, or claim about supply after that date.

The dashboard supply chart applies an additional assumption to the future leg. It starts with the on-chain emission path above, subtracts the Burn Adjustment measured at the chart's as-of date, and then subtracts future Base Fee accrual at a constant trailing 90-calendar-day average:

scenario future burn = trailing 90d average Base Fee burn × future calendar days
scenario total supply = scenario on-chain supply - current Burn Adjustment - scenario future burn

The average is recalculated daily from Base Fee accrual, not from routing-wallet transfers. PIP-82 settlements and routing-wallet movements are not inputs to this chart scenario. The result is a constant-current-pace scenario, not a claim that future network activity or burn will remain unchanged.

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 definition is being compared. POLTRACK Total Supply, contract-state supply, and a provider-specific circulating-supply estimate are not interchangeable.

Total Supply Change

Total Supply Change = minted POL - Base Fees accrued toward burn

Positive Total Supply Change means Total Supply increased over the period. A negative value means Base Fees accrued toward burn exceeded minting over the same period.

The dashboard's 30d Supply Change card uses the effective-supply view rather than settlement-timed permanent burn:

30d Total Supply Change = 30d minted POL - 30d Base Fees accrued toward burn

This keeps the mint and Base Fee inputs on the same 30-calendar-day window. Routing-wallet transfers can settle in batches, so their timing does not define the period's supply change. The already-settled Permanent Burn balance remains a separate Value Flow metric.

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

As of September 10, 2026, PIP-85 staker fee sharing is inactive in POLTRACK. It is not modeled, displayed, or included in staking APR, charts, or scenario allocations. Displayed network staking APR uses emission funding only:

APR from emission = annualized staking emission / average staked POL
Displayed staking APR = APR from emission

This is an annualized funding run rate before validator commission, not a guaranteed realized APY. Activity and POL-price scenarios do not change this APR; the inflation input does.

The former fee model is preserved for reference only and is not calculated by the frontend:

Inactive reference fee APR = annualized staker fee share / average staked POL
Inactive reference combined APR = emission APR + fee APR

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. POLTRACK labels the priority-fee routing-wallet balance Awaiting distribution and does not count it as distributed until an outgoing batch is observed and classified. The PIP-85 percentages above are retained specification parameters. Staker fee modeling is inactive in POLTRACK and requires a separate activation change before it can operate in the product.

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 distinguishes the executed contract timeline from the validator-reward policy calendar:

Executed mainnet history records 3% from October 2023, 2.5% from the July 2024 implementation switch, and the current 2% curve from the July 2025 switch. The latest 30-calendar-day treasury and staking mint flows are reported from on-chain events.

The declared schedule is compounded on the growing supply base:

on-chain supply path = start supply + treasury emission + staking/validator emission
total supply change = observed minted POL - observed Base Fees accrued toward burn

Observed on-chain mint events and Base Fee accrual define actual issuance, recipient classification, and Total Supply Change. The future calculation used by the Supply graph is documented only in the Supply section above and remains separate from current metrics.

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 Chain:

Validator Methodology

The Polygon Validators product combines validator registry data, checkpoint/performance signals, stake and delegator data, commission, tags, and PIP-65 fee payment history.

Validator monitoring combines:

Daily validator state is read through public contract methods such as validators(id), totalSupply(), exchangeRate(), and rewardPerShare() at one Ethereum block. POLTRACK does not rely on private storage offsets for current snapshots because proxy implementation upgrades can change storage layout assumptions. A snapshot is rejected before publication if aggregate active stake is zero, too few active validators decode, or any expected ValidatorShare getter response is missing.

ValidatorShare balances are shares. POLTRACK derives delegated POL from StakeManager's public delegated amount and monitors exchangeRate(). At the August 1, 2026 verification block, all 105 active ValidatorShare contracts were exactly 1:1, but the semantic distinction remains explicit so a future slash cannot silently overstate stake.

POLTRACK Score v5 uses seven components:

Stake Momentum uses only snapshots where own stake plus delegated stake is non-zero. Fewer than two valid observations produce a neutral component with low confidence rather than a fabricated zero-change history.

Decentralization uses holder-address concentration only when the scan is fresh, marked verified, and reconciles at least 99.9% of outstanding ValidatorShare supply. When delegated supply exists below that threshold, the result is a neutral component and an explicit Incomplete Holder Coverage profile label; total stake remains available, but POLTRACK does not publish confident address-concentration claims. A self-stake-only validator with zero ValidatorShare supply has no delegated holder set and is not classified as incomplete. HHI and holder shares describe observed addresses, not guaranteed beneficial ownership.

Score confidence is high with at least 80 valid history observations and a usable holder state, medium with at least 30 observations and a fresh holder scan, and low otherwise. A usable holder state means verified coverage for outstanding delegated supply, or a verified absence of delegated supply. Neutral component defaults express insufficient evidence rather than favorable or unfavorable performance.

The score is a comparison aid, not an endorsement. Public bands are Excellent (90-100), Strong (75-89), Standard (60-74), Low (40-59), and Very Low (0-39). These are score tiers rather than security-risk declarations; operational signals are reported separately.

Public score history is version-scoped. A new formula version starts a new comparable series instead of being appended to older scores with different thresholds or missing-data behavior.

Validator Earnings And Network Security Spend

POLTRACK calculates monthly validator economics from January 1, 2026. The model separates two questions that must reconcile to the same total:

For validator v in calendar month m:

operator earnings[v,m]
  = staking operator income[v,m]
  + PIP-65 validator-pool income[v,m]
  + block-producer pool allocation[v,m]

For the network:

validator operators earned[m] = sum(operator earnings[v,m])
stakers earned[m] = staking reward pool[m] - sum(staking operator income[v,m])

network security spend[m]
  = validator operators earned[m] + stakers earned[m]
  = staking reward pool[m] + total priority-fee distributions[m]

Staking commission is a split of the staking reward pool, not an additional funding source. Priority-fee income is operator revenue in this model and is not reduced by a validator's staking commission rate.

Staking operator income

Monthly staking accrual uses a half-open block interval (start block, end block]. POLTRACK reads the validator reward accumulator immediately before the period and at the final block inside the period, then includes ClaimRewards amounts observed inside the same interval. This avoids losing rewards when a validator claims during the month and the accumulator resets.

Daily validator snapshots preserve stake and commission changes within the period. A commission_changed flag is retained when more than one commission rate is observed. Rows are published only when their quality state is complete enough for operator revenue.

For standard on-chain validator economics, the measured validator-side accrued reward is operator staking income. For operators whose 100% on-chain commission is part of an exchange, custodial, or internal distribution product, POLTRACK does not treat the full on-chain reward as operator revenue. It applies a documented time-bounded staking service-fee rate:

staking operator income = relevant accrued staking rewards × documented service-fee rate

Such rows are marked as estimates. The model records effective dates and confidence so a policy change does not silently rewrite unrelated months.

Priority-fee income and block producers

Observed PIP-65 validator-pool transfers are attributed directly to the receiving validator. The producer pool is handled separately. For each producer-pool batch, POLTRACK selects the producer membership valid on the batch date and allocates the pool using normalized membership weights:

producer allocation[v,batch]
  = producer pool[batch] × weight[v,batch] / sum(active producer weights[batch])

The profile audit trail distinguishes a direct validator distribution from a calculated block-producer allocation. Producer Safe routing transfers are retained as an audit trail but are not automatically treated as validator identity evidence.

Calendar-month presentation

The current calendar month is recomputed as new snapshots, rewards, claims, and payout batches arrive. It is labeled Preliminary and shown in the current-period summary. Historical network and validator charts include closed calendar months only. This prevents a partial month from being visually compared with a complete month.

PIP-65 batch dates can lag the fee-generation dates. Monthly priority-fee earnings therefore follow the realized or attributed batch date, not a synthetic smoothing of fees back across the collection period.

Interpretation limits

• Operator earnings are revenue estimates, not profit. Infrastructure, engineering, security, compliance, tax, and other costs are not deducted.
• On-chain addresses do not always reveal beneficial ownership or internal customer accounting.
• A documented service-fee rate can differ from the on-chain commission field; POLTRACK uses the economic model applicable to the operator and period.
• Producer allocations depend on the best verified time-bounded producer membership available for each batch.
• Values are intended for network and operator comparison and are not accounting statements.

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.
• Aggregate all-zero validator snapshot runs are quarantined rather than interpreted as stable stake. A getter-verified zero-stake state for one validator remains valid history but is excluded from Stake Momentum.
• Holder concentration requires fresh, verified 99.9% supply coverage.
• 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.

Polygon Tokenomics Simulator

The interactive simulator in Polygon Tokenomics is a separate deterministic sensitivity layer over the canonical live dataset. It does not write modeled values back to canonical tables, public snapshots, or historical series.

Its three independent inputs are network activity, POL price, and annual inflation. Activity scales transactions and USD fees; price converts those fixed USD fee flows into POL; inflation changes protocol issuance and the emission-derived staking APR. The long-term burn leg starts from the same trailing 90-calendar-day Base Fee rate used by the live supply scenario.

The complete formulas, control ranges, zero-supply behavior, and limitations are documented in Polygon Tokenomics Simulator.

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.
• ValidatorShare holder addresses can represent wrappers, custodians, or pooled ownership; address concentration is not identical to beneficial-owner concentration.
• PIP-65 batch dates are not always the same as the fee collection period.
• PIP-85 staker/delegator fee modeling is inactive and not included in the frontend. Public claimer or payout artifacts and an explicit product activation are required before enabling this path.
• 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
• Snapshot manifest

JSON, CSV, and the companion manifest are generated from one cached source response and share a publication timestamp and snapshotId. The manifest supplies the CSV's headline source periods, units, field definitions, source metadata, calculation policy versions, and SHA-256 checksums for both data files. CSV columns and existing JSON version 2.0 fields remain compatible. Empty CSV values correspond to JSON null.

The files contain the latest published snapshot rather than a historical archive. Save the manifest together with the data and verify its checksums; retry the download if a daily refresh separated the requests. The file schema version is distinct from source calculation-policy versions, and generatedAt is distinct from the observation cutoff and any live market timestamps. 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
• Polygon Developer Docs: sPOL
• 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
• sPOL 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.

The canonical API publishes calculation identities in policy.metricDefinitions and versions in policy.versions. Compatibility field names are retained; use their accompanying formula and basis rather than inferring meaning from a short field name. Current explicit calculation versions include:

meta.asOf identifies the closed daily accounting cutoff. meta.sourceTimestamps separately identifies newer live observations and the dates of slower source snapshots; an older required snapshot is not relabeled as a new observation. meta.build identifies a code release, not a data revision. The public snapshot schema version and manifest version likewise describe file formats, not economic formulas.