New ICF Delegation Policy ~ Draft

Hihi Cosmonauts,

Below is the first draft of the Interchain Foundation’s new Delegations Policy.

First, I would like to thank everyone who contributed to its creation and invested their time in the initial review process.

In particular, a special heartfelt thanks to Syed Choudhury, Lexa Michaelides, Leoonor Bitcanna, Leonoors Cryptoman, Kevin Garrison, Heejin Lee, Hwang Seung-gon, Adriana Mihai, Gavin Birch, and Abra Tusz who passionately helped review this first draft and provided extremely valuable feedback.

Below you will find more about the process we will follow and related timelines to implement this new Delegations Policy:

  • Thursday, 1 September (Today!) - Post the draft of the policy on the Cosmos Forum, to receive the Community’s feedback
  • Wednesday, 7 September (6pm UTC) - Community Call on the draft policy - Cosmos Hub Twitter Space
  • Friday, 16 September - Cut off for feedback from Community on the forum post
  • EOW ~ 25 September - Final version of ICF Delegation Policy is released and the Application form for Cosmos Hub validators goes live
  • Friday 7 October (12am UTC) - Validator applications close - undelegation of all ICF ATOMs (see at the bottom of the post for more info)
  • 8 October - 8 November - Evaluation of validator applications
  • Wednesday, 9 November - Announce the new chosen validators
  • Week of November 30 - Complete all delegations to the new validators

Before you read the proposed criteria for validators, I would like to outline some important points:

  • As of today, the Interchain Foundation has ~11.63 million ATOMs currently delegated. The total number of ATOMs currently held is ~14 million. The target for this round is to stake 70% of the total held, keeping the remaining as liquid for operational costs (admin costs, grants, etc)
  • New delegation rounds will take place every 6 months
  • However, validators the ICF delegates to will be regularly monitored on key performance metrics, such as uptime and governance participation, and the ICF may redelegate or undelegate under limited circumstances before the next round.
  • Validators can apply one month prior to the starting of the new delegation round. If this is a new application, the Validator will need to complete the form in full. If the Validator is from the previous round, it will require a shorter sync with the delegation team to demonstrate that they are still meeting the delegation criteria.
  • To oversee the whole process, the ICF will form a Delegations Team, which will include a minimum of 1 devrel. The team will be composed of Interchain employees.
  • The Delegations Team will evaluate the applications and create a shortlist of validators, including recommendations on the amount to be delegated to each. The Interchain Foundation’s Board of Management will have the final decision of approving the list and performing the actual delegations.
  • Staking rewards will be claimed by the ICF at the end of every round and kept liquid by default. They may, however, be included in future rounds of delegation.
  • Validators outside of the active set are eligible for delegations, so long as the ICF’s delegations will push them into the Active Set.

ICF Delegations Policy

The Interchain Foundation is committed to stewarding the Cosmos Ecosystem by funding and advancing the creation of an interoperable, sustainable, and community-owned decentralized ecosystem.

To that end, our ATOM delegations will consider contributions made not only to the Cosmos Hub but across the Cosmos Ecosystem.

In order to select Validators to receive delegations, the ICF has devised a set of criteria that will help evaluate Validator contributions. Below are the proposed evaluation criteria and a points system.

The number of points a validator receives will dictate the delegation received. The delegation awarded per point will be dependent on the final list of Validator applicants. This will be calculated as the total ATOMs to be delegated divided by the total number of points awarded across all validators.

Validators who submit an application and meet the mandatory criteria for selection will be evaluated using the criteria below.

Evaluation Criteria

#1 Engineering (Ecosystem)
A validator may receive up to 6 points in this section, 1 point for each item below:

  • Wallets: Wallets that support Governance and lower barriers to end-user adoption

  • Dashboards: Dashboards that promote engagement by supporting Cosmos-specific features such as governance, ibc, etc.

  • Explorers: Pages that display ecosystem data, and provide utility to users

  • Relayers: Operators that facilitate cross-chain IBC relaying in the ecosystem

  • Core Stack Contributors: Teams that actively support the development of the core products in the Interchain Stack - IBC Protocol, Tendermint Core, Cosmos SDK

  • RPC Providers: Public RPC providers

  • L1 Builders: Building a Cosmos SDK Chain

