The Cosmos Hub Governance Experiment: An Overview

Published in

Simply Staking

8 min readMay 2, 2019

The Cosmos Hub mainnet was successfully launched on the 13th of March 2019 (or the 14th if you’re lucky enough to live in sunny Malta as we are), following years of development. The community has been very active and the developers hard at work to push the network forward, culminating in the network upgrade allowing for the transfer of ATOMs. With this significant milestone behind us, we wanted to take a moment to reflect on the governance related events of the past weeks, try to identify some lessons learnt and suggest some ways in which the community can improve moving forward. The discussion of the actual governance process is not the scope of this article, but a great overview of the topic has been written by Chorus One.

TL;DR

Governance proposals have been mainly used as a signalling mechanism and the community does not have any actual requirement to follow them to the letter.
Proposals are only actively discussed after they are submitted for voting, at which point they cannot be amended.
A high voting turnout has been generally observed, but we believe that the quality of the proposals needs to improve if this high turnout is to be kept.
We propose a number of ways in which this might be addressed, namely varying proposal types and the setting up of a working group.

A brief history of governance proposals

Just one week after the launch of mainnet, the first proposal was put up for voting by the community, with the aim of bringing the inflation rate closer to an annual 7%. This proposal found the community to be in agreement with over 80% turnout and nearly unanimous voting in favour.

At around the same time, following talks between Simply VC and iqlusion, we were confident that the development of the upcoming release by the Tendermint team was progressing nicely and it could be used as an opportunity to enable transfers on the network. So, we wrote a proposal in this regard and, following a brief period of open discussion, put it to a vote.

The community initially seemed to be mostly OK with the proposal, until some issues started being identified. Mainly that a single proposal was too limiting because it gave Tendermint too much power to include any changes that they wanted into the release. On top of this, the fact that a specific block at which to perform the upgrade was specified in the proposal led to concerns around the inability of validators to actually vet the programs they were meant to run. The proposal was rejected with near unanimity, with a very high voting turnout of over 90%.

To rectify this situation, Simply VC and the Tendermint team discussed the feedback and agreed that a new proposal should be submitted, with the aim of addressing the community’s concerns while at the same time minimising the time required to enable transfers. This was done through the removal of a specific block height at which to upgrade the network and the requirement of a second proposal to be submitted indicating the exact software to be used for upgrading. This follow-up proposal would make use of an expedited governance rule that allows validators to agree about a proposal without having to wait for 2 weeks, which elicited some discussions around setting a precedence around the rule. However, the community was generally happy with the proposal as evidenced by the 90% votes in favour. Again, the turnout was very high at more than 80%. It was interesting to see that some delegates used their right to overturn their validator’s vote.

The network upgrade eventually happened after the follow-up proposal was voted on using the expedited governance rule. There were some objections here as the proposal had some minor faults, such as an incorrect block number and some incongruencies with what was stated in the third proposal. However, the community accepted to be pragmatic about the whole governance process and that it should just proceed with the upgrade.

On the 15th April, another proposal was put up for voting, with the aim of gauging the community’s opinion on the issuance of fungible tokens on the Cosmos Hub as well as around a governance driven implementation. The proposers kicked off public discussions around this proposal more than 5 days before the proposal submission and incorporated the feedback into the proposal. However, most discussions again happened once the voting period started. This time round, the voting turnout was around 60%, much lower than for any other vote, and the proposal was defeated. It is unclear whether this means that the community is not in favour of issuing fungible tokens on the Cosmos Hub or whether it is not in favour of the proposed method.

Lessons learnt in the past months

The submission of so many proposals, the general activity of the community around them and the development of upcoming proposals being put up for discussion show that the community is extremely active and is trying hard to improve and move forward. This bodes very well for the future of the network and shows that there is a real sense of belonging and the provision of a governance system that attempt to allow for everyone’s voice to be heard.

This does not, of course, mean that everything is perfect and we think that the following should be highlighted:

