Methodology & Data Sources

This page documents the current methodology used by POLTRACK to calculate and present its metrics. It distinguishes current balances, historical accounting series, period flows, observed rewards, and modeled estimates. The implementation and published source coverage determine what each value means.

POLTRACK is independent from Polygon Labs and the Polygon Foundation. Direct contract state, executed transactions, block data, and receipts provide measurement evidence. Official documentation, public contract code, and Polygon Improvement Proposals explain protocol roles; a proposal alone does not establish that a transfer or reward occurred. For broader protocol context, see POL Tokenomics, POL Burn, and the Polygon POL Token FAQ.

Data Sources

POL is the gas and staking token of Polygon Chain, also called Polygon PoS in contracts and source systems. Accounting uses POL unless a field explicitly identifies MATIC, sPOL, shares, wei, USD, or a percentage. POL and legacy MATIC use a 1:1 migration equivalence in the named supply adjustments; they are not added together as two independent network supplies.

Observed values come directly from source state or events. Derived values follow stated arithmetic. Estimated / modeled values depend on a policy classification, incomplete coverage, or a scenario assumption. A value derived from an estimate retains that limitation.

Endpoints And Observation Cutoffs

The website exposes canonical economics, staking data, POL Value data, and the 2026 report. The economics response publishes meta, policy, and data; page-specific responses add the observations needed for their product.

meta.asOf is the closed UTC accounting cutoff selected from the availability of required canonical datasets and ingestion progress, capped at yesterday. Closed sections are read in a database snapshot. This provides a coherent database read, not an atomic observation of both chains. Live market data, current validator state, network-supply balances, Treasury inventory, and routing balances can have different observation dates. Their dates are exposed separately in meta.sourceTimestamps and section fields.

A 30-calendar-day flow window includes asOf - 29 days through asOf. A reward-index return compares closing observations approximately 30 elapsed days apart. Those conventions share a cutoff but are not interchangeable sets of samples. Read the metric's own window and block timestamps.

The complete own-canon daily economics boundary is January 1, 2026. Earlier supply points remain inputs to the currently displayed historical supply series. API field names and file-schema versions are compatibility identifiers; formulas, source dates, coverage, and calculation-policy versions specify the actual basis.

Contract And Address Perimeters

Ethereum mainnet:

Polygon Chain:

A matching hexadecimal Safe address on the two chains has separate balances and transfer histories. Treasury inventory addresses are specified in the issuance section below.

POL Supply

Current Total Supply And Burn Adjustment

On-chain Supply is gross Ethereum POL totalSupply() before POLTRACK's external exclusions. Ethereum supply collection pins contract supply, bridge escrow, burn-address balances, and migration balances to one Ethereum block. The primary collector uses direct RPC; the supply job retains an explorer-source fallback.

Total Supply is the current burn-pipeline-adjusted network supply. It partitions the gross contract supply between Ethereum and bridge-backed Polygon Chain, excluding each tracked burn-pipeline balance once:

Ethereum allocation
  = gross Ethereum POL totalSupply
  - Polygon PoS bridge escrow
  - Ethereum POL zero balance
  - Ethereum POL dead balance
  - legacy MATIC dead balance

Polygon Chain allocation
  = Polygon PoS bridge escrow
  - Polygon burn collector balance
  - Polygon burn routing-wallet balance

Total Supply = Ethereum allocation + Polygon Chain allocation
Burn Adjustment = On-chain Supply - Total Supply
                = POL zero + POL dead + MATIC dead
                + Polygon collector + Polygon routing wallet

The bridge escrow is backing for the Polygon partition, not an additional supply to add on top of gross Ethereum supply. The legacy MATIC dead balance is carried as a 1:1 POL-equivalent adjustment.

The latest Ethereum supply snapshot with bridge data supplies networkSupplyDate. Polygon collector and routing inputs are the latest available records at or before that date. This is a common date ceiling; the two chains are not sampled at an identical instant or block. Each input must be finite and non-negative, escrow cannot exceed gross supply, collector plus routing cannot exceed escrow, and neither partition may be negative. An invalid or missing required input prevents publication of the two network allocations.

Current fallback: when the network allocation cannot be calculated, totalSupplyPol and burnAdjustmentPol fall back to the latest available accrual-based historical supply point described below. onChainSupplyPol falls back to the closed canonical gross-supply state. Ethereum/Polygon partition fields remain unavailable. If neither supply basis exists, the adjusted fields remain unavailable. A legacy zero default in the gross-supply field is not evidence that observed supply was zero. Use the partition availability and source dates to assess the basis of a particular response; a policy description alone does not prove that all primary inputs were available.

