PIP: Priority Fee Sharing for Delegators

Just · March 11, 2026, 6:30pm

Title: Priority Fee Sharing for Delegators
Author: Just Hopmans
Description: Extend PIP-65 priority fee distribution to include delegators.
Status: Draft
Type: Contracts
Date: 2026-03-11

Definitions

Priority fees: The tip portion of transaction fees on Polygon PoS, paid above the base fee. Base fees are burned. Priority fees are distributed to block producers and validators under PIP-65.
Delegator: A POL holder who stakes through a validator without running validator infrastructure.
Validator share token: An ERC-20 token on Ethereum representing a delegator’s proportional share of a specific validator’s total delegated stake.
Claim contract: A smart contract to be deployed on Ethereum that reads on-chain staking data and distributes priority fees to delegators.
Commission rate: The percentage a validator charges on rewards distributed to their delegators.
StakeManager: The core staking contract on Ethereum mainnet that records validator stakes, commission rates, and validator share token addresses.

Abstract

This proposal extends PIP-65’s priority fee distribution model to include delegators. Priority fees are accumulated on Polygon PoS, bridged monthly to Ethereum via the native PoS bridge, and distributed trustlessly by a claim contract that reads validator share token balances (PIP-69) and commission rates (StakeManager) directly on-chain. No off-chain computation is required. The validator retains their commission and self-stake share. The remainder flows to delegators proportionally. No existing contracts are modified.

Motivation

Polygon’s founding documentation states:

“These rewards are primarily meant to jump-start the network, while the protocol in the long run is intended to sustain itself based on transaction fees.” — Polygon Staking Economics.

If transaction fees are intended to sustain the protocol, then the participants who provide the capital securing those fees should share in them. Today, they do not.

Following the Rio hardfork (PIP-65), Polygon PoS introduced a new economic model for priority fee distribution. The model allocates collected priority fees to block producers (26%) and validators (74%). Delegators are excluded from this revenue stream entirely. PIP-65 originally specified an automated smart contract for fee distribution. This was replaced by a manual multisig process two days before mainnet launch due to technical limitations (see PIP-65 forum update, October 6, 2025).

This creates a structural misalignment between economic contribution and economic reward. Approximately 105 permissioned validators collectively provide roughly 0.34% of total staked capital. The remaining 99.66% — representing approximately 33,796 delegators — secures the network through delegated stake but receives no share of priority fees.

Delegators fund the revenue they are excluded from. Delegated capital directly increases a validator’s fee allocation under PIP-65, which distributes 74% of fees to validators weighted by total stake (including delegation). The delegators providing that capital receive none of the resulting priority fees. Their only yield is emission-based checkpoint rewards — the same rewards Polygon’s own documentation describes as temporary.
The commission system does not function as intended. Large validators offer 0% commission because it costs them nothing — their real income is priority fees, which exist outside the commission system entirely. Smaller validators need commission revenue to cover infrastructure costs (~$929/month per PIP-65 forum discussion), but cannot compete when delegators default to 0%. For the largest validators, ROI on infrastructure cost exceeds 8,000%. Commission was designed to let validators price their service. When the dominant revenue stream sits outside it, that mechanism breaks.
The gap grows over time. POL supply decreases through the EIP-1559 burn mechanism (~28.2M POL burned in February 2026 alone). Validators compound on both emission rewards and priority fees. Delegators compound on emission rewards only, which continue to decrease. Approximately 24.11M POL was allocated to validators in the 30 days preceding this proposal. As priority fees grow and emission shrinks, delegators have diminishing economic incentive to stake — directly threatening the network’s long-term security budget. This is precisely the scenario Polygon’s founding documentation warned against.
The permissioned validator set prevents market correction. Delegators dissatisfied with the fee distribution cannot start competing validators. In an open validator set, market dynamics would pressure validators to share fees. In a closed set of ~105 permissioned slots (PIP-39), the only correction mechanism is exit — which reduces network security rather than improving it.
Protocol spending amplifies the imbalance. PIP-82 redirects base fees — which would otherwise be burned — to subsidize gas for agent-to-agent transactions. This reduces the burn benefiting all POL holders, while the resulting transaction activity generates priority fees that flow exclusively to validators.

