METHODOLOGY & DATA SOURCES

Overview

POLTRACK is a structural accounting layer for POL token mechanics, focused on deterministic and reproducible measurement of on-chain tokenomics. POL is the successor token to MATIC in Polygon's token migration, and legacy MATIC references are kept only where historical accounting still affects burn-adjusted supply. It operates against observable state on Ethereum mainnet (supply, emissions, mint, treasury) and Polygon PoS (native burn, chain activity), without relying on proprietary data or unverifiable assumptions. The objective is to produce canonical daily facts for each economic domain — supply, burn, fees, staking, and treasury — from which rolling metrics and derived ratios are computed in a traceable pipeline. All published figures reflect protocol-level mechanics as observable on-chain; market interpretation, valuation, and forecasting are explicitly outside scope.

Scope

What POLTRACK covers

What POLTRACK does not cover

• Price forecasting, valuation narratives, or trading recommendations.
• Full validator P&L (infrastructure cost side is not observable on-chain).
• Unverified wallet attribution.
• Multi-asset dashboards unrelated to POL tokenomics.

Data Collection by Domain

Each domain is collected from a specific public source, stored as raw snapshots, and then reconciled into canonical daily records. Here is where each piece of data comes from and how it is obtained.

Supply

Supply data comes from Etherscan (Ethereum mainnet), where the POL token contract state is queried daily. This gives us two direct on-chain values:

• Total supply — the raw token supply at the time of the snapshot.
• Staked supply — the POL balance held by the staking contract.

Two derived values are computed from these plus burn data:

• Net supply — total supply minus all tracked burn components, applied at read time.
• Burned total — cumulative sum across all burn components described below.

Burn

Burn is the most complex domain because POL tokens are removed from circulation through three distinct mechanisms across two chains. Each is tracked independently.

The end-of-day block for native burn is resolved through Etherscan's block-by-timestamp API, then the balance is fetched via a Polygon PoS archive RPC node. The daily delta formula is max(balance[day] − balance[day−1], 0) — if a snapshot is missing for a given day, that day is marked unavailable rather than filled with a spike.

Staking & Emissions

All emission data comes from Etherscan (Ethereum mainnet), specifically the ERC-20 transfer event logs originating from the POL emission manager contract (0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53). Every transfer from that contract is captured and classified by recipient address into one of four categories:

• staking_actual — transfers to the staking contract,
• treasury_actual — transfers to the community treasury,
• treasury_legacy — transfers to the legacy treasury safe,
• legacy_migration — transfers to the POL migrator contract,
• unknown — any recipient not matching the above.

This classification produces daily and cumulative emission totals per category, feeds the emission component of staking yield, and tracks minted-to-date progress against the declared 10-year allocation caps.

Fees & Chain Activity

Fee and activity data is sourced from GrowThePie, which publishes daily aggregates for Polygon PoS across four datasets: fees.json, txcount.json, throughput.json, and daa.json. These typically publish with a 1–2 day lag.

From these datasets POLTRACK ingests:

• Fees paid (USD) — gross fees paid by users on Polygon PoS per day.
• Transaction count — number of transactions per day.
• Gas throughput — reported by GrowThePie in Mgas/s, normalized to gas/s internally (gas_used_day = gas_per_second × 86,400).
• Active addresses — daily active addresses (DAA).

Gross fees are not reported as a single number. Instead, they are split into three protocol-defined allocation components — burn, staking rewards, and rebates — each tracked separately on a daily and 30-day rolling basis.

As of PIP-82 (Agentic Commerce Gas Program, published February 12, 2026), rebates are treated as a temporary incentive layer for public x402 facilitators. Program accounting is tracked against a fixed $1,000,000 budget and stops at the earlier of cap exhaustion or December 31, 2026.

Treasury

Treasury data comes from Etherscan (Ethereum mainnet) — ERC-20 transfer logs for the community treasury address (0x86380e136A3AaD5677A210Ad02713694c4E6a5b9) and the legacy treasury safe. Every transfer in or out is recorded with direction and amount.

Daily inflow, outflow, and netflow are aggregated from these raw transfers. The cumulative balance is recomputed from the earliest affected date forward on every ingestion run, which ensures correctness after a reorg or a historical backfill — no stale running totals can persist.

Price & Market

