Against community governance
Highlighting my concerns for community governance and systems with no hierarchies.
Governance is hard, especially for decentralized protocols. Allowing a community to govern a protocol does not make it any easier. On the contrary, it makes it exponentially harder and far more dangerous. The challenge is amplified when teams decide that the 1 token = 1 vote model is the best way to distribute power, and that all forms of hierarchies should be eliminated.
One of the most important things to realize when creating governance models for decentralized protocols is that the model must be designed for the user, not for the token holder. This is where I believe a lot of broken models originate, when designing something that token holders will like, and not something that protects the actual users of a protocol. It is evident that there are a lot of projects who do not consider this, the opt-out model which some protocols implement are a clear indicator of this.
1 token = 1 vote systems create terrible plutocracies, especially when considering who holds tokens.
Changing or upgrading a protocol through a token vote is far too easy, protocol upgrades should be hard and a simple vote should not result in network wide acceptance of the said changes or upgrades. When a protocol or governance change is just a token vote, those implementing and dealing with the changes are likely to not be represented. When requiring all users to opt-in to upgrades or changes that were voted on, there is a large social cost connected to every vote. This helps prevent nonsense from being realized or ignored, as those using a protocol can decide whether they even want to accept those changes.
When discussing the governance of decentralized protocols, there seems to be a misconception that structures need to be flat and that all hierarchies need be eliminated. Yet one of the best examples of a functioning decentralized governance model, the swiss government, embraces hierarchies and recognizes their need. Hierarchies do not need to mean that there is a select elite making every decision, when designed correctly hierarchies can be kept in check and add a benefit to all parties involved.
For some protocols all of this doesn’t really matter. When there isn’t much damage that can be done through an upgrade, more simplified approaches may work just fine. It becomes concerning however when the protocol in question can have huge consequences, for example when a protocol with the ability to transfer user funds can be easily upgraded through token holders and the only way to disapprove an upgrade is a lengthy opt-out process. I previously highlighted this concern in a blog post about 0x.
Technocratic Councils
Although elitist and still requiring a certain amount of community governance, I think the one model which works especially this early into the development of blockchain based protocols are technocratic councils. I think the only way one can really make decisions on things like whether a protocol should be upgraded or not, is if the voting party has a firm understanding of the system it is built on and the effects each outcome would have. It seems irrational to think that every token holder will be able to make an informed decision, or even want to participate in governance. We saw with “The DAO” that most holders couldn’t care less as a minimum quorum was never achieved in its short lifespan.
The technocratic council should of course not be completely autonomous and ignorant on the desires of other actors in the protocol. A line of communication should be nurtured, to ensure a more cohesive environment for all parties involved.
Decisions made by the technocratic council should still not be final and automatically shipped to the entire network, users must still be required to opt-in. Assuming agreement by default is a malicious and naive solution, especially when one of the values of many decentralized protocols is to enable their users to have self-determination.
A governance model which includes a technocratic council is currently being worked on by the Melonport team, as teams move towards giving up the governance of their protocols. I hope to see more working on implementing a model like this. It is important to note however, that token holders voting for the technocratic council is still not an optimal solution, as there is still a first level plutocracy.
Governance should be hard
One of the fundamental issues, as previously mentioned lies in the fact that projects have or are attempting to oversimplify governance. Governance however should never be easy, if something can make or break a protocol and determine the future of it, it should be hard to pass those changes in a secure system. A secure system is one in which it is hard to change protocol parameters without significant social cost and user involvement, it should contain every possible fallback to prevent outcomes from occuring which can be massively damaging. This of course does not mean that governance should be needlessly hard, as to prevent anything from ever being changed.
Governance should be multilayered and tradeoffs should be considered carefully, additionally governance should be allowed to change. Setting something in stone before even deploying it seems like a terrible way to jump the gun. Especially when claiming to be a protocol that should withstand multiple years of use and various iterations.
No set of people should be given significantly more power than others and if this is the case, the ability to fork (and this being the default behaviour) becomes of great importance.
