How would you like to see Bitocracy evolve?
I am working on a roadmap for the next year and welcome your feedback 
Here’s the first draft: https://github.com/john-light/sovryn/pull/5
4 Likes
In order to get the discussion going after reading this draft, I’m taking the liberty of quoting in entirety a thread from @lex_node on twitter, one of the lawyers i most respect working at the intersection of legacy institutions and cryptogovernance. He states far more succintly the arguments i have been making in regards to removing humans and traditional accountability from governance protocols relying ONLY on the CODE.
A smart contract is not a protocol. It may be an instance or implementation of a protocol. One of my biggest pet peeves right now is people describing “smart contract governance” as “protocol governance”.
The whole governance token craze is driven by inherently misleading terminology.
“Governing a protocol” would be something like IETF contractually binding itself to only implement changes to TCP/IP that are approved by some token holders; AFAIK gov tokens don’t work like that.
For example, Uniswap has not gone to UNI holders and say “please tell us what features we should add to Uniswap Protocol v3” and it has not even gone to them with a set of proposed features that it gets approved before building.
In order to govern a “protocol” the token holders would actually need to have binding authority over the people and resources that define the protocol.
MakerDAO quasi-attempts to do this but the votes are still non-binding signaling votes because there are no contracts.
And, no, it’s not enough for “protocol governance” that after the upgrade has been built, using up a huge amount of resources flagged for “the protocol,” the token holders then vote to ratify it. At that point they face a Hobson’s choice; that’s not governance.
What almost all governance tokens are actually doing or purporting to do is either or both of: (a) governing a specific deployed smart contract’s parameters; or (b) governing use of funds.
In many cases even those limited uses are mere pretense because the parameters can be changed or funds can be spent without the vote & there is no legal governance contract, meaning that token holders are just trusting the implementers to keep seeking & following the vote.
Let’s even assume a project has set up their smart contracts so that parameters cannot be changed without a governance token holder vote.
That’s as close to “real” governance over the smart contract as we might get. But even that is kind of weak.
If the Foundation or key people don’t like the result of a parameter vote, they can deploy a new instance of the “protocol” with different parameters and throw all their endorsement and resources behind that, bypassing the “governance”.
The best that can be said is that the “tight” version of smart contract governance (but still with no legal/off-chain governance) adds a lot of frictions to such a move.
Really, though, you don’t get robust “governance” unless both the people and the technology are “governed”. This means there must be an off-chain component to the governance, which means legal or other off-chain mechanisms.
But, holy shit, now you are just back in the regular legal system and you have capture & censorship issues! This is why @NickSzabo4 eschew “governance.”
What actually makes sense if you want to give people the power to govern some resources or decisions is a corporation-like model–i.e., have a charter that confers legal voting rights on the tokens & enables token holders to drag the relevant people to court if they bypass it.
Anything else is just a lot of ‘governance’ window-dressing on an ordinary developer-to-user relationship.
BTW, I don’t necessarily think that the governance that many projects purport to have would be a good thing if they actually did have it. How silly would it be to distribute TCP/IP voting tokens to the general non-expert public?
reference: https://twitter.com/lex_node/status/1372852542917468160?s=20
2 Likes
Hi @exiledsurfer thank you for linking to that thread! What part of the roadmap is that in response to? Or are you proposing an addition to the roadmap? Can you be more specific about what it is you’re proposing or responding to here? Knowing this will help me write a response specific to any concerns you have about the roadmap. Cheers
Copying over a comment from Discord:
Quiet end voting is a great idea however, removing contract upgrade ability is not as surely bugs can be found at anytime?
My response: at a certain point upgradeability becomes more of a vulnerability than a feature imo, even with a time delay. People should be able to put funds into a contract and not have to watch the contract like a hawk, and be certain that the contract won’t change under their feet if they go on vacation for a few days.
Plus, at a certain point, upgradeability isn’t even useful for the thing it’s most important for (fixing critical bugs) because as soon as a contract upgrade gets proposed hackers will become aware of the issue and exploit it. That’s not to say there’s no point to having upgradeability: we could say that we will rely on it to introduce new features and fix non-critical bugs, but not rely on it to fix critical bugs due to the risk of exposing an exploit to hackers. I come down on the side of preferring immutability, with explicitly opt-in upgrades. Others can prefer otherwise. Let’s discuss these tradeoffs!