Thanks for your well-thought response. What do i think? I think I’m glad people who are smarter than me are involved! You make excellent points. The tiered delegations or sliding scale seems to make sense, but then there would be other nuances to consider and I’m not sure what those are.
Yeah I think that could be a good middle ground.
Like 1-20 get x% of delegations to split and so on
Or
1-20 has a max cap of x delegation
1 Like
Great! Really hope that it will bring more decentralization to Cosmos Hub!
2 Likes
I have 2 questions:
-
Currently, we have a commission of 12%, with max par set to 20 at inception, over 2 years ago. If we will lower the com to 10 in the next few days will we be able to qualify for the application?
-
Last time (1.5 years ago roughly) when ICF unboded tokens, some validators, like ourselfs (that are dependent on ICF delegations) got kicked out of the active set and members of the ICF publicly said that this should have been taken into consideration. Any update on this?
One more point that might be relevant:
Contributing to bug fixes (github issues) on Cosmos-SDK, Ignite and similar core features.
1 Like
I see a lot of good additions with respect to sliding scales, sharpening definitions, etc.
I have had the luck to give insights in the previous phase already, so I will follow this thread closely with all contributions coming.
Keep 'm coming!
Looks very good. We like it.
Just use clear numbers so there won’t be confusion.
For example:
" * Charge a commission higher than 0% but with a max of 10%"
=> " * Charge a commission of at least 1% but with a max of 10%"
Also sliding scales would be good and more support for the bottom validators.
Support the active validators who deserve it and need support.
1 Like
Thank you very much for this long and detailed post!
Just a little feedback on our side:
It seems that the engineering part Ecosystem and Cosmos Hub is quite redondant on Wallet/Relayer/Dashboards parts that give 6 points when it’s natural to have both of them if one is designed for Cosmos Hub and should be only 3 points given there (or a better adjustment).
Also, relaying works only if done with the ecosystem, but this part is VERY important, so I think giving more points exclusively to it would be more related (2 points only for Cosmos Hub part with the ecosystem, not what’s done in the ecosystem excluding Cosmos Hub)
Dashboard and Wallets are for us not well described.
Wallets should only be for wallet provider => giving the possibility to create and account or use an hardware wallet
Dashboards should be only the front provider part => giving the possibility THROUGHT a wallet provider to use governance or such wallet management stuff
Wallets should have more points, as it’s something crucial for users to interact with the ecosystem
Dashboards can be easily replicate and engage less ressources as it’s only a use of the Wallets without the cons.
Something like 3 points for Wallets, 2 points for Relayers and 1.5 points for dashboards could be more balanced.
On the public good part:
- Offering grants/concrete support for the growth of valuable ecosystem contributors
This part lack of details
Community part:
It seems there is too much points given here.
It is less work and less knowledge needed than engineering part and give more points
- as for enginerring, redondance in both ecosystem and Cosmos Hub part when it shouldn’t give that much points for quite low ressources engaged.
=> reduce to 4 points only instead of 8, maybe add 2 points instead of 1 on more epic task like creating local meetups
Conclusion:
Some points need to be readjusted, not everything should give 1 points, try to separate Cosmos Hub and Ecosystem better (or definitely kick ecosystem and it’s mainly counted by design on the Cosmos Hub), less redondancy by deleting some points (maybe include more things in one line than 2 lines)
1 Like
We have a question from the discussion in the community call (from the first part of the call actually, then the discussion got a bit lost in other topics with Jimmy lol 
). It is mentioned that the total amount to be delegated will be divided by the total amount of points given and then proportionally per validator. We see an error here, since validators outside the active set will be able to apply, there will likely be a lot more applications than the 155 eligible validators in the active set. So from all the applications will only the top 155 by points be considered and then the method applied only to these applicants?
There are two issues that many seem to agree with as well. Firstly, that 1 point is given equally for all projects, but some projects have a very different amount of efforts/costs involved, so this equal point allocation seems unfair. Also, the sliding scale, not only because smaller validators need the delegation a lot more, but because the big validators have a lot of resources to invest in many projects so they have an unfair advantage to get more points.
Another issue is that some companies or projects whose core business is not validating, are using their brand name in Cosmos to launch validators. I think these entities should also not be eligible, and even less being able to mention things built on their core business as projects to get points for the delegation.
1 Like
I would love to know if and when there is going to be a call dedicated to the discussion of the policy. Seems like yesterdays call had a very different agenda. Thanks guys
For sure there will be another call, but probably after that the final doc will be released.
To be fair, at least 45 mins were about the policy :3 I kept trying to bring validators on stage for the whole call, but almost none was accepting. I would also like to remind people that community calls are about everyone and, with proper limitations, all should be able to express themselves. Degens are part of Cosmos as well and a healthy laugh sometimes is needed to break the seriousness of topics as the policy was. Let’s be inclusive and open with facts, not just words 
7 Likes
Sounds like a great policy. We need to hire some Engineers at Whispernode to really start making a bigger impact!
Agree with @schultzie that open source contributions should somehow be measured and incorporated.
There is lots of work being done that’s hard to measure, and I want to commend ICF for taking it upon themselves to attempt to do so in a fair manner.
Hello guys - first of all thank you for the draft, a new chapter is about to start in Cosmos.
Some points we’ve noticed when reading the draft:
1/ Very glad to see that community activities are greatly rewarded, this is as much important as Engineering activities in our opinion. Even if you have the best tech in the world, you need people that are able to talk about it, onboard newcomers and help current users. We tend to forget it so thanks to @catdotfish and those who helped to create this first draft.
2/ Validators that are not on the active set can be eligible for ICF delegations, therefore the governance points can be a bit tricky as it would result in 0 point for them in this particular category.
3/ Regarding the shortlist and the different notations, will it be publicly available?
Thank you for the excellent work you’ve done, looking forward to the next community call!
Hi, thanks for the initiative, we are very excited about it.
Our 2 cents of feedback:
The 3 ideas TL;DR:
- Hub validator set is special and unique
- A good validator set is expensive
- Hub validator set decentralization can be improved
Regarding hub uniqueness, we have noticed that new networks that are flourishing have a very different kind of validators than the hub. When the hub was formed during GoS 
times, most of us came from techy computer science. We find in our set very highly skilled operators coming from data centers, network architects, network security and skilled coders 
What we see now is that new successful validators come from the social media environment. We have validator sets full of youtubers 
, podcasters 
, twitters … 
It is natural. They have a great audience. Unfortunately, despite the fact that they are learning fast and the hard way, the average validator set quality of new networks is far from what we have at the hub. Not a problem when networks are running smoothly. But what we objectively observed is that they tend to double sign at the first chance the network is in difficulties 
. We have seen this repetitively on many network events recently.
This is especially important to consider now that we are talking about shared security. From our point of view the hub should not afford to lose any of those skilled validators. In that sense, we suggest to give to our OGs the importance (the points) that the hub deserves or even an extra to keep them tight.
Point 2 is very related to the previous one. Good Sys Admins are expensive. The industry values the calm they provide. The life of a good Sys Admin should be as boring as possible. A good job of a good sys admin is difficult to appreciate. You only notice it when systems fails. When everything is under control it seems that we, the admins, are doing nothing. But it is totally the opposite. If they are like a fireman running from one place to another or if they are noticed too much then they are doing something wrong. We also observe this on internal networks chats when networks are in difficulties. Newcomers use to flood the chats with their excitement and lack of expertise on moments where we just need calm, listening to the core and proceeding with cold blood. If the budget for those current good admins gets reduced significatively we are under the risk that teams start hiring cheaper admins to do that job. If we pay them peanuts we will have screaming monkeys during crisis moments. On a first attempt I would do the points math to ensure at least a couple of good sys admins positions for each valuable OG validator that the ICF would like to keep onboard. Let’s say $3k / month each or so. This budget would ensure a good shared security for the upcoming hub v2.0
Point 3 just means that we celebrate the idea of distributing the ICF stake avoiding top validators. We never understood that in the past.
We also appreciate that the first draft gives importance to social engagement. Talks, meetups, workshops… these represents a great value for the ecosystem. I personally value them more than “trading focused” channels where the audience is captured but not educated.
Thanks for this great job 
We feel very in line with the message that we read between lines of this initiative.
1 Like
Thank you to all those who contributed to the draft of the delegation policy. Really happy to hear that there will be new delegations to validators!
My overall concern after reading through each of the criteria, is that it seems that more established and financially strong validators might be rewarded by the re-delegation while less established and smaller validators that actually need the support are punished by lesser points (lacking wallet, dashboard, and explorer requirements). I would like to suggest a few ideas that would make the final considerations a bit more fair:
- measure validators based on their past performance in running the validator and the overall ‘health’ of the validator (% uptime, signing checkpoints, % commission, slashing history)
- identify which validators are growing and contributing to Cosmos, yet need extra support to build out and contribute more such as building a wallet, etc. There should be different categories and allocations to consider for the different validators out there.
- the point values may need to be reconsidered, as ‘Translating Cosmos documentation in a local language’ may NOT weigh the same as building a ‘Cosmos SDK Chain’
I would appreciate if you can elaborate on:
-
[quote=“catdotfish, post:1, topic:7153”]
Provide valuable tools that enchant and empower the Interchain community
[/quote] -
elaborate on what ‘Explorers’ are for the ecosystem and Cosmos Hub?
-
elaborate on type of content that is required to be published. once a week seems extensive (but also depends on what is required, and how content heavy)
I hope this helps bring some value! Look forward to the revision & hearing the updates.
I wholeheartedly agree with @derfredy 's points in New ICF Delegation Policy ~ Draft - #35 by derfredy regarding the transition in technical expertise of validator operators from expert to beginner, and that good sys admins are expensive. OGs should get a point.
I know several validators that don’t use sentry nodes. How are you going to measure
- Mandatory Criteria for Selection
- Security of the infrastructure?
There’s no excuse for being slashed. Any validator that has been slashed should not be eligible for the first round of delegations, just like one of the criteria for maintaining an ICF delegation.
Including wallets, dashboards, and explorers in two categories doesn’t seem right, IMO.
I put some thought into an algorithm for distributing delegations. The authz module could be used to redelegate as frequently as a monthly basis and would entirely liberate multisig signers from the tedium of manual delegations. The algorithm would use strictly objective metrics to determine the delegations, which would minimize complaints to the ICF. Of course, all ICF ATOMs allocated for delegation wouldn’t necessarily need to use the algo, but, say, 40% could and the remaining 60% could use subjective criteria. Let me know if you’re interested in talking about a delegation algo.
I know that the business of (fair) delegations is difficult. Thanks to everyone that contributed to the draft!
Hey, so, I think that this policy is better than no policy.
I also think it is likely too complex, with the points system, and likely undervalues engineering work.
No mention is made of audits, security reporting, etc – and I am concerned that this can lead to a passive validator culture.
flip side of my criticisms
There is immense and real value in community building activities. These were also undervalued under the old style.
therefore
We should proceed with this, largely unchanged, maybe fixing the line about centralized organization or custodian (notional is 100% centralized, and I think that most validators are).
with a single caveat
I think that it should be necessary to at minimum declare that you’re not using a white label/third party service in order to qualify for delegations. Personally, this year I made it alligation to a user of a white label provider and even though the team I delegated to is very transparent about this practice, and I don’t see their practices in specific as harmful to the networks they validate, I must honestly say that I likely could have chosen better.
ICF should exclude users of white label providers from delegations, and this would cover validators running their nodes with Coinbase cloud, for example.
ICF should-- like the ethereum foundation – encourage at home and in office validation. Having a truly diverse validator set in locations all around the world makes the hub more secure.
1 Like
Finally, here we go!
Many thanks to everyone who took the time to contribute to the new Interchain Delegation Policy.
I am truly deeply moved by the support you have shown us, and proud to be part of a community that firmly believes that the heart of everything is the word [collaboration].
I look forward to taking the steps to this next with you and together expanding the reach of Interchain beyond all limits.
Delegation coming before EOW!
Cat 
6 Likes