Price data comes from CoinGecko, which provides daily price (USD), market cap (USD), and market cap rank for POL. From these, POLTRACK derives two additional values:

• Security budget — staked supply × price, a measure of the economic cost to attack the network.
• Market cap fallback — if CoinGecko market cap is unavailable for a given day, circulating supply × price is used instead.

Protocol Constants

These are the fixed numerical references embedded in POLTRACK's calculation logic. They are derived from Polygon's official protocol specification and do not change unless the protocol itself changes.

Supply baseline

• Start date: 2023-10-25 (POL token genesis)
• Start supply: 10,000,000,000 POL
• Schedule duration: 10 years

Inflation schedule

The protocol defines a declining emission schedule split between two recipients — treasury and staking — applied as annual percentage rates on the current supply.

How allocation caps are derived

The declared caps are not fixed arbitrary numbers — they are computed by simulating compound emission growth over the full 10-year schedule. Each year, the mint amounts for treasury and staking are calculated as a percentage of the supply at the start of that year (which already includes the growth from prior years). This means the caps are slightly higher than a naive flat-rate estimate would suggest.

• Year 1: 10,000,000,000 POL → treasury mints 1%, staking mints 2%
• Year 2: supply after year 1 → treasury mints 1%, staking mints 1.5%
• Years 3–10: treasury mints 1%, staking mints 1% of the growing supply each year

The resulting declared caps over 10 years:

• Community Treasury max: 1,109,146,957 POL
• Staking Rewards max: 1,260,646,957 POL
• Combined max new issuance: ~2,369,293,914 POL
• Max expected supply (start + issuance): ~12,369,293,914 POL

POLTRACK verifies at runtime that these cap values are consistent with the schedule above.

Key on-chain addresses

All addresses below are treated as immutable protocol references by POLTRACK. They are the source of truth for attribution and recipient classification.

Ethereum mainnet:

Polygon PoS:

PIP-82 program constants

PIP-82 public facilitator allowlist (initial set):

• 0x29df60c005506AA325d7179F6e09eB4b4875dAde
• 0xF09A94831C18566781f70937f0996B96EfE691C8
• 0x42618f623Ec19beFf78dE9DbBFB653BfEaC05D09
• 0x3202643514D128FF0B4625D2682c0244CF58131c
• 0x11DA3fe5ADA6f5382Ebe972f14C3585DA4E65AeA
• 0x135DfE729F9bbd7F88181E1B708d7506fd499140
• 0xDcb0Ac359025dC0DB1e22e6d33F404e5c92A1564
• 0x99EFc08BB42282716fB59D221792f5207f714C9d
• 0xbE5115800247405f020197BF473eBFd085a2C635
• 0x5eAb3D78264Dab340340d6a37Ff0836464Ae5773
• 0xE5D4197eFd5D03E3f30cBf11C0fF63Eb95a0A656
• 0xfac8Edb989f1ba7F9dBb7A1233542D4e1fD6144F
• 0xaFdbfaCb5ed691bf0bCFA660901f299ce9775489
• 0x1e48Ed59a502D0B324CdAf83362865b3ff49ABa2
• 0xA1dcBDC2C34577ACD4A1152A98807B2f281A112e
• 0x9e281D4e26E1a4e7C27014E2ca8Cee7F2D44fa52
• 0x76FCb8ae3365A487E6EA235386C1cf3AbADeDA60
• 0x9523B120C75640469f1D16490Da0388928229452
• 0x153F3A70e4400c211d9B482b62aD721Bb02F96F6
• 0xd5dD012019C58882Dd507A8b3fCBB7b62e9a24c3
• 0xfff23108338C218F895d75980E14688218D4E92a
• 0xF744e153Ef63f7EEe4a58e0F13761D16C2125EE3
• 0x0a8B10FE8Bd3072351600Adef4796F3F7aF72Ab0
• 0x971b4079A618F72Fa0F1792b07ed5923dfBF3500

Methodological Principles

These principles govern how POLTRACK handles data quality, edge cases, and publication consistency. They exist to make the output trustworthy and reproducible — not just on good days, but especially when data is incomplete or sources misbehave.

