Decentralizing Governance In Staking Systems

An Early Cosmos Case Study

I joined the Cosmos Validator Working Group when it formed in October 2017. I've participated in every test net since then. The test nets have matured to a point where governance became relevant.

The validator working group has emerged to become a decentralized staking system testing ground. This post describes how I'm experiencing its governance maturing along the way.

We've seen the governance balance shift. It started as completely governed by the project team.  Governance is now shifting toward the validators. My sense is many of the lessons we're learning about this shift will apply to other staking systems too.

Stage 1 - Rely on the Project Team for Everything

This is where the project starts. Validators rely on the project team for everything.

We need the team to give us instructions, notify us of releases and tell us when to launch new test nets. The product team's vision guides most of the development at this stage too.

There's some room for validator feedback. Most feedback was bug-related. The team works to release a minimum viable product. They're triaging and fixing bugs along the way.

In Cosmos, this meant validators monitoring the relevant Riot channels. We hoped to catch updates when they became available. This was hit or miss at the beginning.

No single official project communication channel was available. No single source of truth existed. We needed a single source of truth, since the project team was the single source of governance.

When the group had fewer than 20 validators, the Cosmos team coordinated early test net launches. A team member reached out to us to coordinate. We joined a Zoom call and launched during the call.

Sometimes the launch worked and sometimes it didn't. The validators' primary focus was following project team's instructions. We tried to launch the test net and keep it running.

The project team was the single source of centralized governance at this state. Validators relied on them for everything and every decision.

Stage 2 - Starting to Crawl

As the group grew and project matured, a shift started. My sense is it went unnoticed. The shift started during the summer.

The group grew to around 50 validators. The project team established an official update channel. That became the single source of truth, usually. The team also established a discussion forum.

Validators still relied on the team for a lot. We waited to hear about releases, bug fixes and test net launches.

The validator group began providing more feedback now. It became less passive. The forum became a good place to add suggestions and have discussions.

Test net stability was spotty. Many times validators would get spun up on short notice. Bugs emerged and test nets went down shortly after launch.

The first validator community fork happened in response to this cycle. This happened around early August 2018. Enough validators joined to bring it online.

This represented a big step in standing on our own feet. We weren't 100% reliant on the project team anymore. We took the software, adapted it and ran without project team intervention.

On-chain voting started soon after this. The voting took the form of proposals. Validators initiated proposals. They were sent to other validators to vote on. Validators who didn't vote got slashed.

The project team introduced proposals abruptly and without notice. The validator group adapted fast though. Soon an autovote script was circulating among us.

The script enabled validators to vote for ever proposal in a pre-determined way. Because the votes were non-binding the outcomes didn't really matter.

This wasn't a perfect solution. Yet it was a step toward validator self-governance.  Validators demonstrated we could respond to a project team governance decision, i.e. to release the proposal feature, in a meaningful way.

Stage 3 - Learning to Walk

Then the project team announced Game of Stakes (GoS). GoS would be the first incentivized test net. Project team and validator focus shifted to GoS preparation.

The project team laid out ground rules. This was somewhat of a necessary re-centralization of governance. The team went silent for periods of time, leaving the validators in the dark.

Validators continued to organize ourselves. We helped each other stay updated on progress as best as we knew it. Some of us participated in joint project team/validator Q&A and AMA sessions. We formed cartels.

A sense of self-sufficiency started growing among the validators. Community lead test nets proliferated. These were in response to  project team organized test net launches. Many of the test networks failed soon after launch. The community test nets helped keep the momentum going.

GoS launch was delayed at a least a couple times. Again, validators were at the mercy of the project team. We needed them to -

• Approve our GoS applications
• Release the software
• Make sure we were in the genesis file
• Tell us when the GoS test net would start

The project team scheduled the first GoS start attempt at 6A UTC. This meant many of the validators had to stay up late. As a result, many would not sleep that night.

Actually, the project team scheduled to release the GoS genesis file at 6A UTC.  This didn't mean the GoS test net would launch at 6A UTC. It was the earliest validators could come online.

Validators soon decided that GoS would launch at 6A UTC. We did this by agreeing to bring our validators online as soon after genesis file release as possible. This was a validator group governance decision. We decided when GoS would launch.

I'm not sure this was a conscious decision. It felt more like a forgone conclusion. Yet this to me represented a big shift in governance power, from the project team to validators.

The first GoS launch failed. Other GoS launches did too. Along the way, validator attention turned to -

• Reporting and actually fixing bugs
• Launching community test nets and
• Deciding the next launch time

These all represent significant governance decisions. Some validators continued to call on the project team for direction. In making these decisions, the majority of us started learning to walk together and govern ourselves.

Conclusion

It feels like the importance of this governance shift has gone unnoticed to some extent.  The primary focus has been on when GoS will launch and run its full course.

As we wait for the next GoS launch attempt, now felt like a beneficial time to highlight this shift. Paying attention to this shift provides us a chance to shape not only Cosmos governance. Done well, we can provide a model for future staking systems to learn from too.