Validator checkpoint signing stake power adjustment

Status: Draft

Abstract: We introduce a new way of weighting stakes where lower stake validators, including delegation, have a higher weight per 1 Matic staked. Instead of signing checkpoints on per Matic staked basis, we use curve-based staking power, where a lower total stake yields a higher relative power.

Motivation: Delegated Proof of Stake networks tends to cluster stakes around the few largest validators and leave the rest of the network as a “dust”. It leads to security issues when Sybil attacks and cartels become increasingly more likely to appear. A new method of adjusting signing power will mitigate some of the power from the biggest validators in the network.

Specification: Current implementation maps 1 Matic to 1 unit of power, and this is a core of the issue because the user has no incentive to stake to low stake validator, and most of the users flock towards popular options, increasing centralization of the network.

In order to fix that, we adopt Uniswap price equation x * y = k for the stake to the shares map function.

Define stake_pool * shares_pool = k, where k is some predefined constant. Now when user stakes, increasing stake_pool, will decrease shares_pool accordingly, so k stays constant. Because of that, the conversion rate of the stake to shares moves on a curve, defined by k.

With that in mind, a new way of staking will be based on shares now rather than staked tokens, and distribution of the power will be on per shares basis rather than a staked tokens.

Pseudocode and algorithm for stake/unstake