Historical Supply Series

The displayed historical series intentionally uses a different accounting basis from the current network-balance snapshot. It answers how supply evolved after fees were accrued toward burn, without waiting for routing settlement.

For dates from January 1, 2026:

Historical burn baseline
  = last available pre-2026 Polygon collector balance
  + last available pre-2026 Ethereum POL zero balance
  + last available pre-2026 Ethereum POL dead balance
  + 28,048,948.737848055 legacy MATIC dead POL-equivalent

Daily net base-fee accrual = max(base fees POL - confirmed rebates POL, 0)
Cumulative accrual(t) = sum(daily net base-fee accrual from 2026-01-01 through t)
Historical Burn Adjustment(t) = historical burn baseline + cumulative accrual(t)
Historical Total Supply(t) = closed gross supply(t) - historical Burn Adjustment(t)

The fixed legacy MATIC component is the December 31, 2025 Ethereum block 24,136,052 balance. Other baseline components are resolved independently from their last available pre-boundary observations; absent components currently default to zero. Earlier series points use the historical canonical permanent-burn state. This boundary is necessary to explain the series currently displayed, not a separate obsolete methodology.

The accrual query reads canonical daily fee facts and confirmed rebate facts. Missing rebate events default to zero. It does not independently require every cumulative input day to pass the publishable-day view, so chart availability alone is not proof of complete historical fee coverage. The current snapshot and this series can differ because of cutoffs, rebates, source coverage, and settlement timing. They are not two interchangeable definitions of the same current snapshot.

Historical annualized supply-change points compare the closing historical supply with the latest available point at or before 30 days earlier and use the actual elapsed days. They are distinct from the flow-based headline card below.

Estimated Liquid Supply

Unmigrated MATIC = max(MATIC totalSupply - migrator MATIC balance - MATIC dead balance, 0)

Estimated Liquid Supply
  = max(Total Supply - active-validator staked POL
        - unclaimed staking rewards - unmigrated MATIC POL-equivalent, 0)

Staked POL is own stake plus delegated stake of active validators, not the POL token balance of StakeManager. Unclaimed rewards use the latest coverage-qualified complete snapshot at or before the accounting cutoff. Unmigrated MATIC likewise uses its latest eligible cutoff snapshot. Dead-address MATIC is removed from unmigrated MATIC because the supply adjustment already excludes it.

The unclaimed-reward collector reads StakeManager.validatorReward(id) and ValidatorShare.getLiquidRewards(wallet) for discovered eligible positions at one Ethereum block, 12 blocks behind the observed head. It retries failed calls and requires successful calls for the selected set, coverage of every eligible validator, topology no older than 35 days, and at least 99% aggregate share coverage. Consequently, the published complete status is a collection-quality gate, not proof that every possible undiscovered legacy position is included.

The liquid-supply result is unavailable if any required quantity is missing. Inputs can have different ages: current supply and stake may be newer than the unclaimed snapshot. This is an accounting estimate for the named reserves, not exchange float, a census of all locked tokens, or a market-provider circulating-supply figure.

Total Supply Change

The headline 30D metric is a period flow calculation:

Issued POL(30D) = emission-recipient inflows over the 30-calendar-day window
Net base-fee accrual(30D) = max(sum(base fees POL) - sum(confirmed rebates POL), 0)
Total Supply Change(30D) = issued POL(30D) - net base-fee accrual(30D)
Inferred opening supply = current Total Supply - Total Supply Change(30D)
Supply change percent = Total Supply Change / inferred opening supply × 100
Simple annualized supply change percent = supply change percent × 365 / 30

The fee leg requires 30 dated, non-null daily fee records. The issuance leg uses the canonical emission-recipient dataset, including its classified recipient categories; it is not a fabricated smooth daily emission curve. Positive change means issuance exceeded net accrual; negative change means the reverse. The percentage denominator is inferred from the current supply and period flow, rather than measured as a pair of current-network balance snapshots.

POL Value applies the same economic flow concept over its selected calendar window, using the sum of daily max(base fees - rebates, 0). The headline 30D API clamps after summing the window. Those expressions can differ if a day's confirmed rebates exceed that day's base fees. Routing settlement and increases in Permanent Burn do not define this period change.

Supply Scenarios

The future segment of the Tokenomics supply chart is modeled separately:

Projected gross supply(t) = observed gross supply × (1 + annual issuance rate)^(UTC days / 365)
Projected net supply(t) = max(projected gross supply(t)
                             - current Burn Adjustment - projected future net base-fee accrual, 0)

