HIP-30: Validator Network Optimization and Token Emission Reduction

Governance Validator DAO
62

How should the reallocated funds be supplied for recovery?

It’s wild to me that we should have a recovery effort without any level of DAO governance…

@lij was one of the biggest proponent of DAOs and while there is some flaws in DAOs they create a level of openness and clarity that allowed for hundreds of people to come together and unite around a shared goal…

and recovery is one of the most sincere shared goals this network has ever had…

The main point of this HIP is : “Validator Network Optimization and Token Emission Reduction”

We have too many Validators based on the fact that we don’t have enough rewards for all of them… so the focus shouldn’t be solely on recovery.

Recovery is it’s own lengthy and complex discussion, requiring great detail to insure it is done securely, with transparency and regard for how the future of the network will survive and thrive.

We need to figure out how to either stop larger validators from eating up so much rewards or reduce the number of validators; or somewhere in the middle…

However we do that… it seems dangerous to be reinventing the wheel if we can adjust our current system to afford the solution we need;
Because we have a large majority of validators running at a loss and eventually that will cause those whom are operating with HUGE stake to become even larger if we don’t act with some level of haste.

So I would propose we break this into smaller increments that we can deploy over a short window of time based on how the first changes effect the network…

  • reduction of total yearly rewards :white_check_mark:

    • earmark reduction of staking tokens emitted to recovery (ONCE we have a secure/transparent way to ensure the funds will not be wasted) :white_check_mark:

  • reduction to 2 shards :white_check_mark:

  • Reduce total number of nodes from 250 (per shard, so 1000 total) to 100 (per shard, so 200 total) :ballot_box_with_check:/:white_check_mark:

  • Limit each node to 1 BLS Key :ballot_box_with_check:/:white_check_mark:

It seems these last 2 are more complicated for the sake of the stability of the network.

It would immediately kick off 500 nodes from the network if we merely reduce the number of shards and reduced the rewards, and that would take some level of resettling to begin with and then limiting each node with a further reduction of nodes and limiting each node to 1 bls key could be tested and introduced after this initial set of changes.

Reducing staking rewards and Kicking half the nodes off the network would result in “Validator Network Optimization and Token Emission Reduction” and would give us a safe and stable pathway to continue to thin the validation of the network in the near future.

IMO we need to break this down into multiple phases of introduction and some of it is clearly more essential and straight forward while other parts are less essential and more complicated to introduce that perhaps thought…

Thoughts?
@ValidatorONE @FortuneValidator @easynode @sophoah @CryptoTech @TrickLuhDaKidz @DKValidator @RoboValidator @Casey

4 Likes
63

Agreed that it’s indeed a complicated matter. We’re dealing with many moving parts. Detaching in smaller parts could be the wisest way to approach.

3 Likes
64

I agree with this. Although it was good to see the larger picture, I believe splitting into sub votes is the only way to pass.

For example I think there is little resistance to shard reduction but more so on emissions and key changes. One validator may vote no solely as they disagree strongly on one aspect, but would have voted Yes on say shard reduction if it were separated. @eddnorris

4 Likes
65

This proposal, as is, is PAINFUL, and could well be a death knell for many of the smaller validators. The recovery IS to fix a self-inflected wound. HOW is the internal team sharing the pain? This should be equally painful to them (like possible salary cuts or donations to share the burden). This should not be “no worries, the delegators and validators can bail us out”. We understand that if the ecosystem dies, no one wins, and are willing to share in recovery, but this is not the fault of delegators or validators. We can’t see what the internal team and decision makers are doing to pull their own weight.

Many great ideas above, but we agree with many that more details and transparency are needed. More examples, facts, calculations, etc.

Capitalism is going to influence people to do what is in their best financial interest, so larger stake holding validators who can get validation to move to new servers WILL do so, if it is more profitable than just running one server. So, we think it’s unreasonable to expect a full 100 unique people/teams to comprise the validators. It will be fewer than 100.

Our biggest issue is serious cut in rewards, which already are unprofitable. You’re asking a big hit, with little transparency as to what happens.

Let’s keep the discussion going and try some more.

4 Likes
66

@Casey Do you have any additional notes for this discussion?

@lij Do you have any notes for this discussion?

If not, Does anyone want to draft a set of alternative HIPs for addressing “Validator Network Optimization and Token Emission Reduction” in stages?

Where we could effectively have several stages which are essential and several options for the next step and take it to a ranked choice vote? @sophoah @theo1 @easynode @CryptoTech @TrickLuhDaKidz @ValidatorONE @here ?

Someone should begin to draft an additional HIP for how these Recovery should be handled if it is going to be funded on the backs of $ONE Token holders and the lowering of Staking rewards (Delegates and Validators)… Anyone willing to take on this task?

The existing recovery effort should be made to be more transparent and require some additional level of oversight for the sake of the optics which the current method is bringing… but that’s another discussion.

GN

2 Likes
67

Agree, to me I don’t think the overall vote would pass. Individual ones like shard reduction for instance could easily pass.

3 Likes
68

to me it doesn’t have to be another HIP. I originally suggested @Casey for the HIP30-1/2/3/4, we could vote base on that eventually.

1 Like
69

for big organization, ie binance, it’s easy for them to build a second/third/fourth validator and delegate to themselves.

It’s only cumbersome for the big validator with real delegators as it would require them to ask their delegators to redelegate to their second or third validator.

