Open Staking: Improvement Proposals

Dear community,

We have heard your concerns about the number of active validators decreasing over this first week since launch. We are currently at 43 elected validators out of a total of 170 validators created. It is extremely important to us that we address the root causes of this problem so that we can foster a decentralized group of validators for the long term.

Let’s work together to see how we can solve this problem. Here’s an outline of what we see as the underlying issues and potential solutions:

Key problems

  1. Minimum stake - the amount of stake needed to get elected is going up, leaving behind smaller validators to start getting unelected, and over time churn out.
  2. Signing issues - Validators (especially smaller & inexperienced ones) are facing signing issues, resulting in low uptime, thereby negatively affecting their future incoming delegation.

Potential Solutions

  1. Increase the EPOS median range from 15% to a higher percentage, i.e. 30%
    • Reasoning 1: A higher median range will allow bigger validators to take fewer seats at a higher stake per seat, opening more seats for other validators. In addition, the cutoff should be lower as there will be no incentive to bid up the bottom seats above median-30%.
    • Reasoning 2: We’ve noticed that the EPOS mechanism actually hurts smaller stakers because they can’t adjust their stake to stay within the EPOS band, whereas larger stakers can. This happens because the larger your stake is, the more evenly divisible it will be into the EPOS band to maximize rewards. While the reverse is true for smaller stakers. Example: I am a small staker with 3M stake, but the median is 2M. If I split to 2 seats, my bids are 1.5M each and I won’t get elected. So I have no choice but to keep my bid at 3M for 1 seat, and receive a low reward.
    • Feasibility: this change will need a hard fork.
  2. Increase the number of public slots from 320
    • Background: Currently, Harmony controls 68% of the voting power and runs 680 of 1000 nodes. We can remove open some of our 680 nodes to the public, but keep our voting power at 68% for safety.
    • Reasoning: This increases the number of seats, decreasing the median and allowing smaller stakers to get elected.
    • Feasibility: This can be easily done with a rolling upgrade.
  3. Helping smaller validators solve signing issues
    • Background: Validators (especially smaller & inexperienced ones) are facing signing issues, resulting in low uptime, thereby negatively affecting their future incoming delegation.
    • Reasoning: If smaller validators have higher signing rates they will have better uptime and APR, making them more attractive for delegation.
    • Feasibility: The long-term solution is to resolve the network layer/p2p signing issues in the pending PR. But in the shorter run, we can support these validators through one-on-one chats
  4. Decrease the limit of seats per validator
    • Background: The current limit of seats per validator is 1/3rd of the entire network, so a single validator can take up to 106 seats.
    • Reasoning: If we reduce this limit, validators will need to create multiple separate validators in order to have the same total number of seats.
    • Feasibility: This change will need a hard fork and will be more comestic in nature than solving the root problem as there is an easy work around.
  5. Change the staking dashboard design to better promote small validators
    • Background: Some have argued that emphasizing ‘Uptime’ rather than ‘APR’ may be beneficial for small validators for example (which we’ve done) and we’ve changed calculation for expected return to use the last epoch so that validators
    • Reasoning: The staking dashboard may inadvertently put small validators at a disadvantage due to its design and emphasis on certain metrics
    • Feasibility: Does not require hard fork
  6. Marketing promotion for smaller validators
    • Background: We can help small validators gain visibility through Harmony marketing efforts. We can also run campaigns encouraging delegators to diversify their stake among many validators rather than concentrate them in one
    • Reasoning: promoting smaller community validators can help them attract more delegation

Process

We know that time is of the essence so we are moving quickly to arrive at a solution quickly. Here’s the process we’ll be following to decide on the next actions to take:

  1. Discuss - Continue the discussion here on the forum for the next 48 hours
  2. Meet - We will host a live meeting on Monday at 1pm PT to go over the points raised
  3. Vote - If needed, we will hold a vote to decide how and what to implement
  4. Publish - Write out details of the changes we will be implementing
  5. Upgrade - We will make the changes and upgrade the network
3 Likes

Hi Nick

It’s great to see that the Harmony team recognizes the issue affecting the smaller validators. I hope you can implement some of the solutions rather quickly. In my view, there is no one solution that will address the problem completely. You may have to implement many of these solutions and possibly others too to achieve the level of decentralization one desires

The biggest problem remains the growth of stakes going mostly in favor of larger operators while the smaller validators don’t receive anything.