The default annual issuance rate is 2%. Future accrual extends the trailing 90-calendar-day average of the historical cumulative net base-fee accrual, using actual elapsed days and the earliest available baseline if the full lookback is unavailable. No rate can be calculated from an insufficient baseline. The current gross supply and adjustment anchor the scenario at the accounting asOf date even when their source snapshots are newer.

The interactive simulator scales activity, holds observed 30D USD fees per transaction and fee mix constant, converts those USD flows at the selected POL price, and scales future burn accordingly. Selected inflation changes modeled issuance and the emission-funding APR. The projected supply floor is zero. October 25, 2033 is a chart horizon, not an automatic contract emission stop or a supply cap. See Tokenomics Simulator for the controls and sensitivity formulas.

POL Burn

Permanent Burn is the sum of policy-classified balances received by four tracked components: Polygon native burn collector, Ethereum POL zero address, Ethereum POL dead address, and Ethereum legacy MATIC dead address. The term describes POLTRACK's exclusion policy; it does not assert that every component executes an ERC-20 supply-reducing burn.

The base-fee routing wallet is excluded from Permanent Burn but included in the current Burn Adjustment as an in-flight burn-pipeline balance. Priority-fee balances, Treasury assets, unclassified addresses, and MATIC held by the MATIC token contract itself are excluded. No additional PIP-25 amount is assumed without an observed included balance.

The collector is an upgradeable temporary holder designated for burn, not technically an irreversible dead address. An ERC-20 supply reduction is observed in contract totalSupply(); holding or transferring tokens into these policy-classified components can instead reduce POLTRACK adjusted supply without reducing gross contract supply.

Balance Changes And Settlement

Period burn uses recorded changes in the tracked component balances. The API computes successive deltas for each component, excludes its first observation because it has no predecessor, and sums the signed deltas on their observation dates. YTD sums these deltas from January 1; the 30D distribution series uses the same recorded-delta basis. A missing recorded delta in the generated distribution date spine currently defaults to zero. These fields therefore do not guarantee a fresh, complete observation of all four components on every day, and sparse observation changes fall on the next observed date.

A collector-to-Ethereum dead-address settlement moves previously excluded tokens. When the bridge, collector, and dead-address legs have been observed, their changes offset; it must not be counted as a second network supply reduction. Different sampling times can temporarily misalign those legs. A routing-to-collector transfer increases the Permanent Burn classification while leaving current burn-pipeline-adjusted Total Supply unchanged. Neither settlement amount is added again to base-fee accrual.

Polygon closed-day balance collection validates the block at or before the UTC day end, its successor, and recorded block references. Ethereum supply reads are pinned to one block but are not automatically the finalized-block observations used by the reward benchmark. Balance, accrual, and irreversible destruction are separate concepts.

Confirmed Rebates

The base-fee routing collector records outbound transfers and distinguishes burn sweeps, operational transfers, and rebate candidates. Only rebate-classified transfers to the configured facilitator allowlist enter confirmed rebate totals. Unverified recipients remain outside those totals. Routing-wallet balance changes alone do not prove a rebate or a new burn.

Confirmed rebates reduce the named net base-fee accrual calculations; days without a confirmed rebate default to zero. Program cap and end-date metadata describe the current PIP-82 collection scope, not an assumption that the cap has been spent. Rebates do not create staking rewards.

POL Issuance

Actual minting is observed from Ethereum POL Transfer events with the zero address as sender. Separately, transfers from the emission manager are classified into staking and Treasury recipient flows. Gross mint evidence and recipient funding answer different questions and can have different event timing.

The currently active emission curve is 2% annual compounded issuance, active since July 9, 2025, with a 50/50 staking/Treasury target split. Observed period values come from executed events, not the daily fraction of that declared curve. Contract minting and allocation can occur in batches.

Staking flows include the canonical staking_actual and legacy_migration categories; Treasury flows include treasury_actual and treasury_legacy. The headline 30D total sums emission-recipient inflows, while the product's recipient breakdown sums those named categories. Missing event-day values in the generated recipient spine are treated as no observed event and default to zero; missing source coverage is a separate limitation. A funding transfer is not evidence that a staker earned or claimed the same amount that day.

Emissions And Treasury

Treasury balances and Treasury flows have different published perimeters. They cannot form a complete opening-balance plus inflow minus outflow reconciliation.

