PIP-85: VEBloP PIP-65 Priority Fee Formula Adjustment

Polygon Improvement Proposals Canonical PIPs
1

PIP-85: VEBloP PIP-65 Priority Fee Formula Adjustment

Authors: David Silverman (@oneski22), Sandeep Nailwal, Nicholas Truslow (@smokey), Parvez Shaikh (@parvez03), Vasanti Rode (@Vasanti01)

Type: Core

Table of Contents:

  • Abstract

  • Definitions

  • Motivation

  • Specification

  • Backward Compatibility

Abstract

Priority fees are up 1000% (10x) since the start of the PIP-65 system. While there are a tremendous amount of fees being passed to validators, this revenue is not presently distributed in a way that is equitably ensuring success for all ecosystem participants. Delegators are not seeing these fees passed on in any meaningful manner, and there is great variability in the reward distribution amongst the validator set. This PIP seeks to address these two issues. First, by adjusting the PIP-65 priority payout formula to include an equal weight factor for the validator distribution as well as a split for stakers.

The PIP-65 Priority fee changes proposed are as follows. First, taking 50% of the validator pool and distributing it to stakers via periodic merkle claimers deployed on Ethereum. Second, adjusting the remaining validator pool to be distributed 75% under an equal weighted performance adjusted fashion, and 25% under the existing stake weight formula.

Definitions

Priority Fees: Part of the transaction fee, it is paid to block builders as part of EIP-1559, typically correlated with blockspace demand, especially when said demand is in excess of the max block size. As part of PIP-65 and the VEBloP upgrade, these fees are distributed monthly and split between the block producers and validator set as a whole.

PIP-65 Fee Distribution System: A process by which Polygon Labs and Regen Financial distribute protocol funds according to formulas passed as PIPs by the Polygon Protocol Governance Process. To date it covers the EIP-1559 Priority Fee System for Polygon PoS and has processed over 40MM POL in value.

Motivation

Since the inception of PIP-65 we have seen a 10x increase in the amount of priority fees, with over 5.4MM POL distributed to validators during the February distribution. These fees are essential towards ensuring validator sustainability. Even with the decrease in hardware requirements VEBloP has brought, the current formula, combined with the current validator commission market rate creates an unsustainable situation for many smaller validators. Additionally, it has always been the goal of the Polygon PoS Staking system to see these priority fees (previously MEV fees under the pre-PIP-65 system) shared back with delegators as they ultimately enable the privileged position validators hold.

With sufficient data on the current performance of the PIP-65 system we propose adjusting the formula to more equitably distribute rewards across the validation set, while also for the first time, enshrine delegator’s rights to priority fees.

In order to see these changes implemented rapidly upon adoption of this PIP we recommend the delegator fee share distribution be completed by periodic (initially monthly) merkle tree distributors on Ethereum Mainnet and call upon the maintainers of staking UIs and software (for example: staking.polygon.technology) to integrate claiming these rewards into their flows.

This PIP also stipulates that when the PIP-65 system is enshrined in smart contracts or other consensus bound mechanisms of the chain, the changes made in this PIP are included as well (unless superseded or canceled by a future PIP).

Specification

No direct onchain changes.

Change the formula that governs PIP-65 distributions from block 85245000 onwards as follows:

New Variable Sf: Stakers Fee Rate (e.g.: 0.5 for 50%)

New Variable Ef: Equality Factor (e.g.: 0.75 for 75%)

Pool_validators is redefined as:

  • Pool_valdiators = T * (1 - C) * 1-Sf

New distribution pool Pool_stakers is defined as:

  • Pool_stakers = T * (1 - C) * Sf

Formula for Rv() is redefined as:

  • Rv() = ((PerformanceWeightedStake_v / TotalPerformanceWeightedStake) * Pool_validators * (1 - Ef)) + (Pool_validators * Ef / Number_of_Validators * Pv)

Sf should be set to 0.5

Ef should be set to 0.75

New Cleanup Process:

  • All Priority fees leftover after this calculation shall be sent to the burn address.

Distributions to benefit stakers shall be deployed as merkle claimers, integrated into staking.polygon.technology with reference code for interacting with them and made fully open source for other integrators to leverage.

Backward Compatibility

This change is backwards compatible as there is no broken functionality caused by these changes for any validator, staker or integrator. Stakers (and UIs designed for staking) should integrate the reference code for interacting with the merkle claimers in order to obtain their priority fees.

Copyright

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

3 Likes
2

Love it! Very happy you see the team picking this up so fast!

3

I highly recommend deploying the merkle claimer contract on the Polygon PoS chain instead of the Ethereum mainnet. Priority fees are collected on the PoS chain and the POL should remain there to encourage continued economic activity on the PoS chain, rather than being bridged out to Ethereum. This will also make the ongoing cost of updating the merkle claimer contract negligible.

4

To say this is something that is LONG overdue would be an understatement. I am very happy to see this is finally being addressed.

1 Like
5

I support PIP-85 as a fast first step. Getting stakers paid by end of April is the right priority.

From the perspective of the community proposals — the Priority Fee Sharing PIP and the Base Reward PIP:

Trust model

PIP-85: No direct on-chain changes. Polygon Labs and Regen Financial continue to calculate and distribute. The formula is open source and all token movements are on-chain — the system is auditable after the fact, but not enforced on-chain. This is a trusted setup with verifiability.

Community PIP: A collector contract on Polygon PoS accumulates fees and bridges them to Ethereum, where a distribution function feeds them into the existing ValidatorShare reward pools. The distribution function reads all inputs on-chain — stakes, commission rates, performance scores. No off-chain calculation. No trusted party. On-chain enforced.

