In this previous article, I talk about my immersion into DAOs.The approach I took to learn about them was to deep dive and collaborate on a few of them. I am still collaborating -and learning.

Furthermore, I have found more resources to help understand the tool universe that web3 is bringing to the equation.

But in this post, I am going to dissect and describe the different governance models of several DAOs.

Note: the governance of a DAO is as fluid as the DAO itself. Because of its decentralized nature, a DAO can vote one day to shift its governance processes, changing the whole mantra in one sweep.

The scope of this study is within these DAOs:

• Constitution DAO
• ENS
• FWB
• Juicebox

I am not going to comment on what each DAO does or their missions. This article is purely focused on their governance process and model. I invite you to dive into their websites and Discords to get a sense of what is that they do.

Constitution DAO

This project might be the easiest to dissect, since there was no governance after all. The project was initiated by a core team that rallied up a lot of people to buy a copy of the US Constitution. During the week long process, there was a lot of discussion on Discord, but nothing up for voting. The goal was to push a governance model once the bid was won.

I wanted to list this one here to clear all of the myths about this organization. While it was born to become a DAO, it never reached that stage. They issued $PEOPLE tokens that eventually would give voting rights to the token holders, but that didn’t happen -or at least up until the group was dismantled.

In the context of DAOs, this never became one.

Its worth noting that upon dissolution, the community decided to keep the remainder of the balance locked in the Juicebox smart contract, as a reserve backing the $PEOPLE tokens that remain in circulation. Quite a novel idea. A token backed by ETH.

nnnnicholas.eth, a core member at Juicebox, describes this phenomena as an ultrasound memecoin. Waiting for his post on this.

ENS

The governance decentralization for this DAO started with the famous airdrop and call for delegates. An ENS token was given for each .eth domain a person had registered. This airdrop got attention in social media circles because some people received a large amount of tokens.

The governing process for ENS happens with a three layer model:

• Discourse of proposals
• Delegates voting off-chain
• On-chain voting

Most of the proposals are born either on the forum or on the Discord. Later on, they get proposed for voting on Discord.

The first proposal voted was to define a constitution for the DAO. This constitution would help govern the decisions to be proposed and give guidelines to the proposals.

Out of all the DAOs studied here, this is the only one that has such a traditional framework (constitution to frame the proposals).

This DAO has three different type of proposals that can be launched:

• Executable Proposal: involve smart contract execution by the wallets controlled by the DAO.
• Social Proposal: change things that don’t need on-chain involvement, such as fee changes or petitions to root holders.
• Constitution Amendment: as the name indicates, are changes proposed to the DAO constitution.

The proposals can be divided into the four work streams that the DAO has:

• Meta governance: governance discussions and modifications.
• Community: community related proposals.
• ENS Ecosystem: promote ENS adoption and build a thriving ecosystem.
• Public Good: as it name describes, proposals for the good of the public.

Each group has a set of five stewards that are basically the operators of the group. They take care of:

1. Managing operational tasks related to the administration of a working group;
2. Maintaining a description that sets forth the focus and intent of the working group;
3. Developing working group goals for the Term and providing a clear road map for achieving those goals, to be published in the ENS governance forum within the first 30 days of a Term;
4. Approving the creation and dissolution of sub-groups or workstreams within a working group to undertake work and/or carry out specific projects or tasks;
5. Requesting working group funds from the DAO; and
6. Approving and making funding available to sub-groups, workstreams, or contributors within a working group.

They are the ones that move proposals forward to ask for funding. They are responsible to get these proposals moved forward according to the governance process as Collective Proposals.

In order to get proposals to move forward, first the proposal needs to go through a temperature check on the forums and Discord. This temperature check helps gauge the level of enthusiasm of the community towards a proposal. This helps gauge and prioritize the proposals that should move forward to the next phase.

Unlike other DAOs, the temperature check is very informal and only helps guide the sponsor of the proposal whether to move forward with it or not.

Next, if the sponsor decides to move forward based on community feedback, there needs to be a draft proposal presented to the community. This proposal now comes under community scrutiny.

Once this phase is done, the sponsor needs to request that the forum moderators move the draft proposal to an active proposal. This means that the proposal gets uploaded to an off-chain voting site (Snapshot in this case) for community voting. This cycle is 5 days long. Once this is done, the outcome is binding and now the working group needs to execute the proposal.

If the proposal is an Executable Proposal, that is, it needs smart contract execution, it goes through an extra layer of governance. I am not going to go deep, as these are very technical proposals, but long story short:

1. you need to have or get delegated at least 100k ENS votes.
2. you need to execute your proposal against the method propose() of the governance smart contract of the DAO governor.ensdao.eth.

Weaknesses

This model of governance is complex and slow. It reminds me of the old forum times where you needed to build consensus via forum -some of us even remember those BBS-, which is slow and tedious.

Proposal drafting is structured and framed by a constitution, this inherits the good and the bad of the traditional law based system.

There is a very low quorum needed for the proposals to move forward to execution: 1%. This is very low by voting standards and means that a few delegates can actually push proposals forward. That said, there is a strong community that is safeguarding the proposal process, which speaks volumes on this DAO’s community management.

FWB

Here is a good article where the DAO explains how their new governance model will work. Their model has evolved from a simple governance by consensus model (using Discord to share proposals, documents to formalize them, and Snapshot to vote) to a multi-group based model. Each group has an area of expertise and a decision capacity / voting power for that domain.

