PIP-4: Validator Performance Management

PIP- 4: Validator Performance Management Proposal


Eric Hill

Harry Rook

Mateusz Rzeszowski

Status : Final


In its current state, the PoS validator network is not entirely permissionless in that the previously-selected set of validators has largely persisted since testnet.

Following the spirit of gradual decentralization, certain steps need to be taken with the end state being the community assuming care for the network.


To arrive at a state of absolute decentralized self-governance, as was mentioned back in the mainnet announcement, the validators will have to self-regulate network participation to an agreed set of parameters.

Following on from the considerations and feedback of validators on the forum and elsewhere, the Polygon Governance Team wants to now put forward the following proposal for validators to accept or reject.


Self-regulation in this context refers to setting and administering conditions for the admission, participation, and if necessary, forced exit of validators from the active set - with the last part formalizing previously-achieved consensus on the subject.

Successfully engaging in self-regulation requires setting parameters with fair, transparent, and self-enforcing standards for:

  1. Measuring performance;
  2. Compliance with conditions of participation;
  3. Choosing and acting on remedial measures; and
  4. Addressing compliance breaches if and when they arise.

Under the proposed parameters a validator who underperforms the benchmarks for 700 checkpoints will have a second 700 checkpoint period to correct the deficiency before a process to unbound its stake is implemented.

The parameters in Part A and Part B were chosen following feedback from the validator community specifically and the Polygon community at large.

If adopted, the framework would allow further decentralization of the network by means of validator self-regulation.

As a result of the increased amount of validator churn that may occur as a result of Part A and B, Part C details the roadmap and process for which new validators would be admitted into the set in a way that promotes network health and aligns with the notion of gradual decentralization.

In addition to the above, Part D proposes to increase the validator set from 100 to 105. This would increase the economic security and decentralization of the network.


Part A

Here we propose a potential framework to manage validator performance through a self-enforced performance standard across the network.

1. Proposed Potential Parameters