Merkle claimer vs existing reward system

PIP-85: Staker distributions via Merkle claimers. An off-chain party calculates who receives what and publishes the root. PIP-85 does not specify who performs this calculation, what happens if it is wrong, or which chain the claimer is deployed on. If deployed on Ethereum — where staking data lives — every delegator pays extra gas on commission and fees claim. If deployed on PoS, staking data needs to be calculated off-chain, reintroducing a trusted party. And delegators who want to restake need to bridge back to Ethereum individually.

Community PIP: Adds one function to ValidatorShare — addPriorityFeeReward — that feeds into the same reward-per-share accumulator already handling checkpoint rewards. This is how POL staking rewards are currently calculated and distributed. It works. No new claim mechanism. All edge cases — rapid stake/unstake, short staking, token transfers — are already handled by the existing system. Delegators claim and restake in the same place. Zero additional gas cost. No seperate bridging needed.

Speed of deployment

PIP-85: No modifications to existing contracts. Requires building Merkle claimers from scratch, deploying them, and integrating into the staking UI.

Community PIP: Adds one function to ValidatorShare and deploys a collector contract. No integrator coordination needed — they already integrate with ValidatorShare.

Custodial model

PIP-85: Does not change the custodial model. POL accumulates in the multisig between monthly payouts. At current fee volumes that is millions of POL held by two parties between distributions.

Community PIP: The collector contract distributes when a threshold is reached — at current volumes, multiple times per day. Less POL held at any point. No accumulation between monthly payouts.

The 50/50 split

Delegators provide 99.66% of staked capital. Validators provide 0.34%. Delegated capital directly increases a validator’s fee allocation under PIP-65, which distributes fees weighted by total stake including delegation. The delegators providing that capital currently receive none of the resulting priority fees.

PIP-85: Both sides receive 50% of priority fees. This ratio is hardcoded in the formula. Changing it requires a new PIP.

Community PIP: The market determines the split through commission rates. If validators need more, they raise commission. If competition drives commission down, delegators receive more. The system adjusts without requiring a governance proposal every time conditions change.

Validator sustainability

Every Polygon PoS validator has identical infrastructure requirements regardless of delegated stake. PIP-65’s own analysis estimates the cost at $929/month. Yet the February 28 payout shows a 359× difference between what Coinbase received ($67,197) and what Stakebaby received ($187). That difference is entirely a function of delegated stake, not operational contribution.

PIP-85: 75% of the validator pool distributed equally (performance adjusted), 25% stake-weighted. This helps smaller validators, but what each validator receives depends on total fees and number of active validators. It varies every period. A small validator cannot predict whether they will cover costs.

Base Reward PIP: Every performing validator receives a fixed amount covering infrastructure costs before the proportional split. Simulation using the February 28 payout data:

  • Validators below infrastructure cost: from 66 to 0
  • Stakebaby goes from $187 to $1,405 (+650%)
  • Upbit loses 11.3%, Coinbase 10.8%
  • Total base allocation: 14.6% of the pool — decreasing as fees grow

The base reward transforms fee sharing from a sacrifice into an opportunity. A validator who starts each month with costs covered has both the ability and the incentive to share with delegators.

How the two community PIPs work together

The Priority Fee Sharing PIP addresses the vertical inequity — validators receive 100% of priority fees, delegators receive 0%. The Base Reward PIP addresses the horizontal inequity — the top 5 validators capture 42% of all priority fees, while 66 out of 103 cannot cover infrastructure costs.

One without the other is incomplete. Fee sharing without a base reward penalizes delegators who choose smaller validators — those validators cannot share as much. A base reward without fee sharing still excludes delegators entirely. Together, they create a system where every validator can compete and every delegator benefits from fees their capital generates.

PIP-85 tries to address both in one formula. The 50% staker split covers the vertical. The equal-weight component covers the horizontal. But the two mechanisms are disconnected — the staker split bypasses commission, and the equal-weight provides no guaranteed floor.

What I’d like to see

Two things alongside PIP-85:

  1. A commitment to transition to on-chain, trustless distribution as phase 2 — with a timeline. PIP-85 itself stipulates that “when the PIP-65 system is enshrined in smart contracts, the changes made in this PIP are included as well.” When does that happen?
  2. The community proposals considered on their actual merits — the Priority Fee Sharing PIP does not remove validator incentives, and the Base Reward PIP directly addresses validator sustainability with real data.

— Just Hopmans (@HopmansJust)

References:

2 Likes
6

Hey @Just only seeing 2 things here on the list, but will address them:

  1. PIP-85 has the strongest language we can give in a governance proposal. Enshrining the entire system in full decentralized smart contracts is a goal for the ecosystem, and as much as I would like to, at least for the team of devs working on the PoS contracts at Polygon Labs we cannot commit to a specific date to complete this task. We believe it is best to approach progressively, and have taken a first step of enshrining the priority fee recipient and make its correctness enforced as part of consensus level checks, removing the block builder’s ability to circumvent the system. Our next goal is to begin using a fee splitter contract, once we have done the proper discussions with many community stakeholders. To be clear this doesn’t stop any other community developers from building this component.

  2. All proposals are considered by the community, and per our governance process, anything brought up to PPGC gets discussed. To be clear this PIP does not state anything about the 2 proposals you have brought forward, and makes no judgement on their intentions or merits. This PIP does propose a different solution to similar problems. This solution PIP-85 proposes was arrived at in consultation with many stakeholders throughout the ecosystem including Validators, Stakers (large, small and CEX program), core developers and users, as well as taking into account the bandwidth and roadmaps of various development teams in the Polygon ecosystem as well as our downstream partners.