#2 Engineering (Cosmos Hub)
A validator may receive up to 6 points in this section, 1 point for each item below:

  • Wallets: Wallets that support Cosmos Hub and Governance

  • Relayers: IBC Relayers connect between the Cosmos Hub and another chain

  • Dashboards: Dashboards that support Cosmos Hub

  • Explorers: Pages that display Cosmos Hub data, and provide utility to users

  • Gaia Repo Contributors: Teams that actively support the development of the Cosmos Hub

  • Gaia IS Builders: Teams that are building solutions based on Interchain Security

#3 Public Good (Ecosystem)
Validators can receive 1 point for each eligible activity/project. The ICF is looking to support teams that are building or providing services that add public goods value to the ecosystem.

Here are a few examples of activities that would receive a point:

  • Payment app integration that supports Interchain wallets and IBC tokens
  • Education platform/docs that will onboard new Cosmonauts to the ecosystem
  • Offering grants/concrete support for the growth of valuable ecosystem contributors
  • Provide valuable tools that enchant and empower the Interchain community as alerts, governance alerts notification tools, scripts, asset management, …

#4 Community (Ecosystem)
Validators can receive 1 point for each eligible activity/project. The ICF is looking to support teams that are actively helping grow and maintain communities, across the Cosmos Ecosystem.

Here are a few examples of activities that would receive a point:

  • Moderate a Cosmos Ecosystem local language community (Twitter/telegram/discord channel), guaranteeing moderation at least 5 days a week
  • Translate significant content / Cosmos documentation in a local language
  • Create community events like Conferences, meetups, or workshops
  • Run local meetups focused on the ecosystem and the Interchain Stack (at least one per delegation round)
  • Promote the Cosmos ecosystem through community initiatives like podcasts, twitter spaces, and youtube shows
  • Provide valuable tutorials that aim to lower the barriers of entry to end users and favor the correct usage of the wallets/application in a secure way, keeping them updated
  • Write and publish valuable content on Medium/twitter/Youtube that aims to highlight the ecosystem (at least once a week)
  • Strong participation in on-chain governance

#5 Community (Cosmos Hub)
Validators can receive 1 point for each eligible activity/project. The ICF is looking to support teams that are actively helping grow and maintain the Cosmos Hub community.

Here are a few examples of activities that would receive a point:

  • Actively participating in the Hub’s governance and helping to shape it
  • Being active in Cosmos Forum and participating in the community calls.
  • Creating valuable content regarding the Hub, its services, use-cases, and value (at least once a week)
  • Give speeches at relevant events about the Hub/organizing events focused on the Hub at least once per delegation round
  • Translate significant content / Cosmos documentation in a local language

Mandatory Criteria for Selection

A validator will only be eligible for evaluation if they:

  • Are not a centralized or custodian entity
  • Are not being paid/receiving a grant for the same work you’re indicating in your candidature
  • Are not in the Top 20 validators on the Cosmos Hub (by voting power) at the moment of the submission of the candidature. The ICF wants to favorite a decentralized and healthy growth and support smaller Validators
  • Charge a commission higher than 0% but with a max of 10%
  • Security of the infrastructure ~ Implement appropriate measures to keep maintain a secure and stable infrastructure

Mandatory Criteria to Maintain Delegations

The Delegations Team will regularly monitor validators on the following criteria.

Depending on the severity, failing these criteria may result in immediate termination of delegations to that Validator, or deselection at the next round of delegations (performed every 6 months).

To maintain delegations, a Validator:

  • Must be active in Cosmos Hub Governance and vote on all the governance proposals ~ at least 80% of your votes must be Yes/No/NwV
  • Must maintain uptime of more than 95% over the Delegation Round
  • Must not increase commission above 10% or decrease to 0%
  • Must not have less than 80% uptime for 5 days in a row
  • Must not be jailed more than once for downtime
  • Must not be jailed for 5 days in a row

About ICF delegated ATOM total undelegation