Their latest move has been back to a centralized consensus model where their focus is on the funnel of proposals allowing more visibility and reach.

First, governing all, there is the Snapshot community voting on the different proposals. This is the sovereign model. The proposals voted favorably will then be taken to execution by the specific team assigned.

But the trick here is how those proposals reach the community. When the funnel of information is a limiting factor -especially on very large projects with lots of proposals- you need to figure out how to make sure each proposal gets its fair share of attention.

FWB has institutionalized an upvote model -a la Reddit- where the community can both propose and upvote those proposals that are relevant to them. This model helps curate those proposals both in content and time -remember, when you do a proposal does matter.

This curation is then treated by a proposals team that helps to draft, organize, and clean the proposals for community review and vote. This helps standardize the format and content of the proposals.

n order to have a forum to contextualize these proposals -or projects- there is a monthly town hall where the teams involved in the curated proposals can explain them. These online meetings also serve as a Q&A and temperature check process for some of these larger proposals.

Finally, the vote takes place. More than 5,000 token holders go to Snapshot, read the proposals, and vote. This can be a daunting task as there may be dozens of proposals at a time.

To mitigate this, FWB is providing some tools to help the community participate such as SMS notifications when proposals get published, side channels on Discord to discuss the content, plus work groups to provide data and metrics on the proposals.

Another route they are incorporating for participation is doing a Discord voting that happens on-chain, so it would be as valid as the Snapshot token based voting.

Weaknesses

This model, while more sophisticated than other models I have seen, takes the effort to centralize the proposal funnel. Before, there was a risk of segmentation by having so many groups, but now influencing what proposals move forward is harder. In this model, you have a centralized team that edits and formats the proposals. This is risky, especially if you don’t disclose how this team is going to be conformed, governed, or what guidelines they will use.

his team might have the power to format a proposal in a way that sways the community vote. Language has many ways to spin something.

Juicebox

This DAO has not yet reached a fully decentralized model. There are token holders that have a very large chunk of the tokens which gives them a very large weight on major decisions.

They have have divided the tasks into workspaces. Each workspace acts as a bucket of tasks that have a specific theme. In some sense this is like the groups division proposed by other DAOs, but in this case, workspaces do not have limited voting scope or a governing body over its tasks. It sits merely to segment the tasks to attack them more properly.

The governance process on Juicebox is very procedural and also centralized. The major difference with other organizations is that they mark their voting process in cycles. These cycles are 14 days apart, and each day of the cycle has its purpose on the process:

During the previous cycle, a set of proposals get discussed at Discord. These emerge from the various chats and soundboarding with members of the core team -and surroundings. The proposals usually get a sponsor from the core team. Those proposals that don’t have a sponsor can still be promoted forward.

Once these are mature enough, they need to be drafted on a specific template:

Once you have a proposal in place, you run it through a Discord channel where a team of community members -you are free to come in and help- would help format the proposal in a workshop environment.

The proposals that have made it to the start of the funding cycle now go through a temperature check. This, as its name indicates, is a way to see if the proposals are welcomed by the community. They get exposed in Discord and discussed.

Once there is enough consensus on the proposals that will go to the Snapshot, the sponsors (usually those with enough tokens to propose at Snapshot) would push the proposal for voting. Once proposals are voted for, the execution happens.

Something to remark: contributors compensations

This DAO compensates the contributions via these governance cycles. That means that you can push a proposal forward towards your compensation. Since you have been involved with a core member when contributing, the core team member would be the sponsor of the proposal.

This compensation can be a one time payment, a trial payout (one or two cycles long, for those who are starting to contribute), or the normal payout proposal. The last one is like a full time salary compensation.

Weaknesses

The major burden of this process is that the core team has to devote a lot of energy to the proposal process. This is inherited from the fact that proposals can only be pushed forward on Snapshot by a threshold of tokens. Juicebox doesn’t have delegation yet, so this process involves at least one of the core team members to sponsor and move forward the proposal. Its a very slow and time consuming process that cripples the scalability of the DAO.

They also don’t have an on-chain voting system, which means the multisig owners might not necessarily follow the decision of the voters.

Conclusion

You have seen three different governance models. These three are different in approach, community and goals, but all of them share a commonality: community votes. Some models are more archaic, like ENS, which resembles a modern democracy with delegates, and some models are more reflective of the new DAO movement, like FWB and Juicebox.

It is too early to discern if these models will be able to handle multi-million person communities -as many DAOs aspire to be- or if they become as clunky and burdensome as the traditional democracies some countries are governed with.

Out of the three letter acronym, O for organization is the only one that has truly been reached. D for decentralization is maturing really fast, but A for autonomous  is lacking. Everything about the process of a DAO (Discord, Snapshot, and Notion) remains manual.

The tools to govern remain pretty much the same as they are in modern democracies; nothing new has been implemented. One would argue the fact that there is more involvement from the community, but I must say that even these numbers, not even reaching 10% of the community, pale in comparison to voting rates in a nation state democracy, reaching 50-60% of population.

This is despite the fact that the proposals are now hashed out through the community, unlike traditional democracies, where proposals are pushed forward by delegates with special interests.

Thank you jonsimmons.eth and nnnnicholas.eth for your help on writing this article.