Regarding the potential solutions you have listed
1 - increase epos median range - I dont have a firm opinion on this. not sure about it being a helpful solution
2 - Increase the number of public slots from 320 - this would definitely be helpful and can provide an easy breather for many to sustain operations. Having said that, if in a week’s time, the total stake doubles, we may again be in this boat. I am not sure that you need to continue to control 68% of voting power as some of the larger validators are trustworthy/long term associations you have.
I fully support this but this cannot be the only solution as it will just delay the inevitable.
3 - Helping smaller validators solve signing issues - No strong opinions on this. I missed the first two epochs. I have an active-active setup and my uptime is 100%, not sure how prevalent this issue is after the initial pains of first couple of epochs.
You may also want to perhaps revisit the technical specifications and assess if you need to recommend better specifications/redundancy etc. Inexperienced validators might be struggling a bit with the challenge of optimizing the BLS keys every epoch but that is more of a medium term issue in my view

4 - Decrease the limit of seats per validator - i agree with your assessment. won’t address the root cause.
5 - Change the staking dashboard design to better promote small validators - agreed.
Some of the suggestions I have provided in other forums are:

  • randomly sort all eligible validators
  • default view should be all eligible (you can look at my basic dashboard at harmony.smartstake.io)
  • instead of relying on hard numbers related to performance or returns, use buckets e.g. good, average, poor
  • A new validator’s rating should be based on their first epoch and should not be reflected negatively because there are no stats for them in older epochs

6 - Marketing promotion for smaller validators - agreed. smaller validators can certainly benefit from marketing efforts.

Other considerations

  • Team’s delegation (if any) - if Harmony core team has upcoming opportunity to stake, encourage them to spread the stake
  • Delegation Transfer - Many decentralization proponents may want to move their stakes to others but the delegation transfer requiring 7 epochs is a huge deterrant for one and all. A non-penalizing option for moving the delegation can encourage people to move their delegation to another validator and considering the centralization, I only see it increasing decentralization.

Best wishes
BigB @ Smart Stake

2 Likes

Make open staking open for all, i know this put the network at risk because Harmony 680 node can be easily overpowered, to addressed this make network iteration that only the top 320 seats base on stake and uptime has a voting power to maintain that power ratio, wheather we like it or not staking pool will dominate these, unless you impose another law that only one vote per validator not per seat anyhow saying that we have 320 seats but occupied only by at least let say 48 individual validator is deceiving, not really when openstaking becomes open to all, median stake will still get to be imposed but only to have a voting power while rewards will now be equally distributed amongst all validator perhaps a bonus reward for the 320 individual validator taking the seat and rewards can be forfeited if uptime is below 66% and forfeited rewards distributed back to qualifying validator, these will remove any barriers to entry, an open community campaigning for their validator, friends supporting friends and soon. Also, the 7epoch undelegation, if its there to prevent token dump and eventually network instability incase of token price spike, why not make undelegation only 2epochs to be available again for redelegation while withdrawal of these token still be 7epoch, these promote better network activity amongs delegator, also you seriously need to ramp-up support for “no coding skill run validator” just like on Ankr but they are currently disappointing, anyhow lets have reality check here, people who are technically savvy enough about coding is just maybe 10% of our community the rest as normal people(not saying the 90% is not normal) heres my analogy to these, “Smartphones are for Smart People” but dumb people still able to use it despite its complexity, because they put a layer on top of that complexity that people can easily understand, like buttons, clicks, scroll, tap. Final word, gave people something they understand and adoption will just be a bonus

1 Like

Hey Nick,

  1. This one is good. however I don’t agree with bigger validator taking fewer seat. It will all depends on the economical game play. they can purposely targetting on taking more slot to eject more small validator. Reason being is that with the current EPOS logic, as long as your total bid for all your keys are in the range of median stake x 0,85 and median stake x 1.15, your overall earning shouldn’t change too much. So they have no incentives to minimize the number of slot taken.

What if we could introduce an incentives for using less key as possible among that range (15% or 30%) ? For instance keys near the 0.85 would earn much lower reward than those near the 1.15.

I know it is already like that today since their effective stake in between would be different, however I am talking here about adding another layer of logic to increase/decrease the final effective stake and the voting power (derived from the effective stake).

Here is in illustration what I am thinking: let’s assume between the range 0.85 - 1.15 we create 3 sub range:
1/ 0.85 - 0.95
2/ 0-95 - 1.05
3/ 1.05 - 1.15

for each sub range, we applied a new logic to incentivized keys in 3rd bucket ie :
1/ would have 10% of their effective stake being taken away/slashed
2/ nothing will happen for them
3/ the 10% taken away from 1) will be equally distributed to keys in bucket 3)