Many of you have wondered why the Interchain Foundation has decided to undelegate all of its ATOMs instead of re-delegating them.

There are 2 reasons for this:

  1. Practical reason: The number of delegations will be different than past delegations and redelegating would greatly complicate operations. The ICF can delegate more quickly and efficiently if it starts from scratch.
    Additionally, from the end of unbonding to the beginning of delegation operations will be no more than 3 weeks so the impact should be relatively small

  2. Ideological reason: We want this process to represent the start of a new chapter for the Interchain. Unbonding and starting with a clean slate is the first step towards this chapter of renewed commitment to, empowerment and recognition of those who make up the Soul of the Interchain.

18 Likes

Great job, I’m sure this will drives the ecosystem toward a bright future.

2 Likes

Can we strike the word centralized please?

I think all validators are centralized, together we make a decentralized network.

Or maybe it should say “centralized exchange” - not sure intent here.

4 Likes

Many thanks for sharing the initial draft! Here is our feedback:

-For the Public Good and Community Ecosystem/Cosmos hub there is no point limit indication, just that ‘1 point is received for each eligible activity/project’. The big issue we see here is that the amount of time/effort/costs between one project and other can be very different so awarding both with 1 point doesn’t seem fair. Example: being active in this Forum would earn 1 point, and also organising Cosmoverse or producing our bi-weekly videos would earn equally 1 point. I think we can agree the amount of costs/time/efforts differs vastly.

-Also, a community project could be supporting the Cosmos hub, the ecosystem and be a public good at the same time, so how would this be evaluated then?

-I think that big projects in terms of resources required and value added to the ecosystem should be evaluated differently. Projects such as Cosmoverse or our news videos is really a lot of ongoing work daily and huge costs involved, I don’t think big projects like this can be just awarded 1 point

-Also, there are mentions about releasing content weekly, I think this is also a bit misleading. Some may release something weekly like a brief twitter thread done in 30min, while us for example we release the news videos bi-weekly but we are working daily on this researching/filtering the news from multiples sources and preparing the content, shooting several video takes for each section and preparing all the material for filming, and then all the video editing part

-Since validators outside the active set are also eligible to apply, the number of applications may be very high. One idea would be to assign a larger % of the available ATOMs for delegation to validators that have been a long time in the active set and voted for example in +80% of the governance proposals since joining the active set

Looking forward to hearing the feedback from the rest of the Cosmos community!

1 Like

I think this is a fantastic start.

“Centralized exchange or custodian” would be a good change in verbiage.

Would also recommend just establishing a clearly defined minimum (i.e. 1%) for Foundation delegations. I could foresee a world where a validator would say “My 0.1% commission isn’t technically 0%” and sort of nullify the whole criteria.

Other than that… looking forward to seeing this puppy in action!

1 Like

Forgive me, I’m not sure I understand the criteria. We’ve not designed a wallet for the ecosystem. People delegate to our node using Keplr, Cosmostation or Trust wallet mainly. Am I understanding this correctly?

Dashboards: Does this mean if our website had some sort of dashboard our delegators could log into?

Explorers: Does this mean we’d get points if our website had mintscan info readily available on it?

Bravo on the policy overall! I was smiling and feeling excitement as I read through it. Thank you for valuing decentralization and excluding the top 20 largest nodes and 0% commission nodes. Thank you.

We became an ATOM validator in October of 2021 and were jailed for a couple hours because we missed the Vega upgrade in December. Fortunately we upgraded and got back online quickly. My initial reaction after reading, " * Must not be jailed more than once for downtime" was disappointment. We truly felt like it wasn’t our fault since the Cosmos team had no established practice to notify validators. Some of the team uses Twitter, some Telegram, some Slack, etc. Additionally, there’s no email list that goes out to validators to let us know about important events. Everyone has their preferred platform and so information distribution is highly fragmented. I spoke with Lexa and Syed about this. My point, perhaps there should be a forgiveness period where getting jailed drops off our permanent record so to speak. Maybe it could be, “Must not have been jailed for downtime more than once in a twelve month period” or something. Just a thought. We’d love to be forgiven for getting jailed.