Precedent

This is not a novel design. Major proof-of-stake networks enforce fee sharing at the protocol level:

Cosmos Hub: All transaction fees and inflation rewards are pooled. A single validator commission rate applies to the combined total. Enforced by the x/distribution module. Major staking providers operating on Polygon — including Coinbase, Figment, Everstake, and P2P — already operate under this model on Cosmos.
Cardano: Transaction fees and reserve rewards are pooled per epoch. The stake pool operator’s margin applies to the total. Enforced by protocol.

Specification

This proposal does not modify PIP-65’s fee allocation model. How priority fees are divided among block producers and validators remains unchanged.

What changes

Priority fees are accumulated on Polygon PoS and bridged monthly to Ethereum via the native PoS bridge in a single transaction.
A claim contract on Ethereum receives the bridged fees and distributes them trustlessly. The contract reads validator stake weights from StakeManager to calculate the per-validator allocation per PIP-65 — the same formula already used for current multisig payouts. For each validator’s allocation, the contract reads the commission rate from StakeManager, deducts commission, and distributes the remainder to delegators in proportion to their validator share token balance (PIP-69). All inputs are on-chain. No off-chain computation is required.
Delegators claim on Ethereum from the same address they use for staking. They choose whether to restake or withdraw. Gas costs are paid by the delegator, consistent with all existing staking operations.

Why this is fully trustless

The per-validator allocation uses validator stake weights from StakeManager on Ethereum and the PIP-65 formula — the same calculation already performed for current multisig payouts. The per-delegator distribution uses two additional on-chain reads:

balanceOf(delegator) / totalSupply() on the validator share token (PIP-69, full ERC-20)
Commission rate from StakeManager.

No Merkle tree, no off-chain computation, no trusted operator. The claim contract performs the same calculation that anyone can verify on a dashboard — because it reads the same on-chain data.

Data availability

Delegation data is publicly available on Ethereum mainnet. PIP-69 upgraded validator share tokens to full ERC-20, enabling standard balance queries for proportional distribution. Commission rates and stake amounts are recorded in the StakeManager contract. Validator allocations follow from PIP-65’s existing formula. No new data sources or oracles are required.

What does not change

PIP-65’s allocation formula between block producers and validators.
The StakeManager contract on Ethereum mainnet.
The validator share token contracts (PIP-69).
Checkpoint reward distribution.
The delegation and staking workflow for delegators.

Commission rate impact

Validators set their commission rate once. This rate applies to both checkpoint rewards (as it does today) and priority fees (new). No additional configuration is required. This changes what commission means. Today, 0% commission costs a validator nothing — their real income is priority fees outside the commission system. Validators compete on who can give away the most. That is a scale game only large validators can afford. Under this proposal, 0% commission means distributing the full fee allocation to delegators. Commission becomes a meaningful economic decision. Validators compete on value — uptime, service, transparency, and fair commission rates. Small validators can win that competition.

Rationale

Why bridge to Ethereum rather than distribute on Polygon PoS?

Staking happens on Ethereum. Delegators claim checkpoint rewards on Ethereum.
Distributing priority fees on Ethereum preserves this workflow and enables the claim
contract to read PIP-69 share tokens and StakeManager commission rates directly — no cross-chain data bridging required. Delegators can restake immediately. The alternative — distributing on Polygon PoS — would require each delegator to bridge individually to restake, shifting costs to 33,796 delegators instead of one protocol-level bridge transaction.

Why mandatory rather than optional?

In a permissioned validator set, optional fee sharing cannot be corrected by market dynamics. Delegators cannot start competing validators. Making fee sharing optional in a closed system preserves the structural advantage of incumbents. Protocol-level enforcement is the standard approach in Cosmos Hub and Cardano — and the validators operating on Polygon already comply with mandatory fee sharing on those networks.

Why extend the existing commission system?

Delegators already understand commission rates when selecting validators. Extending this rate to cover all revenue creates a single transparent metric. Today, validators compete on who can give away the most — a scale game that favors incumbents. This proposal shifts competition to value: uptime, service, and fair commission rates. Small validators can win that competition. This mirrors Cosmos Hub’s design, where a single commission rate applies to both inflation and transaction fees.