like this validator will be incentivized to use less key and hence free more slot for small validator.

  1. I have the feeling that it won’t change anything without the proposal above

  2. this is definitely something we have to work on, POPS can surely help the small validator, and P2P issue really need to have a fix applied, SOON !

  3. no added value for me. just a hassle for small validator whenever they hit the new limit, because big validator can just create up new validator and move their delegation around, for small validator, we’ll have to let our delegator know, (please undelegate and lose 10 days of reward, and plese delegate to that new validator …, that is a hassle) unless the re-delegation (wihout undelegation) is existing As you mentioned, it is just cosmetic at the end.

  4. definitely a must to do and should be one of the most prioritized item

  5. definitely a must as well, however, I would as well encourage small validator to combine their fund and unite forces. @Samuel | RoboValidator.com proposed for that a solution I like a lot so I would just copy paste here but credit goes to him:

2 Likes

Nick,

I like these suggestions, and I will suggest another. The maximum stake a validator can receive could be limited by the protocol. The validator can chose less than the protocol assigned maximum, but the ceiling is set by the protocol to ensure a smoother stake distribution curve.

On another note, and this might not be the proper thread for this, but if

“We can remove open some of our 680 nodes to the public, but keep our voting power at 68% for safety.”
actually meant to say
“We can open some of our 680 nodes to the public, but keep our voting power at 68% for safety.”

I have to ask, how is that even possible? If voting power doesn’t follow node or stake distribution, what does it follow?

1 Like

hey @Gaia the proposal you are making is the same thing as limiting the number of keys per validator. Whale can still move those fund under a different validator they manage, so it is just a cosmetic improvement here.

Regarding allowing more keys for external validator, it just a different logic that can be implemented, ie here internal slot would keep the same voting power, but each slot for external validator could be half what they have now.

so let me give you an example:
today we have 680 (internal) / 320 (external), but this is assuming all slot has the same weightage
in the future it could be 680 (internal) / 640 (external), the only difference is that now the weightage for the external slot are halved.

hope that helps.

2 Likes

Increasing number of slots, limiting the amount to be stake and increasing the range from the median, people will look to support other validators if the big ones are already full

3 Likes

Another recommendation that you could assess is:

  • Cap the max limit of delegation to a validator based on their self stake. I understand that this will not be a trivial effort because of the way most validators are setup but it certainly does put a cap on the max delegations one can receive and limits centralization to a fair degree. One of the formula that I see being used successfully elsewhere is, if self stake is 1, total delegation can be 100 (100 * self stake).

I realize it is a disruptive change given that the network is live. Just noting this down here more for awareness of such an option.

3 Likes

Excellent! Maybe some of these ideas could be interesting. Airplane Method - a Harmony Improvement Proposal

Much have been said. Adding my 2 cents here:

2 - Increase the number of public slots from 320 - this will definitely help, but I think we should release the hounds and let the network carry the weight of signing / voting as well, sooner than later. Give them the responsibility to learn to crawl before they run. The UX for the Staking Dashboard is completely separate from the core protocol and can be tweaked to de-emphasize some things (like Uptime) in the early days, and emphasize others (promotions of newly elected validators) at different times

3 - Helping smaller validators solve signing issues - the docs are well written enough and yet we have seen some newer validators struggle with this. We can introduce a coaching plan of some sort, pairing up some validators with others. Mutual rewards will appear over time. It could be just be a pipe dream.

6 - Marketing promotion for smaller validators - mentioned above, “Let’s do this!”

I have a new one to propose, which is
7 - Introduce the concept of Re-Delegations - to help
a) boost the confidence of delegators to be early adopters with an ability to do-over once every X epochs (say, we could throttle the re-delegation assignments to not allow for more than one re-delegation every 7 epochs for the same amount of tokens secured with the newly redelegated validator)… and
b) hold validators accountable - if validators promote themselves as one and then all of a sudden either run a poorly performing node, or raise fees with no notice, or maybe just leaves the network haphazardly, there is an immediate recourse that’s possible. posted the discussion here as well – Staking Redelegations

Thanks again for pitching in your mindshare here and focusing yet again on making Harmony better and stronger over time!

2 Likes

This sounds like image washing, too late, you had a chance to limit the number of keys from the beginning but you didn’t.

Changing the rules is not fair to the current elected validators and my coins are already delegated.

Make another Open Staking (lite) for small validators but this time limit the keys to 1 so autonode can be used.