Other than that, the policy draft looks great. Thanks again for caring about the ecosystem. Cosmos is by far our favorite project and by far our favorite community.

2 Likes

To see this come out is great!! Thanks to everyone who made this a reality. A few points:

-like mentioned by others, better clarification for the centralized entities

-are white label operations going to be eligible for this? For example, can the provider get foundation delegations for multiple instances?

-a situation where someone has more than one validator, are they eligible?

-will supporting consumer chains, or participating in the ICS testnet be criteria that increases the likelihood/amount of delegation?

-if I have a dashboard on my website for user to stake, does that count? I think we need more clarifications on what qualifies and is expected with this category. And if it was previously grant funded, that’s not eligible right?

-anyone who has gotten a grant for for things they’ve built, cannot use those things in consideration for this? ie RPCs, monitoring tools, and other apps? Is this including grants from any chain or entity? How can we ensure this is fairly/consistently enforced?

-if you’re going to allow one jailing for downtime, maybe make that 1 jailing over a 12 month period or during the delegation period.

-is there a policy for voting from these delegated tokens? What are peoples thoughts on no votes from foundation & leaving that voting power with said validator?

-flat 1 point for each category is best because then there’s no subjectivity that comes into play.

-what happens if someone is pushed into the top 20 from a foundation delegation?

-how do we stop people from just doing things to check off the box? Maybe a maximum amount of points available to give out for categories?

2 Likes

Hi, it’s BlockPower and we translated a Chinese version for your draft delegation policy.New ICF Delegation Policy ~ Draft-Chinese 中文版

2 Likes

With regards to this I believe rather than just blocking out the top 20 you could also delegate using a sliding scale on where where a validator falls within the set/% voting power which would give an objective metric for The Delegation Team to use in deciding the amount to delegate. This could be used in the scoring system where validators lower down the set gain more points or added as an addition guideline to The Delegation Team.

1 Like

This will surely help around decentralization! :ok_hand:

1 Like

Initial feedback: This looks great, we are looking at the details more closely, will share any findings/improvements

1 Like

Thank you for posting this. It looks like quite a bit of thought went into it. We’ll be posting more feedback later and attend the Wedensday call, yet for now, the first comment I have is on the above.

While I support active governance participation being a key criteria, I feel “Abstain” should be included, not excluded. At Chainflow we feel Abstain is a legitimate way to vote, particularly for smaller, resource limited operators. Delegating to these types of operators seems to be at least the partial focus of this program, i.e. “not in the Top 20 validators…(by voting power)”.

Forcing a Yes/No/NoWithVeto vote may force delegation recipients to make decisions they’re not fully comfortable making. Depending on the level of discomfort, some may choose not to vote at all, which goes against the goal of this criteria.

For example, at Chainflow we feel that code audits should be completed by a group of third-party developers from the Cosmos community, i.e. not the developers who built the code. Validators could then choose whether or not to accept the code associated with an upgrade based on the third-party audit. It’s primarily for this reason that we often choose to abstain from votes that are tied directly to code.

Other validators may have other reasons they feel are legitimate and require and Abstain response. While I understand that using an auto-voting system that votes “abstain” by default goes against the spirit of the proposal, I don’t think excluding “abstain” is the way to go. Maybe a middle ground could be to allow “abstain” along with an explanation that describes the reasoning behind the decision to use that option.

2 Likes

I think the answer is no to both those specific questions - IMO of course, it would be the Delegations team that would have to clarify in detail.

But the criteria is saying “if you are a validator, and you also happen to have created a wallet for use by everyone, you will get a point”.

So for example, Cosmostation would have received an Engineering point for making Cosmostation Wallet (engineering project, open to all, not just their delegators); an Engineering point for building Mintscan; and maybe a Public Good point for maintaining Minstcan too. (but of course Cosmostation isn’t eligible for actual delegations since they are in the top 20).

However, that example also illustrates some of the issues @Cosmic_Validator identified:

Building and maintaining Mintscan is a lot harder than another dashboard that shows a few stats. But as it stands now, it does seem like both will get a point each.

