Phase II governance review

Protocol Governance
#1

Phase II has happened on Oct 13 6:38pm (UTC) (Unix timestamp: 1602614338)

We had validators voting based on the community input and delegations as weight for their vote. It was a “liquid” democracy in action, where delegates needed to prove their position first by technically running the node and also attracting enough stake. Obviously it was bootstrapped by people who have been long term runners of the Stake Wars (program to educate validators and stress test the network).

There has been a bunch of conversations around the criteria for validators to vote and discussions in the community for how this process was working or not working.

E.g.:

I overall want to start a work group around governance to improve the process going forward. Want to invite both existing NEAR community members and folks from bigger blockchain community who have experience setting up and managing governance for other projets.

First meeting will be about reviewing what has worked and didn’t work about the Phase II vote. Ideally produce a document to inform community on ins & outs and what are lessons to learn from it.

Proposed time: Fri, Oct 23, 3:00 PM UTC
Event to join: https://us02web.zoom.us/webinar/register/WN_V8X7I3wERhq-hG1hGHp8Ig
Or link to create Google Calendar invite: http://bit.ly/phase-ii-governance-review

If you can’t attend or just want to add some ideas / items to the agenda - please respond here.

8 Likes
#3
#4
#5

To clarify, goals for specifically technical governance of the protocol, I think are:

  • Collect feedback and feature requests from various stakeholders
  • Bring all stakeholders to discuss and ideate on how to solve concerns or introduce features
  • Fund the solutions (a bit outside of pure technical governance, but also important part)
  • Agree on solutions (e.g. consensus between stakeholders) and “schedule” their launch

There are few questions that I already have, that curious to hear ideas:

  • How to drive “attendance” outside of the core technocratic group. E.g. there is not that many people who are attending technical discussions (like Ethereum core devs meetings, our numerous technical meetings).
  • How to propagate information outside of immediately concerned people to the wider stakeholders
  • Is privacy of voting important for technical governance?
1 Like
#6

I’ll throw in my 2¢.
I completely agree with the outlined goals and have nothing to add there.

I believe the best is to have it grow organically and that you’re already on the right path.
Keeping them open to the public, answering questions posted in comments during and even inviting those with good questions in to the call is the perfect start.
Attendance will grow with the protocol popularity and people tend to flock to places where they feel they were heard.

I think this is where somebody like Sherif can make a huge impact, and everyone who has experience working with amazing corporate trainers could agree with me.
Rarely do people that spend days/weeks/months on solution design know how to parse the “common sense” that was built during that process and it usually takes somebody, who doesn’t need to understand the fine grain details, with a fresh (outside) point of view to ask the best questions that can take that information to the wider audience.

I believe it depends. If Viktor from Bison Trails is voting on something by representing his employer and/or delegated tokens, it has to be open. If Viktor is voting on something as a token holder, it can/should be private… and even if it is private, he can easily reveal/prove how he voted at some later stage.

1 Like
#7
#8

Hi Illia,

Thank you for this initiative. We think it is vitally important to learn lessons from the early governance experience.

Firstly we should recognise the positives insofar as this was indeed liquid democracy in action: based on votes weighted by delegated stake the community made a decision.

Beyond that we have to question what went well and what did not go so well. As far as we can tell:

The community participated, challenged each other, gathered information, worked to try to ensure that questions were addressed and actions taken. The vote mechanics of themselves also worked well.

What did not seem to go so well was:

  • Clarity of the question
  • A full understanding of the risks and benefits
  • Variable decision criteria in the absence of prior agreement about the decision criteria
  • Reliable, verifiable, single source of data about the status of factors influencing the decision
  • Political pressure to make the decision and it’s influence on validator behaviour

The combined effect of the above is that at times we seemed to be trying to hit a moving target! This is best illustrated by the amount of staked vote required to achieve a decision which changed significantly in a range from 100m NEAR to 200m NEAR, out of 750m available for staking.

The question is what do we do about this and how do we seek to improve future decision making?

The good news is that the validators are genuinely interested in doing this. Suggested steps are:

  1. Recognise that we cannot all be involved and that it may be better to delegate aspects of this to a small, well motivated and well qualified group. A group whose purpose would be to sift through the information and make recommendations to the community, which would be free to accept or reject such recommendations.
  2. Keep the initial thinking sufficiently strategic. Only when this is right move onto the necessary details.
  3. Build and agree the principles as a foundation for decision making.
  4. Document our conclusions as papers that collectively can define governance, authority, voting/decision making so that these can be points of reference.

Beyond these we can also address the criticisms of this, assuming they are not covered in the work on principles.

1 Like