The idea is for developer to receive foundation delegation and get them elected. It would certainly be harder for pure and individual validator node runner to simply get elected with only self-funding or would require a lot of hardwork to gather enough delegation from delegators.

Yes that’s the idea but we have yet to come up with the program. And no there isn’t any list of current validator eligible. cc @theo1

to me the main challenge of removing EPOS is the stake imbalance again. Also in your proposal, the rich just become richer. We still need something to limit the earning of big validators.

4 Likes
70

This is why I suggested a limit on max stake. Something like, a validator cannot receive delegation once they attain a certain network stake %

EDIT: Looks like https://harmony.smartstake.io/address/one1qa74rqv4ft8za4ud4j35dmvqardgcwmqfc7dze is making some moves undelegating.

2 Likes
71

I became a validator for Harmony because of its welcoming community. I think this was and should continue to be what gives this chain a large support system. There are many chains with 100 or less validators that are mostly centralized to VC, exchanges, or even their own developers. With 1000 slots open for validators, this chain symbolizes a chain for the decentralized community. It is disappointing to see the developers suggest a large validator reduction when many have retained their staked community , offered free support services, and have operated their node at a fraction of an income from where we were at before the crypto winter and/or bridge hack. I do not support this proposal.

6 Likes
72

finally finished pulling prehack wallet’s current balances
https://chefsoysauce.io/projects/harmony/

if we were to take a snapshot of current wallet balances using locked value and want to make wallets whole (1 to 1):
To fully clear 60,143 wallets plus max $30k for the remaining 273 wallets will cost: $22,765,810.20
To fully clear 60,205 wallets plus max $40k for the remaining 211 wallets will cost: $25,168,134.30
To fully clear 60,240 wallets plus max $50k for the remaining 176 wallets will cost: $27,090,376.54

2 Likes
73

EPoS should not be removed. There are no apparent reasons to remove EPoS even if to choose the way of 1 key per validator (not a key per node, which includes 1 key in each shard).

EPoS perfectly balances effective stakes and will influence the redistribution of tokens among many, not the only one validator.

PPS: do not support the reduction of slots ( even for 2 shards it’s possible to have 1000 slots)

5 Likes
74

I agree with @sophoah here, I don’t think the overall vote will pass. A possible way forward might be to only have a snapshot vote on the shard reduction (4 shards to 2 shards). Then we continue working through the remaining proposed changes.

As for the recovery allocation, if we are to allocate the entirety of the first 220M ONE, in a very basic way, I would split like this:

  • 35M ONE to clear Tranquil Bad Debt and launch V2
  • 92.5M ONE allocation to pre-hack wallets still holding depegged assets (possibly using @ChefSoySauce’s data here)
  • Split final 92.5M ONE with 58M for Aave Bad Debt and the rest to recovery partners (Aave bad debt more difficult to navigate because we need to rely on their governance process currently, if this would fail, we can potentially allocate the same 10% parity to the affected wallets)

Once first 220M has been allocated, transfer emission ownership to a community multisig with community oversight.

There is no current list for eligible validators. But the evaluation will be based on impact on the network, as many validators are not dapp developers themselves, it does not make sense to evaluate solely on dapp creation. Validators often provide guidance for early users and help with the onboarding process. Things from being active on reddit/discord/twitter/forum, creating user-guides, helpful webpages/statistics, will all be taken into account. The priority is helping active and involved validators, not demanding that all validators become dapp developers as well.

As for HIP30-3 and 4, I think more information is needed on the impact of node and BLS key reductions.

This is an interesting take, as the current 6% limit is effective given Binance’s sub-optimal usage. An additional edit here might be to not block additional delegations, but reduce rewards by a % based on the % above the limit instead. Encouraging people to delegate to smaller validators without a hard cap.

2 Likes
75
Increase Validator Minimum Commission (5% to 10%)
  • Yes
  • No

0 voters

76

At this point, I tend to agree blocking incoming delegations is more effective than reduce rewards above the a certain stake. Because if you enforce a roof, in order to keep growing, that validator would need to spin another server, and that would help at the decentralization point. I.e: if binance want to stake all their stake, it would enforce it to either, spin 20s servers per example or delegate to 20 different validators, either way is a win/win for the network. Instead of having a large cex, dumping it all at one validator having meaningless returns.

2 Likes
77

Blocking incoming delegations is ideal but the only issue with binance as an example is they are already staked. In the perfect world we need the limit in place and then for them to unstake for the block to take affect on their own stake.

78

I agree here. We should move forward with a shard reduction vote.

@Casey @sophoah would two shards on this potential snapshot vote be at 1000 slots or 500 or 200? Assuming we are fully external nodes.

1 Like
79

I’m pretty sure the right tools can be used once the need arise. If a proposal like this passes, I’m sure, there will be plenty ways to make it happen.

2 Likes
80

Also, how will BLS key assignment work with two shards?

i.e. currently shard = int(bls_key, 16) % 4

81

That would depend on the slots available to the shards as it’s dynamic.

If it stays at 1k it doubles.
If it goes to 500 it stays the same.
If we go less, it’ll be less.

This thread should get locked down and we should start some specific discussions on proposed changes.

We’ve also got a year after anything goes live before there’s 221m available (if that plan passes and then gets implemented) so it’s kind of futile to talk about what we’d use those funds for at this point when the question was if we should simply route part of the funds to the core team for “ecosystem development”.

2 Likes