When I cofounded Aragon in 2016, we thought that DAOs would be managed under one tool supporting the end-to-end lifecycle of governance. We got lots of assumptions right, but that clearly wasn’t one of them!
Today, DAOs are managed by using a bunch of tools, from off-chain discussions in forums to signaling tools like Snapshot and then on-chain enactment with Aragon.
With such wide range of tools, the actual content of the proposals and how they affect the DAO’s assets and resources can get lost in context or misinterpreted.
For example, from the recent governance proposals involving financial transactions, none had Ethereum addresses where to send funds. Some of them concerning payments also didn’t specify how or when to conduct payouts (e.g. upfront, monthly, weekly). As a result, there are tons of work involved to just lay out details on a proposal post-vote. That is quite dangerous, as it means that proposals are being passed without fully understanding what they do/will do.
This is normal, since there is a mismatch between plain English (pay X person for a project) vs on-chain code (call method(params) in 0x123...321). The way that the traditional world deals with this is to have very specific language, legal language, and outlining all of the terms in the most precise way. That takes tons of time and I don’t think we want to hire an army of lawyers to deal with our own governance. There’s another simpler way: use data structures, type checking and smart contracts.
I have been working on a standard for DAO governance that outlines the data structures needed for a DAO to operate. I have also incorporated a governance process defining step-by-step how to make governance proposals.
This work builds upon my learnings from Aragon. The first governance process we had, AGP-1 was quite an elegant process, but we faced significant issues since proposals were just written in plain English, and we had to deal with the lack of encoded/deterministic output after each proposal. The main learning I took from that process is that a DAO governance process needs a clear spec of what a proposal actually does, and you should be able to write the actual proposal in plain JSON.
Of course a more understandable description in English is needed for the proposer to explain themselves, but having an encoded version is paramount to ensure we don’t fall into chaos or unwanted side effects.
My proposal for Nation3’s governance process is defined in GOVERNANCE.md, together with the data structures defined in N3GOV-v1.d.ts.
In total the human-readable process fits within 90 lines of text and the data structures within 300 lines of code (most of which are comments). I’ve been trying to simplify as much as possible, since I have also seen how overly complex processes make things worse and become a playing field for bureaucrats to thrive, instead of builders.
I added some color on a few design decisions that I took along the way, to provide strong guarantees around our governance process.
As an up-and-coming digital jurisdiction, providing a reliable framework of law should be at the center of Nation3’s value prop. To keep such reliability, our own governance process is paramount.
I’d love to hear feedback from the Nation3 community, and have a discussion about such an important topic for our nation!
PS: I have retrofitted, as well as possible, all our existing Snapshot proposals to follow this spec here.
This is the actual proposal adhering to this very spec:
{
"spec": 1,
"id": 13,
"discussion": "https://forum.nation3.org/t/proposal-formalize-nation3-governance-process/712",
"content": {
"kind": "proclamation",
"statement": "The following governance process is to be followed now for all Nation3 DAO governance proposals: https://github.com/nation3/gov/blob/92687c33f8bce37dda9e62882b39720eb1b28df3/GOVERNANCE.md",
"parameters": {
"choices": [
"Approve",
"Reject"
],
"votingSystem": "single-choice"
}
}
}