For Charm vault 0xB788D3bcCeE934648bf670971b47F0Bf7CbE06F2, WPOL (token0) and sPOL (token1) are attributed in proportion to shares owned by the Liquidity Safe:

Attributed vault underlying[asset] = vault.getTotalAmounts()[asset]
                                    × Treasury vault shares / vault.totalSupply()
POL balance = Ethereum POL + Polygon native POL + Polygon WPOL + attributed vault WPOL
sPOL holdings = Ethereum sPOL + Polygon sPOLChild + attributed vault sPOL
sPOL POL equivalent = controller.convertSPOLtoPOL(sPOL holdings)

Vault shares are not valued a second time. Ethereum assets and sPOL conversion share one pinned Ethereum block; Polygon assets and vault positions share a separate pinned Polygon block. Unlisted assets, general bridge backing, and sPOL controller/staking underlying are not added independently. The POL balance includes WPOL and vault assets and is not an exclusively liquid cash balance. Internal transfers, bridging, wrapping, staking, and valuation changes are not by themselves external revenue or expenditure.

The flow series covers Ethereum POL transfers at Community Treasury and Legacy Safe only. Transfers between those accounts can appear on both sides. Transfers to execution Safes or staking/bridge routes are not automatically classified as final external spending. Polygon transactions, vault flows, and sPOL earnings are outside that flow perimeter.

treasury.scope identifies treasury-crosschain-inventory-v2 balance inventory and treasury-ethereum-flows-v1 legacy account-transfer scope. If the expanded balance is unavailable, the API falls back to the latest legacy POL balance and labels it legacy_balance_snapshot_only; missing expanded assets are not invented. Block references, balance dates, and source timestamps identify the actual cutoff. A scope label defines the perimeter, not independently proven complete transfer history.

POL Staking

Headline Staking APR

The headline APR on POL Staking and POL Value is the observed 30D rewardPerStake benchmark before validator commission. It is not an emission-funding ratio or a percentage allocation of priority fees.

The collector reads the deployed Ethereum StakeManager's reward index at actual finalized blocks. For the closed benchmark, both endpoints must fall in the final minute of their UTC closing days: the canonical economics asOf day and 30 UTC days earlier.

Observed reward return = (closing rewardPerStake - opening rewardPerStake) / 1e25
Elapsed days = (closing block timestamp - opening block timestamp) / 86400
Observed staking APR (%) = observed reward return × 365 / elapsed days × 100

The scale is 1e25. Exact timestamps, block references, cutoff, and window are retained with the benchmark. A missing closing endpoint or a decreasing/reset reward index within the measurement window makes the benchmark unavailable. No interpolation, emission-based APR, or modeled fee APR replaces it.

StakeManager allocates the separate proposer bonus before increasing this index. The benchmark excludes that bonus and precedes commission. Annualization is simple and assumes no reinvestment; it is not a realized one-year return or a cash payout ledger for every delegator.

History points use verified reward-index observations and actual elapsed time. Where an exact closed benchmark is unavailable, chart history can use a baseline at least 30 days earlier, with a maximum 33-day elapsed window, subject to the reset guard. The page's data-loading fallback is the website API proxy and then bundled audited historical observations, retaining their original dates. A historical fallback does not become a fresh observation and cannot produce a current headline benchmark without the required closes.

Commission And Individual Delegator Return

Commission is the validator's share of staking rewards. Pinned daily validator snapshots retain the contract rate. The subsequent metadata sync updates the current directory's core_validators.commission_rate from the public staking API, normalized to a 0–1 fraction; that field is therefore not guaranteed to be the same pinned-block observation as the stake snapshot. If the API update fails, the stored rate can remain last-known. Applying benchmark × (1 - commission fraction) is an indicative before-cost delegator comparison only when the same participation and commission assumptions hold.

Individual returns also depend on missed checkpoints, validator participation, proposer treatment, commission changes, deposits/withdrawals, claim timing, and transaction costs. The network benchmark does not reconstruct every position's net cash return. Monthly operator revenue uses period reward observations and claims rather than simply multiplying the network APR by a closing stake balance.

Funding, Earned Rewards, And Reward-Pool Balance

Priority-fee funding requires the exact Safe-to-StakeManager transfer pair. The scanner starts from Ethereum block 26,000,000, uses a 32-block confirmation lag and a 64-block rescan window, and deduplicates event identities. This confirmation policy is distinct from the finalized-block tag used for APR observations. Other Safe outflows remain unclassified rather than being silently attributed to staking.

