Priority Fee Distribution: PIP-65 / PIP-85
This page explains observed PIP-65 priority-fee distributions and the PIP-85 specification for Polygon Chain, also known technically as Polygon PoS. For general fee mechanics, start with Polygon Chain Fees. For how POLTRACK measures batches and validator income, see Methodology & Data Sources.
Reviewed October 7, 2026: the canonical PIP-85 document remains marked Draft. POLTRACK displays confirmed fee funding into StakeManager separately from validator payments and block-producer allocations. Staking APR is measured from earned reward-index growth; a funding transfer is not itself an earned reward or payout. Published policy and executed transfers are separate evidence.
What PIP-65 Changed
PIP-65 changed how Polygon PoS priority fees are redistributed after block production. Instead of treating all transaction fees as a single economic bucket, priority fees are routed into distribution pools.
The original PIP-65 model specifies:
| Pool | Share | Recipient logic |
|---|---|---|
| Block producer pool | 26% | Directed to the elected block producer |
| Validator pool | 74% | Distributed across validators by performance-weighted stake |
These distributions happen in batches, not as smooth daily wallet payments. POLTRACK treats observed payments as realized distribution facts and keeps them separate from modeled daily fee generation.
What PIP-85 Specifies
PIP-85 specifies a change to the downstream economics of the PIP-65 validator pool: a staker/delegator share and an adjusted remaining validator-pool formula.
The PIP-85 formula specifies:
Block producer pool = 26% of total priority fees
Staker / delegator pool = 50% of the 74% validator pool = 37% of total priority fees
Remaining validator pool = 37% of total priority fees
The specification weights the remaining validator pool by equality and performance rather than only the earlier stake-weighted approach. These documented percentages are reference parameters, not proof of observed payouts. POLTRACK does not turn a calculated pool share into an individual reward record.
The displayed network staking APR follows observed StakeManager rewardPerStake index growth, before validator commission and excluding the separate proposer bonus. It uses simple annualization. Fee funding contributes only when it reaches earned-reward accounting; no estimated fee APR is added to the observed index return.
Why It Matters
Priority fees connect network usage to validator and staker economics. When transaction activity rises, the fee pool can become a more important part of staking economics. When activity falls, emission can dominate the yield picture.
PIP-65 and PIP-85 are important for:
- validator income comparisons;
- distinguishing observed staker funding from earned rewards and withdrawals;
- fee distribution transparency;
- analysis of how Polygon PoS activity flows back to network participants.
How POLTRACK Tracks PIP-65
POLTRACK reads PIP-65 distribution transactions from the Polygon PoS multisig and maps payments to validator records. The validator analytics product shows batch history, total received, pool share, and recent trend.
Validator fee share = validator PIP-65 amount / total validator pool
Observed validator payments, block-producer Safe allocations, staking funding, and any downstream reward or claim records are separate data concepts. The existence of a distribution formula does not establish that a particular delegator has a claimable balance.
POLTRACK additionally reads finalized POL Transfer logs on Ethereum. A transfer from the priority-fee Safe to StakeManager is recorded as a distinct Fee funding to StakeManager batch. Polygon Chain Fee Distribution shows separate 30-day cards for Stakers funding, Validators payments and Block Producers allocations. POL Value keeps those destinations separate within Polygon Chain Security; its Staking Pool category records gross protocol emissions. Transfers from EmissionManager into the same contract remain classified as issuance funding, and neither funding classification is treated as evidence that a validator or delegator has earned or received a reward.
Any other Ethereum POL outflow from the priority-fee Safe is stored as unclassified and raises a monitoring alert. The Polygon-side bridge-system transfer is excluded from direct PIP-65 validator payout classification; the canonical funding fact is recognized only when finalized POL reaches StakeManager on Ethereum.
For live fee routing, see Polygon Chain Fee Distribution. For operator-level payment history, see Polygon Validators. For the product guide, see the Polygon Validators guide.
Data Limitations
PIP-65 batches can lag the underlying fee collection period. A payment observed on one date may represent fees collected earlier. POLTRACK therefore treats batch payment date, fee collection period, and validator state as related but not identical facts.
PIP-85 activation and distribution mechanics should be read from the canonical PIP text and public implementation evidence. The official fee calculator includes PIP-85 allocation logic, but an aggregate calculated staker pool or a StakeManager funding transfer is not evidence of an individual accrual, claim, or payout. POLTRACK does not infer individual staker fee income from those aggregates. Its observed staking benchmark measures earned index growth separately and does not attribute an unspent portion of the shared StakeManager balance to a specific funding source.
Primary References
Frequently asked questions
What is PIP-65?
PIP-65 is the Polygon PoS fee redistribution model that routes priority fee income to a validator pool and a block producer pool.
What is PIP-85?
PIP-85 specifies 50% of the PIP-65 validator pool for stakers/delegators, equivalent to 37% of total priority fees. These specification percentages are not automatically treated as earned yield. POLTRACK separately records confirmed staking funding and measures observed staking returns from reward-index growth.
Does PIP-65 income go directly to delegators?
PIP-65 tracks validator-side fee distribution. Delegator economics depend on validator commission, staking mechanics, and later fee-sharing policy such as PIP-85. Under PIP-85, delegator/staker fee sharing is a separate distribution path rather than the same thing as historical PIP-65 validator payments.
Why are payments batched?
The redistribution flow is settled periodically. That creates observable batch payments rather than a smooth daily payout stream.
How should I compare validators using PIP-65 data?
Compare total received, number of batches, pool share, and recent trend. Do not compare one batch in isolation.