Backwards Compatibility

No existing contracts are modified. Two new contracts are deployed: one on Polygon PoS (fee accumulation) and one on Ethereum mainnet (trustless claim distribution). The only change to existing infrastructure is redirecting priority fees from the current multisig to the new fee accumulation contract. Checkpoint rewards continue to function as they do today. Validators’ existing commission rates apply automatically.

Security Considerations

Claim contract correctness. The claim contract reads on-chain data (PIP-69 share tokens, StakeManager commission rates) and performs arithmetic. The logic is deterministic and verifiable. Standard smart contract auditing practices apply.

Snapshot manipulation. A time-weighted average balance over the distribution period prevents gaming around snapshot blocks.

Commission rate frontrunning. A timelock on commission rate changes (one distribution period delay) prevents validators from raising rates immediately before a distribution.

Bridge security. The proposal uses the existing Polygon PoS native bridge, inheriting its security model. No additional trust assumptions are introduced. Future implementations may use AggLayer infrastructure for trustless, higher-frequency distribution and inclusion of Heimdall performance scores once Polygon PoS is connected.

References

Copyright

All copyrights and related rights in this work are waived under CC0 1.0 Universal.

S1W · March 11, 2026, 6:52pm

Thanks you so much for this proposal, I really hope a lot of community members are going to support it! That said:

Swift implementation is critical.

This proposal addresses a structural misalignment that should not remain unresolved any longer. Delegators provide the overwhelming majority of the economic security behind Polygon PoS, absorb the token price risk, and yet remain excluded from a growing part of the network’s real economic output: priority fees.

That gap may have been tolerable when emissions were the dominant source of rewards, but it becomes increasingly hard to justify as fee generation grows and Polygon moves toward a more mature, utility-driven model. If the network wants staking to remain credible as a long-term capital commitment, delegators must participate in the fee upside they help secure.

A slow or multi-year path here would be a mistake for three reasons:

Economic fairness

The present design leaves delegators structurally undercompensated relative to the capital they contribute. That weakens the legitimacy of the staking model.

Market signaling

Polygon is increasingly building a real revenue story. If that revenue continues to accrue disproportionately to validators while delegators are sidelined, the market will recognize the misalignment and discount POL accordingly.

Delegator retention and growth

Capital is mobile. Over time, delegators will compare real yield opportunities across ecosystems. A system where delegators secure the network but do not share in meaningful fee revenue is harder to defend.

For that reason, this should be treated as a priority economic upgrade, not a “nice to have” refinement for later. Even if the exact operational design still needs iteration, the direction should be locked in quickly and implementation should move with urgency.

At minimum, the community should align rapidly on two points:

priority fees should be shared with delegators;

implementation should follow on an accelerated timeline.

A fast rollout would send an important signal that Polygon is serious about aligning token economics with actual network usage. That would strengthen staking, improve confidence in POL as a productive asset, and better connect network success to tokenholder outcomes.

pete · March 11, 2026, 7:03pm

Calculating the claimable amount for delegators is not as simple as looking at the current balance of validator share tokens at the time of payout.

There are several cases that make this significantly more complex:

What happens if a delegator unstakes before the next payout cycle?
What if someone only stakes for a very short period (e.g., a single day) near the end of the payout window?
How should rewards be handled for stake that changes frequently throughout the period? (reducing stake or increasing stake)
How should rewards be handled if staked tokens are moved to different accounts?

Without a sufficiently robust accounting system, this could also open the door to gaming strategies. For example, a user could repeatedly stake and unstake the same tokens across multiple accounts within the same payout window to capture a disproportionate share of the rewards if the distribution logic is based on simple snapshot balances.

Because of these challenges, this is not a trivial feature that can be rushed. The reward distribution algorithm must be designed carefully to ensure that it:

Accurately tracks stake over time
Prevents manipulation through timing or account splitting
Fairly distributes priority fees to delegators based on their actual participation

Implementing this directly on Ethereum mainnet would also likely be gas-intensive and expensive, especially if the accounting requires frequent state updates or historical tracking.