• On-chain first. On-chain state is primary evidence. Third-party aggregates (fees, price) are supporting layers used where direct on-chain measurement is impractical, not authoritative replacements.
• Raw-to-canonical pipeline. Source data is always stored as-received before normalization. Rolling metrics are derived from canonical daily facts, not from raw inputs directly. This makes the pipeline auditable and replayable.
• Reward type separation. Inflationary rewards (emissions) and fee-based rewards (the staking rewards slice of fee allocation) are always tracked and reported as separate values. Combining them without distinction produces misleading yield figures.
• Null over fill. If a required input is missing or the coverage window is incomplete, the affected output is null — no interpolation, no zero-fill, no extrapolation. A missing data point is always preferable to a silently wrong one.
• Common as-of date. All sections of a published API response share one reference date: the latest date for which every required dataset is simultaneously available. This prevents cross-section distortion from mixed-date figures.
• Reorg buffer. Event-based ingestion (staking, mint, treasury) re-processes the last 64 blocks on each run to catch any chain reorganizations before they can silently corrupt cumulative totals.

How Metrics Are Calculated

The formulas below describe the conceptual logic behind each metric group. They are simplified for clarity and do not reflect internal implementation details.

Supply, issuance, and inflation

Circulating Supply and Net Supply are the same value in POLTRACK. Both refer to Total Supply − Burned Total. The term "Circulating Supply" is used in market and yield context; "Net Supply" is used in issuance and inflation context — but they resolve to the same number.

Net Supply = Total Supply − Burned Total
Circulating Supply = Net Supply  (identical, different label depending on context)
Net Issuance (day) = Emissions (day) − Native Burn (day)
Net Issuance (30d) = Sum of Net Issuance over last 30 days
Net Inflation Rate (annualized %) = (Net Issuance 30d / Circulating Supply) × (365 / 30) × 100

Note: Max Expected Supply is also burn-adjusted — (Start Supply + Treasury Cap + Staking Cap) − Burned Total — so the Issued % Of Max ratio reflects real remaining headroom, not gross schedule headroom.

Burn and fee mechanics

Native burn is measured as a balance delta:

Native Burn (day) = max(Cumulative Burn[t] − Cumulative Burn[t−1], 0)
Burn USD (day) = Native Burn POL (day) × Price USD (day)

Gross fees are split across three components (burn, staking rewards, rebates). Under PIP-82 accounting, rebates are measured from observed recycle settlements and then deducted from non-burn fees:

Non-Burn Fees USD (day) = max(Gross Fees USD (day) − Burn USD (day), 0)
Rebates USD (day) = Sum of eligible rebate settlements (day, USD)
Rebates POL (day) = Rebates USD (day) / Price USD (day)
Rewards From Fees USD (day) = max(Non-Burn Fees USD (day) − Rebates USD (day), 0)
Rewards From Fees POL (day) = Rewards From Fees USD (day) / Price USD (day)
Rebates USD (30d) = Sum(Rebates USD (day), last 30 days)
Rebates Program Used USD = Sum(Rebates USD (day), from program start to as-of date)
Rebates Program Remaining USD = max(1,000,000 − Rebates Program Used USD, 0)

When no eligible rebates are settled for a day, Rebates USD (day) is 0.

Staking yield

Staking yield is split into two components that are summed to give the total. The fee-based component uses only the staking rewards slice of fee allocation (fees - burn - rebates, as represented by rewards_from_fees) — not gross fees alone.

Staking Yield From Fees (%) = ((Staking Rewards From Fees POL 30d / 30) × 365 / Avg Staked POL 30d) × 100
Staking Yield From Emission (%) = ((Staking Emission POL 30d / 30) × 365 / Avg Staked POL 30d) × 100
Staking Yield Total (%) = Yield From Fees + Yield From Emission
Security Budget (USD) = Staked Supply POL × Price USD

On the dashboard this metric is presented as 30d Annualized Staking APR:

• It is a trailing 30-day run-rate annualized to one year.
• It is not a forward prediction model; it is a pace extrapolation.
• It is APR (linear annualization, no compounding), not compounded APY.

Supply cap progress

Issued % Of Max = Circulating Supply / Max Expected Supply × 100

Max Expected Supply is derived from the declared 10-year emission schedule described in the Protocol Constants section above.

Validator rewards framing

POLTRACK does not model full validator P&L. At the network allocation level, the conceptual framing is:

Validator Effective Revenue = Commission % × Distributed Rewards

Realized validator returns can differ from protocol-level flow due to payout timing, delegation mix, and operator commission policy.

Publication Pipeline

Data moves through four stages before reaching the dashboard:

1. Collect — source snapshots and events are fetched on a recurring schedule from Etherscan, Polygon RPC, GrowThePie, and CoinGecko.
2. Reconcile — raw data is normalized into canonical daily facts per domain (supply, burn, fees, staking, treasury, price).
3. Compute — rolling windows (30d), annualizations, and split metrics are derived from canonical facts.
4. Publish — a normalized API response is assembled, anchored to a common as-of date, with null outputs for any incomplete windows.

Validator Monitoring (beta)

The Validators section of POLTRACK provides per-validator analytics for the Polygon PoS validator set, focusing on PIP-65 fee redistribution, checkpoint rewards, and operator income. Data is sourced from on-chain events and stored in the POLTRACK database.

Data sources

Validator monitoring combines data from three on-chain sources:

Additional metadata (name, status, commission rate, delegation count, stake amounts) is fetched from the StakeManager and stored in core_validators.

PIP-65 fee redistribution

After the Rio hardfork (PIP-64/PIP-65, October 8 2025), block fees on Polygon PoS are redistributed monthly through the PIP-65 multisig in two pools:

• 74% validator pool — distributed pro-rata to active validators based on their delegated stake weight (Pv = stake_v / total_stake). This is the primary pool tracked in the validators dashboard.
• 26% block producer pool — directed to the Validator-Elected Block Producer (VEBloP) designated by validator governance.

Each distribution is recorded as a batch (core_pip65_batch) with individual payments per validator (core_pip65_payment). Batches are identified by their Polygon PoS block number and date.

Per-validator analytics

For each validator that has received at least one 74% pool payment, POLTRACK computes:

• Total PIP-65 income — sum of all 74% pool payments received across all batches.
• Pool share (%) — validator's total income as a percentage of the grand total across all validators.
• First share / Last share — the validator's share of the batch total in the first batch they appeared in, and in the most recent batch.
• Trend — a categorical label derived from the ratio of last share to first share:

ratio = last_share / first_share

surging:    ratio ≥ 1.5
growing:    ratio ≥ 1.1
stable:     ratio ≥ 0.9
declining:  ratio ≥ 0.5
collapsing: ratio < 0.5
new:        validator absent from first half of batches

Income model

For validators with reward period data, POLTRACK constructs a three-source income model:

Checkpoint Gross = Operator Bonus + Delegator Pool
  Operator Bonus = Δ(SM.validators[id].reward) + ClaimRewards events
  Delegator Pool = Δ(rewardPerShare) × totalSupply / 10²⁵  (ValidatorShare method)

PIP-65 Income = Sum of 74% pool payments (goes entirely to operator)

Total Operator Income = Operator Bonus + PIP-65 Income
  (commission on delegator pool is included in the checkpoint bonus)

Key accounting notes:

• SM.delegatorsReward is a per-checkpoint buffer, not a running total — the ValidatorShare method is used instead.
• validator.reward with 0% commission equals the checkpoint bonus (proposer + signer rewards), not a delegator fee.
• PIP-65 distributes native MATIC/POL (not ERC-20), so txlistinternal is the correct retrieval method.
• Monthly yield is computed as (total_operator_income / total_stake) × (365 / days_in_period) × 100.

Anomaly detection

POLTRACK automatically flags structural anomalies across the validator set. Each anomaly is data-driven and computed from the analytics described above:

Anomalies are sorted by severity (warning first), then by total income descending within each severity level.

Forecast

When a multisig snapshot is available (core_pip65_multisig_snapshot), POLTRACK displays a forecast for the next batch:

• Central estimate — the forecast_74pct_pol value from the snapshot, derived from the current multisig balance and daily fee accrual rate.
• Range — ±10% around the central estimate.
• Timing — expected distribution date based on historical batch cadence.

Forecasts are clearly marked as estimates and are not included in any aggregate totals.

Key on-chain addresses (Validators)

Limitations specific to validators