POL Staking funding cards sum issuance and fee-funding inflows over their labeled 30D, 90D, or YTD UTC windows. POL Value dates the Stakers allocation by the observed transfer within its cutoff. Polygon Chain's Fee Distribution view separates 30-day StakeManager funding, validator payments and producer-Safe allocations. Validator payments use the separately classified validator batch total; producer-Safe allocations use the combined PIP-65 batch total less that validator total. The tracked batch source contains these two categories. Missing or inconsistent totals remain unavailable. StakeManager funding and producer-Safe allocations describe destination funding, not individual earned or claimable rewards.

Funding affects the observed APR only when the reward index subsequently accrues rewards. It is never added directly to index growth, operator earnings, or a second staker allocation when later claims/restakes occur. Once funds enter the shared StakeManager balance, POLTRACK cannot identify the remaining fee-funded portion from that balance alone. The fee-pool balance is unavailable and shown as a dash. A period funding total and the monthly period-accrual field described under Validators are flows, not this balance.

API Funding Estimates

Canonical economics still returns separate modeled allocation fields: aprFromEmissionPct, aprFromFeesPct, and aprTotalPct, marked rewardSemantic: modeled_allocation. Their current calculation is:

Emission funding APR (%) = 30D staking-recipient inflows / average daily staked POL × 365 / 30 × 100
Modeled fee APR (%) = 0.37 × 30D eligible priority fees / average daily staked POL × 365 / 30 × 100
Modeled total APR = emission funding APR + modeled fee APR, when both are available

The fee eligibility calculation uses Polygon block 85,245,000 and later. On the activation day, it measures eligible blocks with the necessary coverage rather than prorating a whole day's fees by a calendar assumption. The emission estimate requires a complete 30D stake window and observed emission input; the fee estimate additionally requires complete eligible fee-day coverage. When the fee input is unavailable, the retained total can contain the emission estimate alone.

The 37% factor is an assumption implemented in this API model, not verification that exactly 37% was transferred, remained in the pool, or was earned by stakers. It is not added to confirmed funding or the headline reward-index APR. Tokenomics' simulator uses the separate emission-funding estimate; POL Staking and POL Value use the observed benchmark. Consumers must select the field matching their question rather than treating every field named APR as the same metric.

sPOL Liquid Staking

Global sPOL state comes from its Ethereum token and controller at one pinned block, with a 32-block head lag:

sPOL supply = sPOL.totalSupply()
Backing in POL = controller.convertSPOLtoPOL(sPOL supply)
Redemption rate = backing in POL / sPOL supply

Ethereum sPOL and Polygon sPOLChild holder counts are collected independently. Transfer-log discovery supplies the address set; pinned-block balanceOf reads count positive balances. The sum of indexed balances must exactly equal each contract's total supply or the snapshot is rejected. Counts include contracts and multisigs, are not added or deduplicated across chains, and do not estimate unique people.

Daily pinned-block redemption snapshots include a 31-day end-of-day backfill at initial collection. The yield baseline is the earlier available snapshot closest in block timestamp to 30 days before the latest observation; it is not interpolated. The actual elapsed window can differ from 30 days.

r = latest redemption rate / baseline redemption rate - 1
d = exact elapsed block time in days
Observed window return (%) = r × 100
Simple APR (%) = r × 365 / d × 100
Compound APY equivalent (%) = ((1 + r)^(365 / d) - 1) × 100

observedApr30dPct and aprWindowDays retain simple annualization and the exact duration. The interface derives APY from the same inputs; rounding the displayed day label does not change the calculation. Redemption-rate growth already reflects the effects of validator commission, sPOL reward fees, and restaking. It excludes gas costs and secondary-market premiums/discounts. APY extrapolates observed growth and is not an observed one-year yield or a forecast.

A failed collection retains the last successful snapshot with its date. Missing/invalid supply, rate, or baseline makes the affected result unavailable; the native staking APR is not substituted for sPOL yield. Net rewards change redeemable POL per sPOL rather than automatically increasing a wallet's token count.

Supply-Adjusted Holding And Staking Returns

POL Value measures changes in token ownership share, before price movements:

Holding period return H = opening Total Supply / closing Total Supply - 1
30D reward return R = observed staking APR / 100 × 30 / 365
Staking period return = (1 + R) × (1 + H) - 1
Simple annualized return = period return × 365 / calendar days × 100

Opening and closing supply use the accrual-based historical series at the exact selected boundary dates where available. Closing supply falls back to current Total Supply; opening supply falls back to closing supply minus the period net change. These fallbacks retain the snapshot/series limitations already described.