2 Likes

Very interesting post, I just want to add something to the point number 4) removing multi-BLS keys will put all validators(big and small) at the same page, with the same tools to compete for a slot. Of course big validators can split the keys into new/several validators, but they will not be able to “ping pong” with keys, that is exactly what is killing small validators each epoch now. Multi-BLS keys create competitive advantages to big validators. This was my sincere opinion from the beginning, multi bls keys should be an option only for internal nodes, external nodes should only use one key. This worked very good in P2

1 Like

True 4/16 keys would have been enough per validator ! They gave to much flexibility to “big players” maybe this was the intention ,I have no idea :thinking:

hey everyone there!

inspired by the word “open” in the name of Harmony product #Open
Staking

I don’t pretend to resolve the issues raised relatively to fairness of election in our openstaking by this one message on the forum, also I’m not really sure how technically difficult to implement the idea i’m sending here, but i’d like to try to deliver my thoughts to all are presented dudes on this thread who are caring about the current situation.

Key problem #1 highlighted by @nickw

  1. Minimum stake - the amount of stake needed to get elected is going up, leaving behind smaller validators to start getting unelected, and over time churn out.

For me #Openstaking means that everyone validator, whether it’s a big staker with lots of bls keys or a single key node should be in equal conditions at the bidding stage when slots are going to be filled by validators. Also I totally support the initial design of Harmony EPoS that mentioned here, see an extract below,

This statement definitely suits our tokenomics that has on its aim to go to 0 issuance and incentivizes stakeholders to stake more assets they have on Harmony staking.
But at the same time this statement caused the issue we have right now - only because of this we have big validator with many BLS keys bidding for numerous slots and get them - there’s no problem with that if it’s not so painful for the small validaotrs.

And here’s my suugeston, that I see could be a good start point for finding the solution. What if earning slots will be distributed randomly among all the eligible validators to get a slot, that are participating in bidding. Randomness it’s always fair game for every applicant, and random selection makes OpenStaking really open for everyone - I’d like to participate, I go there, I create validator and stake on it and I play a slot lottery. I can win or can play again next epoch. And nobody can affect that except an random selector (generator) only. But there should be compliance terms definitely, to avoid cases when 10k ONE stake validator can get elected and earn when median stake is about 3 000 000 ONE.

Let me describe a RANDOM SELECTION for Harmony validators

  1. Not to hurt our EPoS design and tokenomics I suggest to code on the protocol level eligibility to be elected not only for the highest 320 stakes, but for unlimited number of stakes that bounded by the lowest border at 0.7 * effective median, which is 70% of effective median stake. This means that all stakes which are equal or higher than 0.7 * median stake can participate in bidding for slots.

This doesn’t mean to change our median gradation. In opposite this opens validators with stakes as higher than 1.15 median and less then 0.85 median be involved into elected and EPoS will work as it designed for yellow, blue and green zone validators.

  1. The next statement can limit the number of bls keys per validator because I assume that all the keys of validator will get slots if the validator is elected (if not and validator can bid for number of slots accordingly to the number of keys, but gets less slots - there should be no limits for keys).

So let’s imagine the model when each validator has 4 bls keys max allowed. this time RANDOM SELECTION comes on the scene and the lottery will choose 320 lucky slot winners. It means that all the validators with stakes from the highest and to the last 0.7*median stake will participate in bidding, but slots will be distributed randomly (4 per validator max in our case).

So, in our case we can reach the desired situation when even 1000 of validators can participate in bidding and get elected. Only 320 keys will win. Next epoch it will be other 320 keys (based on random selection)

You can say that big stakers can create more 4 keys validators and share their stake on them, but it doesn’t mean their newly created validators 100% be elected, because of the random selection.

You can say that median won’t grow, but it’s not true, because in this particular case big stakers are more likely to delegate their stake shares to other validators than to spin up more new nodes. Why? - because more validators for them means more paid instances - more expenses, but doesn’t guarantee their validators to be elected every epoch. So, those who doesn’t want to spend money for extra instances will delegate to other and hope for getting income from different validators.

Quote thoughts “I’m not elected now, but couple of shares I delegated to other validator this epoch could be elected and earn for me.”

As a result you can see how simple randomness election for validating slots makes everyone stakeholder to share their stakes among maximimum possible number of validators, because if they don’t do that their stakes won’t earn oftenly.

No more for stake centralization!

Is not randomness a fair choice for OpenStaking?