struct StakeState {
   uint shares;
   uint sharesPool;
   uint stakePool;

mapping(uint => StakeState) stakeState; // validator id => StakeState
uint totalShares; // tracks how many shares in the system.

function toShares(amount, poolIn, poolOut) {
    return amount * poolOut / (poolIn + amount);

function getRequiredShares(amountOut, reserveIn, reserveOut) {
  return reserveIn * amountOut / (reserveOut - amountOut);

function stake(uint amount, uint validatorId) {
   StakeState state = stakeState[validatorId];
   uint shares = toShares(amount, state.stakePool, state.sharesPool);

   state.stakePool += amount;
   state.sharesPool -= shares;
   state.shares += shares;

   totalShares += shares;

function unstake(unit amount, unit validatorId) {
   StakeState state = stakeState[validatorId];
   uint shares = getRequiredShares(amount, state.sharesPool, state.stakePool);

   state.stakePool -= amount;
   state.sharesPool += shares;
   state.shares -= shares;

   totalShares -= shares;

// check if 2/3+1 holds using shares
function commitCheckpoint(uint256 reward) {}

Rationale: The design choice uses a diminishing returns effect. And to control it Isoquant curve is used. By lowering down the amount of power validator gains with each extra Matic staked, we can mitigate some of the power of the biggest validators into the hands of lesser ones.

The choice of the curve is very important to define how fast power per Matic drops. To take a view of different curves visit this spreadsheet (click-me).

Here is a model of the power distribution using current and new approaches. Go to the model (click-me).

Backwards Compatibility: Shares approach would require us to run a special function to convert validators’ stakes into shares just once. Old variables will be untouched, and in case of some unpredictable behavior, implementation can be reverted back to the old one.

Security Considerations: Shares approach is the same as current, with the only difference - curve-based conversion of stake and shares. Changing the curve at any given moment is possible, and will require re-purchasing and resetting the per-share reward counter and should lie within the block gas limit for all validators at once.


  1. Any alternatives considered? Yes, there are other approaches, mostly based on distributing stakes by the network itself, like Polkadot and capping the maximum stake of the validator like Harmony for example. Polkadot option is not viable for us, due to the inability to execute it on the smart contracts. For the Harmony approach - we will get back to it later with adjusted rewards system based on stake shares.
  2. Does this change decrease my existing rewards? No.
  3. Is it possible to get less MATIC out than I put in? No.

Initial reaction: I get the motivation, but I have mixed feelings. Delegation isn’t very liquid today due to the long unbonding period. I am sure a lot of delegators will be very unhappy if their APY can be ruined by some whale joining the same validator, and there isn’t a way to move their funds to another validator that has less MATIC staked.

I think for this change to work, we need to figure out a way to let delegators jump between validators quickly. I understand that it is quite complicated due to the potential fraud risk, but it’s not impossible to fix, we can still slash funds as long as their funds are still staked.


I totally agree that the illiquidity of the stake is a problem! I will take a look at how that could be possibly solved.

1 Like

Agree with Jim. There should be an easy to move option between validator without the need for a unbouding period. I personally believe the move stake option will surely help to distribute the power between validators as the delegators will try to switch from one to another when there is an issue. Currently, delegators are going with big name validators even if they charge a high fee as they are afraid that if something goes wrong in future, the switching of the validator is time and money consuming!
I believe delegators will try the new validators of having lower staked tokens if they have a easy switch option between validators!


Is it possible that someone creates a lot of validator nodes in order to keep his total APY high? Or even to create a cartel and to token the network?

I agree that your solution makes sense because there will always be pools that are larger than others based on commission and performance to which delegators will congregate. However your solution should be implemented together with improvements on unbonding periods and reduction on cost of staking which also affects ability of stakers to restake.

Smart question. I’m curious to see what’s said.

The Polygon Network is currently limited to 100 validators, so it would be just as possible for one person/group/organization to create multiple validators today as it would be if this proposal is approved.

Could someone do it to keep their APY high? Yes, but they’d have to force out other validators through Auctions, which I would think will get expensive as the Network gets more mature.

Could this lead to Cartels? I think cartels would be possible in both scenarios for a variety of reasons.

First, this is a great idea, and one I am certainly onboard with (given some possible implementation changes, explanations, etc). Distributing the amount of stake is great for validators and for the network as a whole. We have a lot of smaller-named or individual validators that, in my opinion, can be (are) overshadowed by well-known players (not that it’s inherently a bad thing to delegate to a big name validator).

A few questions I have reading this. You discuss a lot on how the would impact the staking power for the validators, and imply a bit for the delegators, but how does this impact delegators (if at all)? What incentive is there for a delegator to switch validators?

Looking at other blockchains in this space: Cardano uses diminishing rewards for overdelegated (saturated) validators. This could work for Matic, where delegator rewards start diminishing after a validator reaches x% of total Matic staked. I wouldn’t think it would take much, even a worst case scenario of 90% of expected rewards adds up and would incentivize diversification.
Tezos uses the validator’s self-stake as the deciding factor for how much delegation a validator can receive (a validator could only receive x times as much as they stake themselves). I don’t like this as much, because it puts the bias back on the larger validators that can afford a large self-stake, but wanted to throw out options.

As others have mentioned, if we are going to incentivize (or highly recommend) delegators to move between validators, we should implement a way to do it without the unbond delay. I assume this is technically feasible since it was implemented to move delegators from the foundation nodes to the community nodes.

1 Like

Diminishing returns on rewards is the next step using shares implemented in this proposal. And will follow the same curve-based logic.

I am totally agree with this proposal motivation part, because it is very import to make low validators involved in the validation of Matic chain, just like ETH2.0 supporting lots of medium and small validators. I have looked through the proposed design , and I have following doubts:

1)The shares curve model is cool, but the AMM curve will be very sharp if some whale stakers comes in or comes out. How did you plan to deal with is.

2)After checking the shares Curve in the spreadsheet, I found it does not make notable difference between the Reserve In and Reserve Out, so I think this plan just make a small change about the signing power among different validators. It is not the absolutely equal signing power among validators like Polkadot or Ethereum.

3)This proposal said the staking rewards will not change, so is it means that the this proposal just changes the signing power of validators, but not changes the staking rewards distribution mechanism? If it is really like the FAQ like no changes in the staking rewards, I didn’t see there is a need for stakes to changes delegation between different validators to make higher APY like other comments.

I think this proposal is very good, a healthy and decentralized validators community is very important for the Matic development and chain safety. I will keep following how this proposal going.

I agree with Jim and Wetez and other above. A couple of point after going thru the attached documents here, tough this approach helps smaller validators, the power may still remain skewed in favor of whales. Also, how would a person who delegates know which is the best validator to pick if the commissions being the same.

  1. The whole point is to keep signing power on a curve to diminish the higher concentration of the stake if a whale jumps in and out we expect the curve to behave according to its shape.

  2. It depends on the constant product of the curve how steep it’s going to be.

  3. First step is to change just the signing power and then change rewards distribution.

You are correct, power will be still behind who staked more, but with the curve it won’t scale linearly, skewing it towards the center of power distribution not to the outliers (whales).

Once we implement rewards distribution on curve, users will optimize their returns better, because lower stake validators will produce better APY.

I had a couple of queries:

  1. How are the shares calculated and what is the tipping point?
  2. How is the power calculated?
  1. There is a code for shares calculation in the proposal.
  2. Power is based on shares.

That is very informative.

I wanted to see if we’re now stuck on this topic or if we just need a nudge to keep it alive. I think there does need to be a change in the weighting of validators to help “decentralize” the network a bit more. My question is with a change in power, what exactly does this affect? Does this mean the block producer will be more evenly distributed? Will checkpoint-signers be more distributed as well? If a validator keeps the same amount of rewards, but has to sign an increased number of checkpoints, this could run into funds issues for the validator team as now they pay more Eth to sign checkpoints but aren’t as compensated for it.

When we introduce adjusted staking power, rewards will also be adjusted accordingly.

As I am beeing questioning around I now understand that the “Auction Mechanism” posted on June 7 scares the hell out of smaler Validators. Their reaction is to gather as much as delegators as possible by actually sponsoring them with 0% fees and even promoting this in their Validator names.

What about allowing bigger backed new validators like the waiting Anchor-staking to allow slot 101 and above. More soft capped projects are also choosing this route and I can imagine this will release some stress and bringing appreciation for the ones who invested lots of their time and asset power into the early stages of Polygon.

1 Like