Staking return is available only for a 30D selection with a reward benchmark whose cutoff matches economics asOf. Other period selections do not substitute an emission-funding APR. Rewards are normalized to the same 30 calendar days as the supply effect while their exact observed timestamps remain in the benchmark. These are before-commission, supply-adjusted token returns, not USD profit or consumer-price-adjusted purchasing-power returns.

Network Fees

Block And Receipt Calculation

For each Polygon block, fee measurement uses its header and transaction receipts:

Base fees (wei) = block gasUsed × block baseFeePerGas
Priority fees (wei) = sum(receipt gasUsed × (receipt effectiveGasPrice - block baseFeePerGas))
Gross fees = base fees + priority fees
POL amounts = wei amounts / 1e18

Receipt validation checks transaction/block identity, receipt ordering, cumulative gas, total receipt gas against the block header, and effective gas price against base fee. Invalid or incomplete receipt input does not become a verified block. Policy routing changes who receives fees; they do not change this fee-generation identity.

UTC daily facts sum blocks in [00:00, next 00:00). Canonical publishable views require closed-day block coverage. Receipt/hash verification is reported separately: legacy rows can have complete block coverage without the newer receipt/hash verification status. Read those coverage fields rather than interpreting complete as universal receipt verification.

Aggregation And USD Valuation

Daily fees POL = sum(block fees POL)
Daily transactions = sum(block transaction counts)
Daily fees USD = daily fees POL × daily CoinGecko POL price
Average fee per transaction = sum(fees) / sum(transactions)
Gas throughput = daily gasUsed / 86400 / 1e6   [MGas/s]

Daily base gwei is the unweighted average of block base fees. Daily priority gwei is total priority fees divided by total gas used, converted to gwei. Daily gas utilization is the average block gas-used/gas-limit ratio; average block time uses elapsed time between first and last sampled block divided by block count - 1. These weighting rules differ; they are not all transaction-weighted averages.

Rolling 30D totals use the closed calendar window, daily averages divide by 30, and fee per transaction divides summed fee value by summed transaction count. Missing daily prices prevent complete historical USD totals while POL amounts can remain available. The latest closed-hour live fee view has its own timestamp and current price and is not part of the closed-day annual report.

Historical USD fees and payouts use each day's price. Some POL Value period cards and allocation-chart values convert their already-summed POL flows at the latest live price. Those are current-price equivalents, not historical realized-dollar sums. Provider market capitalization likewise remains the provider field, not automatically POLTRACK Total Supply multiplied by price.

Fee Distribution

Fee generation, routing-wallet balances, and paid allocations are separate datasets. Priority-fee rewards in the distribution series are observed classified payout batches, dated by payment/settlement date. Pending Safe balances are Awaiting distribution, not distributed revenue. No residual gross fees - permanent burn calculation replaces actual payout evidence.

PIP-65 supplies the 26% producer-pool and 74% validator-pool categories used to classify batches. Direct validator distributions and producer-pool transfers are recorded separately. POL Value period cards use the detailed split when it reconciles with canonical batch totals within 0.0001 POL. A 30D fallback uses the published validator total and residual producer share; other periods do not invent a split. Separate confirmed StakeManager funding follows the Ethereum transfer dataset described above, not a modeled percentage of generated priority fees.

The cumulative allocation chart uses a different reconciliation tolerance: less than 0.1% relative mismatch between detailed and canonical batch totals. It scales reconciled detailed splits to the canonical total. If the detailed split is unavailable, producer/validator categories are not asserted as measured allocations. Payment timing can lag the fee-generation window; payments are not redistributed backward across fee days.

POL Value Capture

POL Value compares generated fees, burn accrual, issuance, allocations, and supply effects over the selected period. Its 24H selection means the latest closed UTC day; 7D, 30D, and 90D are closed calendar windows, and YTD starts January 1. Complete fee and distribution date windows are required for the period model. Sparse issuance events within an existing spine default to zero; a missing calendar row is different from no event.

Holder revenue in period cards is net base-fee accrual toward burn, sum(max(daily base fees - confirmed rebates, 0)). It is a burn-based value-capture measure, not a cash dividend, a right to receive fees, or a transfer to passive wallets. New issuance can outweigh this accrual, which is why net supply change and supply-adjusted returns are presented separately.

The YTD cumulative allocation chart's POL Holders series currently sums gross base fees without deducting rebates. Its label describes base fees accrued toward burn. It must not be read as the same net holder-revenue field used by the period cards. The chart's Staking Pool series sums staking issuance flows, not StakeManager balance or reward-index earnings; Stakers sums confirmed priority-fee funding. Treasury sums classified Treasury issuance. These are allocation flows, not recipients' realized profit.