Guys, share your thoughts below and comment, probably this solution has hidden stones, that are not obvious for me yet.

Thanks in advance

What I think it should be necessary is the unlock period to set adequately when those small validators would come play.
It could be like betting.
High returns but inestable nodes vs low returns but reliable, failover nodes. There would be no point to delegate in small ones if the returns and probs to be elected are equal than bigger ones. It could be tilted so that the delegator has risky vs stable options to stake.

Hey @nickw :wave: ,

  1. With a fewer seats for big players ,I guess most of them will disagree, they are not here for peanuts !

  2. Even if you open more external seats , like i’ve said in the last hangouts meeting ,having 106 keys allowed per validator ,these seats it will be “swallowed” precisely by the same big players that will add more keys to their validator ! P.S. HashKey Capital & HashQuark have atm 48/48 slots/keys with 270M tokens staked…What it will them stop to not add more keys if they still have space until 106 ?!? Because at the moment we see so many keys ,not because others don’t wanna be validators ,we see this battle because most of this giants want as much as possible better returns and they cant achive this “higher returns” only by having the flexibility of adjusting lots of keys per validator/node !

  3. Here there is an issue ,because wasn’t nowhere written specification about what are the minimum specs recommended for VPS to run the node “especially having keys in shard 0” and from here we’ve seen those users with uptime/signing issues most of them having keys in shard 0 !

  4. In my opinion reducing the keys allowed per validator ,it means also that we no longer encourage validators to run few nodes with many keys and winning lots of slots with less costs. They will think twice if it is worth to deploy another server and create another validator ,because in this case the delegations will have another impact if the validator has no more flexibility to play with the keys. Of course the risk to see validators with only 4keys allowed and max delegation set it will still exist. But this can be somehow enforced in the protocol for example with: 100M per validator minimum lower cap ,you cant have a lower max delegation cap than 100M , is an idea !

Example:

  • Validator 1 “Giant” has 200M tokens , 4 keys allowed per node.
  • Create validator with minimum delegation cap 100M ( cant be lower than 100M ).
  • Having “–min-lower-delegation” can’t be less than 100M or 50M …

Even If the validator decide to start more nodes and to create more validators, having the lower cap enforced in validator creation and only 4/16 keys allowed per node/validator he will be forced to delegate those tokens/spread them on his validator or anyone else validator and delegations will play a huge role now in this case if there will be no more flexibility to play on a single node/validator and of course there will be no more issues with “giants” receiving only them delegations ,because they will not be able to adjust so easily the staked amount with only 4/16keys allowed per validator and a lower cap that cant be controled by “Validator’s Creator”.

So my suggestion here is 4/16 keys per node max and “–min-lower-delegation 50M/100M” to give majority of the decision to delegators ,if in case the user/entity/partner decides to start multiple nodes/validators because he will be limited by 4/16 keys and having a big bag, wanting to win more slots he will see an opportunity in running more nodes/validators but of course with the minimum cap this it will be somehow filled by someone else if not by himself.
Therefore, the free will “delegators” will dictate in this way the game and not the user/entity/partner with their tons of keys !!!

Adding to point 4:

Median stake 1.5M

C7 Creator 100M tokens available

V1 created 1 node / 4keys with self stake 10K and delegate from other wallet 6M split on 4 keys, he stays in median with bidding for slots and in better returns with good APR ,has space left for delegations but he decide to set --max-total-delegation for V1 to 6M and it will keep adjusting this with more tokens available because it cant adjust it from keys. So ,he creates another validator V2 with same requirements.

V2 created 1 node / 4keys self stake 10k delegate from other wallet 6M split on 4 keys, he stays in median with bidding for slots and in better returns with good APR ,has space left for delegations but he decide again to set --max-total-delegation for V2 to 6M and to not allow more delegation and it will keep adjusting this with more tokens available because it can’t adjust it from keys.

So, how can we avoid this ? Simple !!! By enforcing in validator’s creation “minimum lower delegation” meaning that your max total delegation allowed can’t be less than 50M/100M let’s say, and in this case even if the Creator starts another node and creates another validator ,on previously validators created he will not be able to have the node running only with his own delegations and set it to max delegation for holding multiple validators capped on his desired delegation setted and not allowing other delegations from delegators, adjusting his tokens to stay in median and of course winning more slots with different validators.

