Generalized Governance

A framework for scalable, interoperable governance, coded in Vyper.

by Kenny Peluso

Source: http://worldartsme.com/images/types-of-government-clipart-1.jpg

To dive right into the code, checkout my repo, here.

What is Generalized Governance?

What’s the difference between government and governance? Government is the tangible apparatus that legitimizes and executes laws. Governance is the means through which a government distributes its legitimization and execution across laws. Generalized governance (GG) is the set of rules all types of governance mechanisms follow. In other words, GG is all that can be abstracted from all forms of governance. In programming lingo, GG is a class, and things like democracy, republic, TCRs, etc. are instances of that class.

Why do we want GG?

GG is useful for the same reason every Ethereum Request for Comment (e.g. ERC-20, ERC-721) is useful: Ease of interoperability is directly proportional with achieved network effects. When aspects of commonly used notions (e.g. what constitutes a token, what constitutes packets of information sent across the internet, what constitutes governance) are standardized and agreed upon, developers can concentrate on the core competencies of their products and thus augment the network’s cumulative value (e.g. the nuances of TCP/IP minimally distract the front-end developer from providing their users with the best UX).

What makes my GG so special?

Past GG designs have assumed tokenomics-based solutions to governance (e.g. this GG paradigm is tokenomics-specific and this other GG paradigm, by Level K, is again tokenomics-specific but opinionated to easily accommodate TCRs), but clearly there are many instances of governance that don’t need any tokenomics (e.g. despotism, direct democracy, and systems that cannot be implemented with tokenomics). Therefore, past solutions do not fully encapsulate the set of all governance solutions and thus are not truly GG solutions.

I have formulated an alternative interface that I now propose as a true GG solution. This solution allows for data type-agnostic decisions and captures the governance instances born from tokenomics as well as the traditional solutions pictured above. I have also made and tested a basic, exemplary implementation of said interface. In this post, I’ll be diving deep into how my interface operates through examining my basic implementation.

How does my GG work?

To explain how my GG works, I’ll first list excerpts from the relevant code that can be referenced as the “legal workflow” is outlined. Then, I’ll actually walk through said outline.

Below are excerpts from interfaces/governance.vy, the interface for my GG:

@public
addPreferences(_dud: address, _type: uint256, _prefs: address) -> bool
@public
addIssue(_dud: address, _type: uint256) -> uint256
@public
propose(_dud: address, _type: uint256, _issue: uint256) -> uint256
@public
debate(_dud: address, _bill: uint256) -> uint256
@public
vote(_dud: address, _debate: uint256, _votes: uint256, _ye: bool) -> uint256
@public
resolve(_debate: uint256) -> bool
@constant
@public
numIssues() -> uint256
@constant
@public
numBills() -> uint256
@constant
@public
numDebates() -> uint256

These excerpts allude to the general workflow for “how a bill becomes a law” in my GG.

Additionally, here is an excerpt from contracts/preferences_basic_address.vy, a necessary feature of the governance process:

inDebate: public(bool)
owner: public(address)
delegation: public(address)
opinions: map(uint256, address) # HERE
@public
def __init__(_owner: address):
    self.owner = _owner
@public
def isInDebate(_status: bool) -> bool:
    assert msg.sender == self.delegation
    self.inDebate = _status
    return _status
@public
def setDelegation(_gov: address) -> bool:
    assert self.owner == msg.sender
    assert not self.inDebate
    self.delegation = _gov
    return True
@public
def setOpinion(_issue: uint256, _opinion: address) -> bool: # HERE
    assert self.owner == msg.sender
    assert not self.inDebate
    self.opinions[_issue] = _opinion
    return True
@public
@constant
def getOpinion(_issue: uint256) -> address: # HERE
    return self.opinions[_issue]

In preferences contracts, user can input their opinion for various issues. Those opinions may become law. The excerpt above is taken from the preferences contract handling the address data type. Only 3 lines of code need to be altered to build preferences contracts listing opinions for different data types, and within those lines, only one word needs to be changed. The lines that need to be altered have been commented with # HERE in the excerpt above. If the governance system is to reach decisions regarding string[100] variables instead of address variables, then, within those 3 lines, simply replace address with string[100]. That’s it. My repo provides examples of preferences contracts for uint256, string[100], address, and timedelta data types, so check it out if examples can explain this point better than I.

With the necessary infrastructure in place, we can now dive into the “legal workflow.” The workflow that follows is how I thought about the GG process, but the governance interface, I think, accommodates a plethora of alternative and valid workflows. Those other workflows may not even include preferences contracts! That being said, here is my envisioned workflow:

1. Future members deploy preferences contracts for every data type of decision.
2. Future members set their preferences i.e. their opinions are recorded and setOpinion() is called.
3. The GG contract is deployed
4. Members are “added” i.e. Members must call setDelegation() to assign the GG contract as their preferences’ delegation, addPreferences() is called to link their preferences with their address the GG contract, and some other operation may be invoked within GG (e.g. reputation points may be assigned to the member’s address or some access token may be assigned to them).

5. Members call propose() to propose that their opinion on an issue becomes law.

6. Debates on proposed bills are initiated by calling debate().

7. Votes follow via calling vote().

8. A debate is resolved by calling resolve().

9. The governing body’s legitimization of an opinion is asserted; A bill becomes a law. The actual read operation of laws involves reading the approved bill’s sponsor’s preferences and then reading the sponsor’s opinion.

A locking operation can be applied to the preferences contract such that when one’s opinion becomes law, then they cannot change their opinion on an issue. The basic implementation on my repo works differently in that it allows those whose opinions have been deemed as law to change their opinions and thus the law. This is akin to selecting “an expert” per issue governed, where the governing body defaults to the expertise of a subset of members. I say “subset” because a preferences contract’s opinions can easily be governed by another governing body of individuals, another GG contract, or even the same GG contract with opinionated functionality for whitelisted committees.

Conclusion

The contract in my repo has a basic implementations of both the preferences and GG contracts. Feel free to fork, contribute, and leave your feedback!