Current Permanent Burn and Awaiting burn describe stocks at observation dates; period burn deltas and net base-fee accrual describe different stages of flow. Moving a token inside the excluded burn pipeline does not create a second supply reduction. Similarly, adding pool inflows to earned rewards would double-count funding and accrual. POLTRACK does not claim a consolidated cash-flow identity across different observation and settlement periods.

Validators

State, Stake, And Performance

StakeManager and ValidatorShare public getters provide own stake, delegated stake, status, snapshot commission, share state, and reward context at a named Ethereum block. The sync quality gate rejects aggregate all-zero active stake, insufficient decoded validator coverage, or missing expected getter responses before transactional publication. A verified zero-stake state for an individual validator remains valid evidence. Current directory commission is subsequently updated from the staking API as described above; it is not protected by the same pinned-block publication boundary.

ValidatorShare balances are shares; current delegated POL uses public staking state, and exchange-rate observations preserve the distinction if share value changes. StakeManager's token balance includes rewards and buffers and is not the active principal stake total. Validator metadata and checkpoint/performance context come from the public staking API; failed sources can leave last-known state with its recorded timestamp.

The directory's 30D stake-change metric compares delegated POL with the latest eligible calendar snapshot at or before 30 days earlier. It is not the Score Momentum observation-count window below. Delegator and holder counts describe on-chain positions/addresses, which can represent wrappers or custodians rather than individual beneficial owners.

POLTRACK Score

Some validator profiles retain this score in a supporting identity section. It is not used to order the current validator list or comparison. The retained v5 calculation is a weighted comparison on a 0–100 scale:

Score = round(sum(component score × component weight), 2)

Components are clamped to 0–100. Commission's current-rate score is (1 - commission fraction)^1.5 × 100. Momentum combines growth scores from up to 30/90 valid observations and an outflow penalty; these are observation counts, not guaranteed complete calendar-day windows. Only non-zero total-stake snapshots enter its history. Record's operating age is an estimate from activation epoch using a fixed epoch-duration conversion, not an exact activation transaction timestamp. Transparency and operator-type tags are metadata classifications, not ownership verification.

Holder concentration uses reconciled address shares: HHI = sum(address share fractions squared). A usable positive-supply holder scan must be fresh within 10 days, marked verified, and reconcile at least 99.9% of ValidatorShare supply. Insufficient coverage produces neutral Decentralization 50 and an incomplete-holder label, not a favorable concentration claim. A verified zero delegated supply has no holder set and is not classified as incomplete; its concentration component is neutral.

Confidence is high with at least 80 valid history observations and usable holder state, medium with at least 30 observations and a fresh holder scan, and low otherwise. The history count uses the larger available valid commission/delegated-history count. Neutral defaults indicate insufficient evidence. Bands are Excellent ≥90, Strong ≥75, Standard ≥60, Low ≥40, and Very Low <40. Score history is version-scoped. These comparison labels are not security guarantees or endorsements.

Validator Earnings And Network Security Spend

Monthly economics combine period staking accrual with observed direct priority-fee payouts and calculated producer allocations:

Operator earnings[v] = staking operator income[v]
                       + direct validator-pool income[v] + producer allocation[v]
Operators earned = sum(operator earnings for published covered rows)
Stakers earned = period accrued staking rewards - sum(staking operator income)
Network security spend = period accrued staking rewards + direct/allocated priority distributions
                      = operators earned + stakers earned

The compatibility field staking_reward_pool_pol here means period accrued staking rewards, not the current POL balance of StakeManager. Reward accumulators do not separately establish whether the earned amount was originally funded by issuance or priority fees. The current product's Inflation label for this component is therefore a source-attribution limitation; the arithmetic above describes the measured components.

Staking accrual uses the half-open Ethereum block interval (start, end]. Validator accrued rewards include ending-minus-opening liquid reward state plus observed ClaimRewards in the interval. Delegator accrual uses ValidatorShare reward-per-share growth against opening share supply plus the measured change in the delegator reward buffer. These are period accrual calculations, not incoming pool transfers.

Rows retain coverage/calculation quality. Insufficient legacy delegator coverage can publish an operator-complete row without complete network delegator accrual. A negative/reset validator boundary is conservatively floored rather than treated as a negative operator payment. Aggregates sum the rows eligible for publication, so they are not an attestation of full network coverage merely because a total is present. Commission changes are retained as period quality context.

