I very well support this idea it will give a lot of new validators hope on getting elected! it is really hard getting elected there are people who delegates with my validator then undelegated because they are not getting any rewards i did all that i can to tell my delegators to stay with me but they still decided to go with the big validators with big rewards. I am very well prepared to go the testnet to show that i am very well prepared.
3 Likes
Hey SNC glad to see your Validator back up 
1 Like
Is there an ETA for the new 1.35/0.65 bound?
1 Like
we are still looking into the second parameter to add, or maybe just start with extended bounds and add the other one later on. For now the first one to go out would be the 5% min fee proposal, which should be created on the governance app monday/tuesday next week
2 Likes
Im not sure if anyone else has noticed, but the EMS has gone down recently. Some ONE has been undelegated across the board, but i do not think that this is the primary reason. There have been more large validators fighting for those ābelow lower boundā seats so that they can get extra rewards for their delegators. What this tells me, is that we need to address large validators parking above EMS. This is not the way. I am strongly against anything that will encourage larger validators to fight for spots above EMS, as it will eventually create a runaway EMS scenario, and make the hurdle to become elected for new validators even higher.
What I would propose instead, is a simple incentive for validators with fewer than X BLS. The downfall would be that this would also encourage large validators to consolidate BLS, and increase the EMS as well. Because of that, I dont think that this is the solution.
Alternativelyā¦ we could incentivize a band in the middle. My proposal is thus - 1.15 * EMS through .8 * EMS is incentivized by a +0.5% reward bonus. The remainder of the band would get a -0.5% reduction. (1.35 * EMS - 1.15 * EMS & .8 * EMS - .65 * EMS) This will ensure that the bonus isnt large enough to make a large difference, but encourages competitive validators to stay near EMS, with it weighted slightly downward, encouraging the EMS to shrink as time goes on. The hurdle for new validators is quite large right now, as it takes nearly $1 Million USD in order to get elected. (Current price of ~$0.18 * 5 Million ONE in delegation used to make this calculation) I feel that this change, along with de-incentivising anyone below the lower bound and increasing the Upper and Lower bound to 1.35 & 0.65 will accomplish the three things which need to be addressed, in my mind.
Those 3 things are:
-
The need to make the bounds larger, so that a new validator with 1 key can safely grow to the point where they can deploy a second BLS key, and remain within the upper and lower bounds. (Handled by expanding upper and lower bound to 1.35 * EMS & 0.65 * EMS)
-
Encourage the EMS to move DOWNAWARDS, not UPWARDS. (Handled by weighting the band of increased rewards to the low side by an extra 5% - 1.15 * EMS through 0.8 * EMS)
-
Ensure that no one takes a dive to below the lower bound, on the off chance that a large amount of BLS open up, and slots are available below the lower bound. (Handled by completely de-incentivizing being below the Lower Bound)
Thank you for reading this proposal, and being part of the process! This is what decentralized governance looks like!
I know that here are some who will not like this, as it creates 3 bands, and thus adds complexity to being a validatorā¦ that is why i propose to keep the bonus low. I am not opposed to reducing it further, down to something like +/- .25. If someone is delegating based upon reputation, the difference will be marginal, and thus not necessary to be tracked. It will only really effect those who want to be competitive, and earn the best possible rewards for their validators.
2 Likes
I feel that Mindstyle is correct, and we should remove the incentive the be below the lower bound. Even with expanding the bounds, Validators will quickly expand their amount of BLS, and be prepared to jump below the lower bound when it is available. By expanding the Upper and Lower Bound to 1.35 * EMS and 0.65 * EMS, this will reduce the likelihood of seats being available below the lower bound, but wont get rid of the potential entirely. If we have seats open up below the lower bound, why shouldnt a validator with only a little delegation get electedā¦ even if only for an epoch? I have created this poll to provide everyone the opportunity to give their simple feedbackā¦ with either a yes, no, or i dont really careā¦ gotta have SOME fun! =P
Should we remove the incentive to be below the Lower Bound?
- Yes
- No
- I donāt really careā¦
0 voters
Instead of incentivizing or deincentiving validators, we should incentivize delegators by giving them a return boost for the first x amount of epochs a validator is elected for the first time or first time after so many epochs of being unelected or delegating to lower bound validators. This could push delegators to leave higher staked validators for lower ones or time it could help even out the staking landscape, if youāre delegated to these rewarded validators though, undelegation period increases to a high enough number to prevent people from hopping around too much.
2 Likes
Before I vote on that @OgreAbroad, Iām wondering if a fourth band has been considered. Itās just a simple thought at the moment and a twist on your previous post, but I figured I throw it on the table and see if anyone likes it, hates it, or wants to burn it with fireā¦ Have we considered a fourth band? The idea is this:
-
Large validators want the ability to earn extra rewards for working extra hard. Some incentive to stay competitive across epochs.
-
Smaller validators want the ability to enter election without getting kicked by the larger folks who spin up keys to reach the bottom.
In my head Iām picturing:
LOWER BOUND - EMS *.65 and below (or similar)
- Benefits validators running a single key. This gives delegates incentive for staking with new validators into election. āStake with the small guy and receive a temporary boost in rewards.ā Prevents larger validators from coming into the lower bound.
STABLE BOUND - Above Lower Bound / Below Target Bound
- No benefits provided - this is the safe zone.
TARGET BOUND - EMS * 1.25 to EMS * 1.35 (or similar)
- Benefits validators running more than one key, but incentivizes a lower key count. Smaller validators will have a hard time staying in the range compared to larger validator. Gives larger validators a ācompetition zoneā without the stressful worry of getting kicked out of election if they under-bid.
HIGHEST BOUND - EMS * 1.35 and Above (or similar)
- Similar to our current upper bound. Validators are punished with reduced rewards.
ā Like I said, far from fleshed out of an idea, but it accomplishes pushing large validators away from the low bound, rewards delegates for staking with newly elected validators, and provides a safer competition zone for those who want a boost in rewards. Weāre simply bringing the āsweet spotā out of the lower zone and sandwiched between two others, and making it so it benefits 2+ keys while the lower bound benefits those with only 1 key.
3 Likes
Adding to my previous post, I personally wouldnāt mind getting rid of reward boosts altogether, or keeping it more simple. For example, minor reward boosts for validators with high uptime and staying in a higher band for longer. Iām just trying to think of what works for everyone, and Iām starting to think that might be improbable.
1 Like
ive read it and its def interesting, but its a big change and we arent sure if it will work as expected. So for now i would be keen on just enraging the bounds and getting rid of under lower bound incentives. After that gets implemented, we can see where it goes.
1 Like
Cool beans. Letās do it!
1 Like
Regarding removing the incentive for validators below lower bound, I have following thoughts:
-
The original design for this incentive is to make sure that the majority of the stakes are not concentrated on a few top ranked validator keys. If it happens, it will cause imbalance of stakes on keys within the shards, thus reducing security and stake decentralization in the shard.
-
I donāt see many validators are fighting to get the slots below lower bound (which rarely appears in this competitive market). And even for those who do want to bid for high-reward slots, there is a good chance that his bid will be outbid by others and eventually lose the election and reward for a whole epoch. So itās not risk-free to so do. In other words, there is already a disincentive in place to counter the incentive to bid for below lower bound.
-
Our goal is to lower the barrier for entry for small validators without affecting too much on protocol-wise security or incentive model. We have many other changes we can do to achieve that such as the 1.35/0.65 change, and also increasing the external validator slots beyond 640 (which we are planning to do soon), which is more effective in achieving our goal. This specific proposal seems going a bit far on the protocol design and may potentially affect the security of the protocol.
So overall, I donāt think this should be implemented at least at the current stage.
4 Likes
We had a private chat with RJ about disincentivising lower bound and I agree with him, that the proposal should just go forward to voting without this part, so just extending the bounds, which should already help out a lot. Later on, we can see if it works or if it will need a further change, such as disincentivising below lower bound.
1 Like
agree with RJ, I donāt feel a strong consensus to remove the incentives for validators below the lower bound.
1 Like
Agree. I think itās soon to make protocol changes until we see how it goes with more external slots
I agree, letās do it. very fair and vaild point.
1 Like
Already being voted on!
If youāre a Validator, Head on over to:
Https://governance.harmony.one and cast your vote!
If youāre a delegator, make sure that your Validator is voting!
I agree. What more do we expect to do.
This is also one possibility yes, but i think this one should be added as a separate proposal to be discussed in this forum. Please make a thread for it
1 Like
AnyONE can start a thread, and propose a change. 