• Delegator yield approximation. The ValidatorShare method uses ts_start approximation for period boundaries, which may overstate delegator yield during periods of large stake exits.
• Signer address rotation. If a validator rotates its signer address, historical payments under the old address may not be automatically linked. Signer history is tracked where available but gaps can occur.
• PIP-65 batch lag. PIP-65 distributions lag approximately one month behind the fee collection period.
• Commission changes. Commission rate is recorded at snapshot time and may not reflect mid-period changes.

Limitations & Known Constraints

No data pipeline is perfect. These are the known constraints users and researchers should be aware of:

• Data lag. Chain activity and fee data from GrowThePie typically carries a 1–2 day lag. Price and market data from CoinGecko typically lags by up to 1 day. Native burn for the current (incomplete) day is available intraday but subject to revision until end-of-day.
• Third-party dependency risk. Explorer and market APIs can rate-limit, revise historical data, or fail temporarily. POLTRACK treats source failures as coverage gaps — affected outputs go null, not zero.
• On-chain anomalies. Unusual transfer clusters, migration events, or sparse event days can distort short rolling windows.
• Reorg and indexing effects. Near-head on-chain data can shift during block finalization or index refresh. The 64-block reorg buffer mitigates most cases, but very recent data should be treated as provisional.
• Validator payout reality vs protocol assignment. Protocol-level reward flow does not always equal immediate realized distribution at the validator or delegator level.

Versioning & Updates

This methodology is a living document. As POL token mechanics evolve and data coverage improves, formulas, source precedence, or category definitions may be updated. Any change that materially affects how a metric is calculated or how it compares to prior values will be documented explicitly here.

• Metric naming will be kept stable where possible.
• Meaningful definition changes will be clearly disclosed.
• Silent retroactive logic changes will be avoided.

Structured Summary (For Research & AI Parsing)

• Net Supply / Circulating Supply: these two terms are used interchangeably in POLTRACK and resolve to the same value: total supply − burned total. Burn-adjusted using all tracked burn components (native Polygon burn, POL zero-burn, legacy MATIC dead-burn).
• POL and MATIC relation: POL is the successor token to MATIC. Legacy MATIC appears only in historical components that still affect present accounting (for example, dead-burn balance tracking).
• Net Issuance: emissions minus native burn over a selected period.
• Net Inflation: net issuance relative to circulating supply, typically shown as a rolling 30-day annualized rate.
• Fee Allocation: gross fees split into three components — burn, staking rewards, and rebates — each tracked separately.
• Staking Yield Split: decomposition of staking yield into inflationary (emission-driven) and fee-based (rewards component of fee allocation) components.
• Inflationary rewards: emission-driven staking rewards from protocol inflation directed to the staking contract.
• Fee-based rewards: staking-side rewards funded by the protocol-defined rewards share of network fees.
• Rebates: protocol-defined fee rebates tracked separately from staking rewards; PIP-82 rebates are budget-tracked against a $1M cap through 2026-12-31.
• Security Budget: market value of staked POL (staked supply × price), published as a network security context metric.
• As-Of Date: all metrics in a given response share a single reference date anchored to the latest common availability across all required datasets.
• Data Basis: POLTRACK metrics are derived from observable on-chain state (Ethereum mainnet and Polygon PoS) and publicly verifiable data sources. Source coverage gaps produce null outputs, never synthetic fill values.
• PIP-65 Validator Fee Distribution: monthly redistribution of Polygon PoS block fees via the PIP-65 multisig — 74% to validators pro-rata by stake weight, 26% to the elected block producer.
• Validator Income Model: three-source decomposition — checkpoint operator bonus (Ethereum StakeManager), delegator pool yield (ValidatorShare rewardPerShare method), and PIP-65 fee payments (Polygon PoS native transfers).
• Validator Trend: categorical share movement label (surging/growing/stable/declining/collapsing/new) derived from first-to-last batch share ratio.
• Anomaly Detection: automated flagging of dominant validators (>10% share), surging/collapsing share trends, new entrants, exits, and missing batch gaps.

Transparency & Open Methodology

All metrics published by POLTRACK are derived exclusively from publicly accessible on-chain data and public data providers, as described in this document. The calculation logic, source attribution, and formula definitions are documented here to allow independent verification and replication. Any revision that materially affects metric definitions or comparability will be reflected in an explicit update to this document. Researchers, developers, and independent analysts are encouraged to cross-check outputs against the referenced primary sources.