Standard operator staking income uses measured validator-side accrued rewards. For custodial/exchange models with documented customer redistribution, a time-bounded service-fee estimate can replace treating all on-chain rewards as operator income. The current model selects the applicable rate at the period boundary; it does not reconstruct daily customer cash flows or prorate every intra-month policy change. Such rows are estimates, not profit after operating costs.

Direct validator-pool payouts are attributed to the receiving validator. Producer-pool allocations use verified time-valid membership and normalized weights:

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

A calculated allocation is distinguished from a direct payment. Safe routing does not by itself prove beneficial operator identity. Batch dates can lag collection dates; monthly income follows the realized/attributed batch date. The current month is Preliminary, while historical revenue charts use closed months. Service-fee assumptions, archive coverage, and membership quality remain limitations of the estimates.

Annual Report

The 2026 report reads canonical daily Polygon facts for that calendar year, excludes the current UTC day, and requires the date to be publishable under block-coverage rules. Required fee, activity, gas, and daily-price fields must be finite and non-null. Duplicate dates are rejected. Missing dates are not filled with estimated transactions or fees.

Monthly, quarterly, and YTD transactions and fees are sums of included days. Historical USD totals sum each day's POL fees multiplied by that day's price. USD per transaction is total USD fees divided by total transactions, not an average of daily fee-per-transaction ratios. Monthly base gwei, priority gwei, and utilization averages use included daily values with equal daily weight; quarterly base/priority gwei uses the same daily-weighted basis.

A month is complete only when all calendar days are present. An open or incomplete month reports its observed days; a closed quarter requires its three complete months. YTD includes the observed current partial month without projecting it to month end. Future chart slots are unavailable rather than zero activity.

The report has its own latest eligible-day cutoff, which can differ from the minimum-source economics cutoff. Event annotations are curated context, not statistical attribution of a fee change to that event. A failed report request is not silently replaced with invented figures.

Data Quality And Limitations

• Read source timestamps and section cutoffs. Fresh market or inventory observations do not refresh an older reward, migration, or unclaimed snapshot.
• Completeness is metric-specific: complete block coverage, receipt/hash verification, discovered-holder reconciliation, unclaimed call coverage, and operator-complete reward history are different guarantees.
• Sparse event spines use zero for no recorded issuance, rebate, payout, or component delta. Required fee inputs, benchmark closes, and liquid-supply reserves use availability checks. A zero default is not universal proof of a complete source scan.
• Current supply can fall back to the historical accrual basis; Treasury can fall back to the legacy balance scope; staking history can retain audited older observations. These fallbacks preserve their original dates and limitations.
• Burn settlement, fee generation, payout batches, funding, accrual, and claims can occur in different periods. Their totals must not be combined as though they were synchronized cash transfers.
• The burn collector and routing exclusion are policy classifications, distinct from irreversible ERC-20 supply destruction.
• Address counts and concentration do not identify every beneficial owner. Validator scores, service-fee models, and producer allocations retain coverage and estimation limits.
• Daily-price USD history and live-price POL equivalents use different valuation bases. sPOL redemption metrics exclude market premiums/discounts and transaction costs.
• Allocation APR estimates, supply scenarios, and APY equivalents extrapolate assumptions or observed windows; they are not guarantees of future returns.

Calculation Identity

When citing a figure, include the product page, metric, selected period and observation date. Read the displayed definitions and source timestamps before comparing values. See Using POLTRACK and Data License.

Current response policies identify such calculations as supply-burn-pipeline-reconciliation-v2, network-allocation-burn-pipeline-v2, liquid-supply-cutoff-v5, treasury-crosschain-inventory-v2, treasury-ethereum-flows-v1, staking-apr-block-policy-v2, stake-manager-funding-v1, and fee-batch-settlement-v2. They describe the applicable calculation/perimeter. meta.build identifies an API implementation build, not a data revision or independent deployment attestation. Check actual inputs, timestamps, and fallback availability alongside policy metadata.

Primary References

• Polygon documentation: POL
• MATIC-to-POL migration
• Rewards and staking incentives
• sPOL documentation
• EIP-1559 on Polygon
• POL contract source
• sPOL contract source
• Bor burn-recipient configuration
• PIP-24: burn collector policy
• PIP-25: supply adjustment and exclusions
• PIP-65: priority-fee economic model
• PIP-82: rebate routing program
• PIP-85: specified priority-fee allocation

Protocol references explain roles and declared policy. The observed datasets, formulas, fallback rules, and coverage stated on this page define what POLTRACK currently measures.