It has been made very clear (as if there was ever any doubt) that the validators have the final say in what software to run and that proposals only serve the purpose of identifying where the community’s general consensus lies. This is evidenced, for example, by what happened after the approval of proposal 5, where the Tendermint team published guides to upgrade the network that used v0.34.1 of the Cosmos SDK as opposed to v0.34.0 as indicated in proposal 5. We understand that the difference in the versions had no effect on the network, but we believe that this final responsibility borne by the validators is important to keep in mind.
Most of the proposals until now have been used to signal intention and gauge the community’s opinion around these intentions and high-level specifications. In this sense, proposal votes have been very similar to a referendum with people given the choice on some loosely defined paths which they believe should be taken. The actual implementation of the work seems to be beyond the scope of the governance system and more the responsibility of developers and validators. This is conceivable since ATOM holders will not, generally, have technical knowhow nor the time to go over code or detailed designs to thoroughly understand and review them.
The current proposal system does not allow for any amendments to be made following the submission of a proposal. This would have been very helpful, for example, in the case of proposal 5. A system allowing for amendments would allow for minor changes to be made as long as they are deemed to be important in reflecting the community’s opinion more accurately. On the other hand, such a system could lead to a lot of time wasting for the community if it was abused. In this sense, the upcoming proposal by Sikka could serve as a middle-ground solution allowing proposers to amend their proposal via a new submission without risking the loss of deposits, if the community deems the amendments to be beneficial to the ecosystem.
There is currently a lack of process in the release system. This is understandable and completely natural given that the project has only recently launched its mainnet, thus allowing for governance proposals to impact the direction of the network. It is clear that a process will help formalise things, hopefully without being restrictive to the point that innovation is stifled. The need to address the current lack of process is evidenced by the draft proposals published by figment.network who have attempted to identify and address possible scenarios.

Thoughts and comments on the current state

With the above lessons in mind, we believe that the current and future proposals can be categorised in the following ways:

Proposals that allow the community to signal its interest in a particular feature being added to the network.
Proposals that allow the community to signal that a set of high-level specification is desirable for a particular feature.
Proposals that ask the community to accept that a particular implementation, and the features within, is run by the validators.

We think that moving forward proposals should be written based on where they fall within this categorisation, in order to avoid the mistakes that have happened until now in which proposals belong to more than one of these categories, resulting in confusion vis-à-vis what is to be voted on.

What is more, given the open-source nature of the Cosmos SDK, anyone can implement any feature and ask for the community to vote for the implementation to be run by validators without ever publishing any of the first two types of proposals. While we see this as technically possible, it seems highly unlikely that somebody would just do this without the community realising that such intentions existed, especially since most of the development processes are streamlined via GitHub.

GitHub does not exist for the development of proposals and the community is expected to openly discuss proposals and then vote on them based on every member’s opinion formulated through the following of and participation in such discussions. Unfortunately, what we have seen until now is the expectation that the community votes on proposals that have not been well discussed beforehand, somewhat catching the community off guard with only two weeks to make a decision.

In order to develop a network that values and promotes community involvement, it does not seem reasonable to ask the same community to vote on proposals that have not even been thoroughly discussed by the most active members of the community first. We see two ways in which the situation can be improved:

The first is to adapt a process typically used when setting up bills and laws in many countries, with the definition of various levels of proposals such as whitepapers, 1st reading, 2nd reading etc. In this case, the public should be encouraged to vote and give feedback on proposals with the clear understanding that, most of them, are not a final version but a step towards a final decision.
The second is to set up a governance working group with the specific aim of reviewing, discussing and possibly amending proposals before they are put to vote. The aim of such a group is in no way to serve as a gatekeeper for proposals, but rather to facilitate the discussion of potential proposals with the view of giving the community the opportunity to vote on proposals of high quality. Of course, anyone wanting to submit a proposal to the community for voting is still able to do so if they believe that the community will view their work favourably.

We believe that the above two systems, along with the idea (from Sikka’s upcoming proposal) that deposits on No votes get returned to their depositors, could lead to a governance system that strikes the right balance between allowing for high quality proposals to be brought to vote while also ensuring that spam proposals are minimised.