Measure individual validator performance based upon checkpoints signed over a specified time period, performed on a rolling basis at each new checkpoint. Then measure this against a benchmark of the total network performance in that same time period, as detailed below:

  • Monitoring Period (“MP") = previous 700 checkpoints, updated every new checkpoint.
  • Take % of checkpoints signed by each validator in the MP, combine all % values and find the median average.
  • Multiply median average by an agreed multiple = Performance Benchmark (PB).
  • At each checkpoint, calculate the % of checkpoints signed in the MP by individual validators and measure against the PB.

2. Performance Benchmark

In order to transition validators into the process requiring satisfaction of the proposed potential parameters, there will be a slightly lower benchmark for the first ~2 months, while validators become accustomed to the parameters.

  • PB1 → 95% of median average of last 700 checkpoints signed by validator set (first 2,800 checkpoints)
  • PB2 → 98% of median average of last checkpoints signed by validator set (continues thereafter)

3. Validator Performance Dashboard

If validators adopt this proposal, then a public dashboard would be developed to provide live monitoring of individual and overall validator performance.

The dashboard would serve the functions listed below.

At launch:

  • Provide real time visual representations of validator performance telemetry.
  • Display validator notices and updates on their status, either meeting performance benchmarks or being deficient.

In a future release:

  • Provide direct notifications to validators, alerting them to their deficient status.

4. Notice to Validators

If the validators adopt this proposal, after the MVP dashboard is developed and deployed, validators will be given 24 hours notice of the commencement of performance monitoring, with the data set beginning 24 hours after the notice is sent.

Part B

If the validators adopt this proposal, then any validator that falls below any performance benchmark would enter the process below:

1. Remedial measures and corrective action

Deficient Validator Process:

  • If validator <PB in the MP → Grace Period (“GP”).
  • If validator in GP <PB after 700 checkpoints → Notice of Deficiency (“NOD”), enters into Grace Period 2 (“GP2”).
  • If validator in GP2 <PB after 700 checkpoints → Final Notice (“FN”), validator will be unstaked with no further resource.


The GP is 700 checkpoints long and allows a validator time to bring its performance back above the PB. If the deficiency is corrected within the GP, then there would be no further action.

Failure to become compliant in the GP would result in issuance of a public NOD from the Performance Monitor (“PM”). The operator would have a 700 checkpoint period to correct the deficiency in GP2. If the deficiency is corrected within the NOD period, then there would be no further action, however the NOD would remain public.

Failure to become compliant in the GP2 would result in issuance of a FN of the intent of the community to implement a forced exit procedure by offboarding the validator from the network by unbonding their stake.

2. Forced Unstaking

The unstaking of the deficient validator would be done as follows:

Call ForceUnstake function in Polygon Commitchain Contract:

  • 0xFa7D2a996aC6350f4b56C043112Da0366a59b74c

Part C

1. Validator Admission

To repopulate the validator slots that may become vacant as a result of the forced unstaking detailed in Part B, below is the proposed roadmap for the admission and onboarding of new validators into the set:

  • Phase 1 (current) - The multi-sig holders would set the admission parameters and choose the validators.
  • Phase 2 (next step) - The governance and validator communities set and approve the parameters, and the multi-sig holders implement those parameters.
  • Phase 3 (end state) - The governance and validator communities set the parameters and admit and onboard validators themselves.

2. Irregular Joining

Joining the validator network consists of two steps: admission and onboarding. These steps and specific parameters relating to each will ultimately be controlled by the governance community. This community approach enhances network security with a level of certainty about the intent of the actors trying to join the network, and introduces social ramifications, which can ensure proper functioning of the network, e.g., validator onboarding and education, participation in off-chain and on-chain governance, efficient communication on critical updates and/or node performance issues.

Irregular joining occurs when a new validator joins the network, but does not follow or circumvents the community-approved admissions and onboarding process. Bot sniping of a node is an example of an instance of irregular joining.

As irregularly-joining validators do not participate in the onboarding process, they cause massive issues for the network health. In particular, the inability to communicate on critical updates and/or node performance issues is problematic.

As a result, we propose if this proposal is adopted:

  1. Participation in the admission process (outlined in Part C) will be viewed as obligatory;
  2. Any future participants who circumvent the process will be unstaked from the network;
  3. The minimum $MATIC staked will be increased from 1 to 10,000 in order to deter snipers.

Part D

1. Increasing the Validator Set

At times, a situation may arise in which an underperforming validator has already been offboarded, following a Final Notice, but a new one has not yet been onboarded to the network. This essentially means that the active validator count may occasionally drop below 100. Additionally, validators that underperform for prolonged periods of time effectively reduce the active set.

In order to maintain network integrity and guarantee an active set of 100 efficient validators, we propose increasing the maximum validator count to 105 from 100.

As the network has matured and seen wide adoption, it seems warranted to provide new validator slots for added decentralization and security. A conservative increase of 5 slots seems like it would serve as a good starting point.


Part D shouldn’t take part in this proposal, looks to me that this is just an excuse to increase the current active set.

The network runned for months with only 99/98 active validators, increasing to 105 doesn’t look like it makes sense. Also, how do you plan to add another 5 validators? Invite more friends?

Also taking into account that 1 validator == 1 vote, shouldn’t the foundation KYC the validators?? We don’t know who is behind all those Anonymous, also some companies have more than 1 validator slot, we just need to look at the explorer and see, they even use the same logos and names.


We like the proposal overall, but also wonder if part D adding 5 validators should be a separate proposal.


The Active Validators are all trusted financial and technical stakeholders that uphold the network. They earn their right to vote through being a Validator (and by in the future keeping to governance-initiated performance metrics as mentioned in the proposal).

We also have to allow for privacy and anonymity.
Even though this isn’t a “DAO”, Governance on POS is Daoesque and should be as such, IMO.


In general I like the ideas and concepts.

One thing I’d like to add is some sort of “reorg” measurement included in validator performance. At present, not only are validators not penalized for causing reorgs but they are actually rewarded for it. From an end user standpoint, this should be changed.


I understand but having the same “company” with more than 1 vote it’s not the most equal

1 Like

Also how will the new 5 validators be selected?

1 Like

Hey @Flamingo, thank you for your questions and feedback. The method for the selection of new validators is described in Part C of the proposal. The phased approach seeks to provide a progressive roadmap for the community to first set the admission parameters, and then consequently execute on them.

We plan on providing more details of how this could work - we’re already working on it internally, but all feedback is welcome!

Your thoughts would be much appreciated in this thread.


I would agree with the whole proposal except part of ‘Part C’.

There are two validators mentioned in ‘Part C’. I checked the staking page, the validator 139 has a very good performance with 100% ‘checkpoints signed’. Obviously they have good knowledge about how to setup and maintain the Polygon node. We can’t kick out validators just because they got a chance to be a validator. What’s wrong with those token holders who voted for well-behaved validators?
The validator 140 has missed all the checkpoints since it became a validator. I agree to kick it out under the rules of ‘Part A’ and ‘Part B’ if they’re adopted.

We’re trying to adopt new government rules and onboarding process. New rules and process should start from new validators. If we can apply the new rules to the latest 2 validators, why can’t we apply the same rules to the latest 20 validators.

Polygon POS is a permissionless network.


Hey guys!
First of all, thanks for the whole proposal and for being interested in our opinion.

We agree that performance measurement is a must at the moment. The requirements in Part A appear objective and reasonable, and the procedures described in Part B appear sufficient to correct potential failures.

But we have a few questions about Part C and Part D:

What will the onboarding process look like? How will potential participants be evaluated and how will validators be involved in the evaluation?

In case if no one from the validator set is removed as a result of the forced unstaking, will the active validators set now consist of 105 members? If everyone will perform well, then these 5 will still be included in the active set?

Also, in “forced unstake” will only fundation tokens be unstaked or all together? Will it be like a jail in cosmos? Then the question is how to return to the set after, is it foreseen?

Thanks in advance!


Hey Masha, thank you for your team’s feedback. It’s great to see more and more validators being involved in the discussion and so we couldn’t imagine not asking for your opinion.

Now, to answer your questions about Parts C and D one by one.

What will the onboarding process look like? How will potential participants be evaluated and how will validators be involved in the evaluation?

From the proposal:

  • Phase 1 (current) - The multi-sig holders would set the admission parameters and choose the validators.
  • Phase 2 (next step) - The governance and validator communities set and approve the parameters, and the multi-sig holders implement those parameters.
  • Phase 3 (end state) - The governance and validator communities set the parameters and admit and onboard validators themselves.

We don’t have a firm definition of phase 2 yet, but we’re looking forward to working with validators on both the particular process, as well as specific admission parameters.

For onboarding specifically, we’re looking to revamp that process completely - from providing better educational resources to involving existing validators as mentors. All of that is aimed at creating as many community-driven mechanisms as possible, working hand in hand with those who should be perceived as representatives of the ecosystem.

In case if no one from the validator set is removed as a result of the forced unstaking, will the active validators set now consist of 105 members? If everyone will perform well, then these 5 will still be included in the active set?

Yes, the validator set would consist of 105 members going forward, all of them getting a chance to participate equally.

Also, in “forced unstake” will only fundation tokens be unstaked or all together? Will it be like a jail in cosmos? Then the question is how to return to the set after, is it foreseen?

The tokens of a validator would be unstaked and the delegators would need to unstake and redelegate to another validator to earn rewards.

If an unstaked validator wanted to return to the set, they would need to go through the admission process.

I hope this clarifies things, @everstake_masha, I’m looking forward to keep the discussion going!


Everything is clear, thank you very much for the explanations!


We think this proposal would help improve validator performance and decentralization, and agree on part A and B.

For parts C and D, we would prefer to see separate proposals as these topics could be debated separately


This proposal seems to provide solutions to address Polygons ‘today’ issues-- so I am happy with seeing this proposal pass.

I agree that a next phase ‘tomorrow’ solution would be to further expand in to more codified admissions (and jailing) parameters, possible KYC, and a team implementation everything after more discussion and requirements are outlined.

Expanding the current set and pruning validators that are underperforming is a quick win.


As mentioned by others. parts C & D are a different problem and warrant a separate proposal. A nd B look good.


We are onboard an agree with part A and B but believe it can only be implemented when Part C is agreed or disagreed on by the majority .

Question about part C 1. Validator Admission. Is it so when a failed validator is unstaked by the multisig account. Is that multisig account becomes the owner of that validator slot? and Phase 1 starts? Or is that slot now open and “Irregular Joining” is possible?

We believe when the majority agrees on PartC.1 Validator Admission, Irregular Joining should be made impossible. I think it will damage the reputation of the network if we force unstake new validators that didn’t follow the “rules” but are excellent preforming validators.

Also agree with Alex2:

The new rules and process should start from the moment we set them in place and not apply them retroactivity


Thank you for your team’s feedback, @Kasper.

As you rightly point out, part C formalizes the admissions process and lays out a roadmap towards the governance community owning that process. Such a formalized framework is needed to go hand-in-hand with parts A and B.

To answer your question, the multi-sig doesn’t become an owner of the validator slot at any time - in the unstaking scenario, what happens is a decrease in the number of maximum validator slots (by one) along with unstaking of the underperforming validator. Consequently, an increase in that number happens once a new validator is to be onboarded.

The irregular joining scenario is only possible if a validator doesn’t communicate with the team that they intend to unstake, hence leaving the slot empty.


PIP-4: Validator Performance Management is live for voting on Snapshot!

The community will now have a week to accept or reject the proposal.

Following the feedback received on the forum and elsewhere, we’ve decided to remove a contentious proposal in part C to unstake two validators who have joined the network in an irregular manner.

We are excited to see this vote as a major step forward for decentralized governance of the PoS chain.

1 Like

Hey All,

I wanted to share some thoughts on the set increase to 105 addressing the comments from @Flamingo and @Matt-BlocksUnited.

The Polygon POS chain currently holds $2.05bn in TVL and has matured significantly as an ecosystem since the mainnet launched in June 2020. Improving the decentralization and security of the network should be the main goal and focus.

The 5% increase in validator slots, as proposed in PIP 4, might have the following benefits:

  • Guarantees ~ 100 active nodes even when some are offline
  • Supports a wider distribution of stake which is required to improve our Nakamoto Coefficient (minimum number of nodes required to disrupt the network)
  • Enables a wider geographical distribution of nodes
  • Increase economic security. To give everyone an idea on why this is crucial: the total stake has reduced by 400m in the previous ~6 months from ~3.0b to 2.6b MATIC.

Hi. Ideas are great, but I personally think new validator selection should be transparent even before it becomes fully decentralized, not like it is done now.