And yeh, that’s not fully fair -since the assessment is based on quantitative measures - but how could it be improved? Bearing in mind that the ICF wants to be confirming / redelegating every 6 months, so ideally “subjective analysis” needs to be kept to a minimum, right?

This also ties in with other comments (here and twitter) about having a sliding scale type of mechanism for awarding points - based on validator commission levels or gov participation levels. Personally, in principal, it makes sense. Practically, it would be a nightmare to make it fair right now, and a bigger nightmare to manage it regularly.

I see this is v1.0 of delegations - ship something that is fairer and better than what the ICF has now; keep it simple, so that it can be managed and delegations updated regularly; and once the process is working smoothly over the course of 2-3 six-month reviews, then start adding more complex criteria/calculations.

wdyt?

Again, everything is just my opinion. It’d be the Delegations Team job to flesh out these properly

3 Likes

First of all, thank you to all involved in composing this draft policy, as it greatly helps with understanding what is required to qualify for the upcoming ICF Delegations program and lays out a clear path for all

Just to echo a couple of points already raised:

White label validators: I would like to see white label validators being a reason for disqualification from selection and added to the Mandatory Criteria section of this draft
Reason: we feel white label operators (and any awarding of ICF delegations to same) would go against the whole ethos of this policy

2.) The inclusion of clearly defined MIN and MAX percentage of foundation delegations for each tier and score on any matrix would also be good

3.) Not directly related to this draft, but…
Staking rewards claimed by the ICF could be channelled back into a type of incubation program/fund for new validators.
There is no doubt that the bar will be raised and standards improved on with this new policy (and rightly so!) thus getting into the active set I imagine will become more difficult for the type of newcomer required (and desired) in the validating family that would help ‘decentralize’ the chain more

To promote a more community-owned decentralized ecosystem then having a fund available to identify and support new validators can only be a good thing!?

At Silk Nodes we greatly appreciate the introduction of this new policy and the obvious positive changes it will bring to the Cosmos ecosystem as a whole

exciting times!

3 Likes

Good decision :tada::tada::tada::confetti_ball::confetti_ball::confetti_ball:

Appreciate it.

1 Like

Let’s take an example: a validator ranked 21# is eligible to apply, they are well funded and with lots of resources to invest in building wallets, explorers, etc., they will get many points and likely one of the top delegations, which won’t really have much impact to them since already well funded and large validator. In contrast, a validator barely staying in the active set but that is creating huge value for the ecosystem in some engineering or community project, with very low resources, since not enough funds are available to do many projects in parallel then not many points will be received and hence a low delegation. However, a good delegation to this smaller validator may allow them to boost their project and add additional huge value to the Cosmos ecosystem

In 2020 Tendermint re-delegated ~19M ATOMs to new Cosmos Hub Validators and delegations were organised by tiers (100k, 200k, etc.). I think since the top 20 validators are not eligible then the next 20 could be eligible only to the smaller tier let’s say 100k (the tiers will need to be decided), the next 20 to this tier and also the 200k, and so on. In this way, if for example a validator ranked 21# has done similar contributions as a validator ranked 150#, the smaller validators will get a larger delegation. This will improve decentralization and support more smaller validators which need this support more

4 Likes

Are not being paid/receiving a grant for the same work you’re indicating in your candidature

Why should this be disqualifying criterion? First of all, grants are varying in size and often times just enough to cover development expenses and not make a hugely long-lasting profit. Also, grant applicants might have not included support and maintenance of the project leaving small development teams fixing bugs, adding improvements, and updating projects out of pure enthusiasm without any monetary support.

This is a great start!

One point I’d like to highlight is section #1 Engineering (Ecosystem)

I believe there should be an additional section for open source contributions. As an example, we have:

These are all extremely valuable contributions that should be rewarded a point, but don’t fall under the selection criteria.

2 Likes

Yeh, they are valuable tools. If not part of the “#1 Engineering (Ecosystem)” [I think it’s in the ‘spirit’ of that section though], these tools would fall under the the “Public Good (Ecosystem)” category - these are valuable tools.

2 Likes

Love the tiered idea

2 Likes