It’s also worth noting that priority fees are already being collected and sent to a single address on Ethereum Mainnet. Given that, it should be straightforward to bridge those funds to Polygon PoS chain at each payout cycle and implement the distribution and claiming mechanism there, where delegators would be able to claim rewards in a much more gas-efficient environment. That will also boost TVL of the PoS chain and encourage usage of the PoS chain.

Bluelights · March 11, 2026, 7:44pm

I agree this shouldn’t be rushed and that naive snapshot based accounting would create edge cases and potential gaming strategies.

However, these problems are not unique to this proposal as they already exist in many staking and liquidity systems across the industry, and there are well understood mechanisms to handle them.

A few approaches that could mitigate the issues you outlined:

1. Time weighted stake accounting

Instead of snapshot balances, rewards could be distributed based on stake-time (stake × time). This ensures that someone staking for one day at the end of a reward period receives proportionally less than someone who remained staked for the full period.

Many DeFi reward systems already track this using accumulator style accounting.

2. Reward-per-share accumulators

A common approach used in staking contracts is a global “reward per share” index that increases whenever fees are added to the pool. Each delegator’s claimable rewards are calculated relative to the index at the time they stake/unstake.

This avoids needing to iterate through all delegators and naturally handles:

stake increases
stake reductions
short-term staking
account transfers

3. Epoch-based reward accounting

Since Polygon already operates on epochs for validator operations, priority fees could be aggregated per epoch and distributed based on stake participation during that epoch.

This significantly simplifies the accounting model and reduces the attack surface for rapid stake/unstake strategies.

4. Distribution on Polygon PoS instead of Ethereum

I also agree with the suggestion that distributing rewards on Ethereum mainnet would likely be expensive.

If priority fees are already collected on Ethereum, bridging them periodically to the PoS chain and distributing them there would make a lot of sense:

far lower gas costs
cheaper claiming for delegators
additional activity and TVL on the PoS chain

None of this suggests the problem is trivial, but it also doesn’t appear unsolved from a design perspective. These patterns already exist in many staking and reward distribution systems.

Given the engineering capabilities within the Polygon ecosystem, particularly the work already done on zk systems and complex validator infrastructure designing a fair and manipulation resistant reward mechanism for delegators should be achievable with careful implementation.

Just · March 11, 2026, 8:17pm

Thanks Pete for the technical considerations and bluelights for the detailed implementation analysis.

The accounting challenges Pete raised are real — and the approaches bluelights outlined (time-weighted accounting, reward-per-share accumulators, epoch-based distribution) are proven patterns that address them directly.

On distribution chain: distributing on PoS instead of Ethereum is worth serious consideration. The main question is how to make delegation data (ValidatorShare balances, commission rates) available on PoS, since it currently lives on Ethereum. Would be interested in your thoughts on that.

The Draft is intentionally open on implementation specifics for exactly this kind of discussion. The principle has support. Let’s get the design right. No rush

Just · March 11, 2026, 8:57pm

On the concern that implementing this on Ethereum would be gas-intensive:

The accounting problem described here — distributing rewards proportionally to a changing set of participants — is a solved problem in DeFi. Aave, Compound, Lido, Synthetix, and hundreds of protocols distribute rewards to millions of users on Ethereum daily. The pattern they all use is the same: a reward-per-share accumulator.

How it works:

The contract maintains one global variable per validator: rewardPerShare. When priority fees arrive, the contract updates this variable once:

rewardPerShare += newFees / totalShares

That’s one storage write per validator — not per delegator. For ~105 validators, that’s ~105 writes per distribution period.

Each delegator’s claimable amount is calculated at the moment they interact:

claimable = shares[delegator] × (rewardPerShare - rewardPerShareAtLastClaim)

No iteration. No snapshots. No historical tracking. The delegator pays gas only when they choose to claim.

How it handles the edge cases raised:

Unstake before payout: the accumulator settles at unstake. Delegator receives rewards only for the period they were staked.
Short staking period: rewards are proportional to stake × time through the accumulator. One day of staking earns one day’s share.
Frequent stake changes: each change settles the previous period at O(1) cost. No batch processing needed.
Tokens moved between accounts: PIP-69’s transfer hooks can trigger settlement on transfer, same pattern as Lido and Synthetix.
Gaming via rapid stake/unstake: No snapshot window to exploit. Rewards accrue continuously based on actual participation.