We can avoid this with “minimum lower delegation” set to 50M/100M and only 4 maximum 16keys allowed per validator, because the space left it will be filled by other delegators if not by himself and a single delegation made ,let’s say 500k tokens ,can change his APR and next delegators seeing this will move on another validator with better APR and so one , until at some point without a huge flexibility with lots of keys to be able to stay always in median it will create a balance among validators and similar APR for most of them. Therefore no problems for smaller validators because most of delegators look only for “Giants” who has lots of keys for better returns. The dynamic it will change a lot if we lower the number of keys per validator and enforce the max total delegation to not be less than 50M/100M letting to much space for Creators to create lots of validators if they can’t play anymore from keys !!!

  1. Tbh nobody cares about “Uptime” only the validators…Delegators will always look after better APR ,but implementing what I have specified on 4th point can change very much the game if the user/entity/partner who controls the validator it will no more have so much flexibility with tons of keys. The delegations will have a huge impact on APR in this case ! Also I see very dynamic the APR changing and then delegators will definitely look and on other validators , because those with higher stake ( 4 keys only ) at some point will go above median and others will look on smaller one’s until the APR stabilize for everyone :wink:.

  2. Of course we can encourage and promote them , I don’t see a good idea in creating “pools for them” if this is the idea but yes more improvements can be done here !

  3. This is own observation ! “Lukas Drama” is actually “Delegators Drama” because the tokens of this users especially now when we have almost 2 days lasting 1 Epoch and 7 Epoch unbounding period ( 12-14 days at the moment ) are the most screwed and this because, maybe we should have “KYC” for kids or somehow a bigger minimum amount self stake required to create validator , a warranty “longer unbounding period for the amount required for creating validator” maybe pegged to usdt pair because someone said: why minimum 10k tokens ,what if the token price goes to 1$ , so let’s say ONE worth 500 $ to create validator , tokens blocked for 30/60 days idk ,something what can avoid what we have seen with Lukas. Because tbh most of the user/entity/partner has 1 wallet with 10k tokens for validator creation and makes delegations from different wallet/s and when this “dramas” occur being so lower this amount required for creating validator ,maniacs/users/entities/partners don’t give :poop: on those 10k blocked for 7 epoch ,but delegators suffer a lot from this.

  4. We really need “Re-Delegate” with effect from next epoch to avoid “Lukas Drama” and delegators having tokens blocked for weeks bcoz of kids/maniacs/users when it will no worth anymore to be validator if we don’t get out of mud and earned rewards/costs exceed the profitability !!!

  5. I wonder if we can vote for this in the community :thinking: or among validators/delegators…

A) . Do not allow max delegation lower than 50m/100m
B) . Max keys allowed per validator 4/16 depends what we set at point (1) 50/100.

P.S. If anything else comes in my mind ,I will continue to edit this post !!!

Thanks to all of those who will read this :beers:

3 Likes

How about to reduce undelegate from 7 epoch to 1 epoch. And give a change to new validator to be guaranty elected in next epoch after creating validator. With new validator being elected in the next epoch, delegator can see the new validator APR and they can delegate. After that, the new validator will be still elected or not elected depend on total stake vs median stake.

And every validator which not elected can use --active true command and will always be elected in the next epoch after --active true. And the next epoch will depend on total stake vs median stake

1 Like

So, here some i think and write on telegram group…

The lottery thing its a good idea, and calculate APR and somehow show this even on not elected with uptime its a good idea too, limited BLS KEYS to 4~16 agree, and 66% of median stake to get a chance of winning a seat would be nice too, but i have a feeling its missing ONE more thing… like to increase the chance of winnig a little bit, by calculate the total staking, like if some validator have more than median stake, betwen 10% more staking, the chances of get elected increase like a 1% more, if have 20% more than median stake, incrase to 2% more chance, maybe create something to calculate the chances of winning of each validator

And, somekind of change to redelegate, instead of 7 epochs, just 1 to redelegate and 7 to withdraw.

Sorry for my English, its not my main language.

Have a good time guys!

how about sport.

3 ligas!

1 high level, 2 middle level 3 low level. .

example - per level maximum slots with value:

1st league 70 slots / condition minimum invest 50 million ones per server
2nd league. 100 slots / 10 million - 50 million ones per server
3rd league 150 slots /100,000 - 10 million per server

in combination with the random principle as with sports betting (only vice versa).
big investors get a worse quotas (1: 100) on a win, smaller investors a chance of winning 1:10 for slots

1 Like

I proposed the same with airplane seats in my previous comment, but it’d work with Leagues too! Good analogy.
What is the point to view a competition between the Barça and the Regional amateur football club?
Pointless don’t you think?

2 Likes