IISS 3.1 Structure

[BennyOptions_LL]

In your proposal the opportunity cost associated with a bond is a further deterrent to setting up multiple nodes. In the current system design, the bond will indeed earn delegation rewards. Anything bonded for P-RepA will also be delegated to P-RepA and therefore earn rewards.

Personally I think that in this situation the cost outweighs the benefit, but if you feel strongly we can vote specifically on the topic of whether or not a bond should be able to be delegated.

As for the concept of capacity, that’s already how it is designed, so no need for any extra work or development on that topic unless I am misunderstanding you. We have the concept of “bonded delegation”. Let me know if you are unfamiliar, it was explained in the IISS 3.0 thread

[Emre]

@BennyOptions_LL

If we put a cap on the number of votes a team can get, then literally every team that reaches that cap will simply launch a second node. The second node can easily climb ranks, as the larger node will delegate all rewards to the smaller node. As the smaller node grows, other community members will vote for it. I don’t see how it solves the issue, all this does is force whales to create more nodes, which we don’t want to happen.

If a team own their 100% of their vote yes that’s possible. If they have some votes from the community they can’t. The point I was making is forcing for vote concentration at top to split and make votes equal over certain vote and make it decentralized. If some team self staking fully they can still do that but they can’t keep gaining more power on the network by community vote by retaining their position. Biggest example of that is foundation node having more than 24m vote for their 24m self stake. Something like that force that 24m vote to split to others. Same for non-active votes on top preps. Under these changes foundation also will have more beatable vote power on the network in the long run. Because right now foundation just keeps gathering more vote. I am not about it’s earned or not it’s just not helping decentralization in any way.

[BennyOptions_LL]

You are right that it is more beneficial for whales that control their own ICX, but it would still happen for teams that have maxed out their delegation.

Example: P-RepA is a high ranked community voted team. After a few months they reach the cap. The team for P-Rep A will then deploy P-Rep B. P-Rep A will begin using all future rewards to delegate to P-Rep B. P-Rep B will rise the ranks through a similar process, then they will deploy P-Rep C when P-Rep B inevitably reaches the cap.

Whether or not you think this is a realistic concern is up to you. If you think a cap is the answer, then you can propose that. Come up with a specific proposal and ICX Station can submit it on your behalf since Sub P-Reps can’t submit proposals right now. Then the network can vote on your idea.

[Emre]

@BennyOptions_LL

Example: P-RepA is a high ranked community voted team. After a few months they reach the cap.

I don’t see that as a concern. If you check the numbers I don’t think you will see that way either since the bond is already coming not to mention that takes 333 months with saving up all the rewards not even counting in server cost. 17 year to create a second prep to gain one more vote power is a very long process don’t you think. 28 years to max it and 3.5years to collect 1million icx. If that system got implemented 1million icx will climb them to nowhere. I really don’t see it under any circumstances maybe I am missing something if you want to explain that part.

[BennyOptions_LL]

Alright, these are fair points. I’m going to consider a cap on the percentage of the network one node can receive in terms of delegation. Perhaps the pros outweigh the cons

[Emre]

Yes that’s the case imo. I have 2 approach for that capping. These approach considering 8m icx max cap I come up with after some basic calculations max cap can be anything while system is getting implemented. One of them is over 7.8-7.8 million icx prep having 1 vote. For under 7.8 million icx preps making it 4 million or something like 5-6 million to avoid preps splinting their vote between two preps to duplicate their vote power. Other way is making 7.8-7.9 million icx prep node 2 vote power and making over 4 million vote 1 vote power in this way there is no benefit of split etc. In any of these case any sub with one vote power consider elected have equal say in cbp system and can join node rotation since that amount of vote should be enough for covering their server cost. Foundation also retain 24m split them in to multiple nodes still have high % in every vote on chain without single-handedly dominating it or keep gaining more power by community vote.This way votes get in a way forced but split between multiple parties and including subs over time with rotation as mains will be much easier.

[iconsweden]

@BennyOptions_LL

1.) Direction - that we will have one inflation pool that gets split into the aforementioned buckets

2.)

1: Agreed

2: We like to see some upper limits on voting weight so that there should not be so much difference in voting weights. (We like the idea of ETH 2.0 - though there may be some issues with that)

[metanyx]

As many won’t read all of this due to the wall of text we will summarise our main points

• Fairer Rotation of Block producers (more than just 2, weighted based on vote)
• Rewards for Block producers as rotation means it is not just for top 22 and pays for overhead costs of running adequate server
• Self bond + exclusion of reward of self bond will deter people from setting up multiple Preps
• All 100 Preps should be treated equally and have governance vote

Metanyx Team

[eossweden]

@BennyOptions_LL

Any reward that is based specifically on running a node (flat reward per node, reward per block-producing node, etc. etc.) incentivizes a Sybil Attack. I don’t want to be in a situation where 10 Main P-Reps are operated by 1 entity and we just don’t know. We don’t need to pay people extra money for executing a Sybil Attack. On top of that, now that we are pursuing 3 rotating Sub P-Rep slots, all nodes will engage in block production anyway. The long term goal is to remove Sub P-Reps and only have Main P-Reps. The Validation Penalty (Jail) incentivizes uptime as well. If you suffer this penalty, you face opportunity cost for the term you are in Jail.

Yes, we like this approach. It will also ensure that sub-Reps gets always ready to produce and be active. Moreover, it is great to have 3 rotating Sub P-Rep slots (even better to have more e.g 5). We will even support that blocks production chance should be based on %age of stake/votes (so all P-Reps may get this chance based on %age of stake/votes, not just top 22).