This is the exact mechanism behind Synthetix StakingRewards (~200 lines of Solidity, open source, MIT licensed, forked thousands of times), Compound’s reward distribution, Aave’s incentive controller, and Lido’s share-based rebase. It has been audited, battle-tested, and proven at scale for years.

Protocol cost per distribution: ~420,000 gas ≈ $1–5 at current prices. That is comparable to a single Lido oracle report — which updates balances for millions of holders.

For context: Lido rebases stETH for millions of holders on Ethereum every day at ~460,000 gas. This proposal needs to distribute to ~33,796 delegators, monthly.

The gas cost is not a blocker — the pattern is proven, the scale is smaller, and the frequency is lower.

pete · March 11, 2026, 10:21pm

That’s exactly how POL staking rewards are currently calculated today. For priority fees, it’s more complicated than that because priority fees are paid and collected on the PoS chain, not on the Ethereum mainnet.

The team already knows how to implement this, my point is that this is not as trivial as you think, and requires careful planning, testing, and an audit before it can be deployed, like any other smart contract deployments. Expecting this change to happen overnight is unreasonable and reckless.

Please give the team some time to work on this.

josevelez · March 11, 2026, 10:25pm

Thank you for this proposal. I don’t have anything technical to add, sorry; but as a long time POL holder, I support this.

The market has already signaled how it feels about current POL tokenomics - in spades.

Just · March 12, 2026, 9:47am

Pete made an important point: the current ValidatorShare contracts already handle reward-per-share distribution for checkpoint rewards.

That changes the implementation path from what I originally proposed in the PIP. Instead of a separate claim contract, priority fees could feed directly into the existing system.

Since the accounting already exists — what would need to change:

From what I can tell, two things. Happy to be corrected on the details.

A collector contract on PoS that receives priority fees and bridges them to Ethereum once per period. The native PoS bridge already exists — we can use it for this function to.
A distribution function in StakeManager that takes the bridged fees, splits them per validator weighted by stake, applies commission, and adds the delegator portion to the same delegatorsReward pool that checkpoint rewards already use.

ValidatorShare doesn’t need to change. The claim mechanism doesn’t need to change. Delegators and validators claim through the same interface they already use.

The edge cases raised earlier in this thread:
All handled by the existing system. Unstaking, short staking periods, frequent stake changes, token transfers, gaming — the current rewardPerShare accumulator already deals with all of it. And it works.

Why Ethereum, not PoS:

The data needed to distribute trustlessly — ValidatorShare balances, commission rates, total stake — only exists on Ethereum. It’s not available on the PoS execution layer. This has been the case since launch. It never changed.

Distributing on PoS today would require off-chain calculation by a trusted party — which is exactly how the current multisig works. Bridging to Ethereum and feeding into the existing ValidatorShare system removes that trust requirement entirely.

In the future, once PoS connects to AggLayer, staking data could be proven on PoS via ZK proofs. Delegators or validators could then choose: claim on Ethereum and restake directly, or claim on PoS with lower gas costs. But that’s a future upgrade — not a reason to postpone it.

Main risk:

The bridge. If a bridge transaction fails or is delayed, the distribution for that period is delayed — but not lost. Fees sit in the collector on PoS until the next successful bridge. No funds at risk, only timing.

Would like to hear how others see this approach — especially validators and delegators who would be directly affected.

jitendra7th · March 12, 2026, 4:21pm

If it can’t be calculated to distribute to the stakers, then burn the fees collected.

This way it will help reduce the inflation and win win.

nowrich · March 12, 2026, 7:26pm

I am in favor of the direction of this proposal.

It is logical and fair for Delegators to receive a share of priority fees from Polygon PoS since Delegators make up such a large portion of the capital used to secure Polygon PoS. Over time, transactions will generate more revenue via transaction fees; if Delegators are left out of receiving these funds, there will be an actual misalignment.

I also support the comments suggesting that the implementation should be designed with caution, thoroughly tested, and audited. There is still room for improvement on the technical design, however the overall concept of sharing priority fees with Delegators has merit.

As a POL staker, I would strongly support a trust-minimized method to distribute priority fees to Delegators using the existing reward structure as much as possible.