In one image:
Let’s see first how DAOs currently vote and the problem. Then, we will introduce two solutions and the image above will be clear.
How DAOs vote
Many DAOs use off-chain voting to avoid gas fees.
For example, Decentraland uses Snapshot to decide off-chain. Then, three trusted members from Decentraland record on-chain results on Aragon.
Gitcoin uses Snapshot for off-chain voting and Tally to record important decisions on-chain.
Snapshot allows DAOs to choose up to seven voting strategies. These strategies include:
Who can vote — e.g. everyone with a token or who has more than N tokens.
One vote per token, one vote per eth address, one vote per human, quadrating voting, etc.
Basic delegation.
At the moment, Snapshot’s delegation is limited to one eth address. Also, if this delegate doesn’t vote but delegates again, the first eth address doesn’t vote — it’s not cascading.
Problem
DAOs sometimes have many frequent proposals to vote. When members can only choose one delegate, delegates can also have too many proposals to vote. When they don't vote, the sovereignty of those who delegate to them is lost. This is even more problematic when delegation is not cascading — like in the example above.
Also, Andrew Hall (Stanford) and Porter Smith (a16z) warned DAOs about the "Paradox of voting". Involving everyone in too many decisions makes it less democratic.
When we involve everyone in too many decisions:
Voting requires too much effort
The participation of a single person is not so relevant
So why make the effort?
Let’s see how we could solve this without the need for traditional rigid hierarchies.
How to improve DAO governance
New voting mechanisms
We could improve DAOs governance by means of new voting mechanisms. DAO members could use any combination of them. Let’s see some examples.
Cascading delegation
A person P1 could delegate to P2, P2 delegates to P3, and P3 to P4. If P1, P2 and P3 don’t vote but P4 does, all of them would vote as P4.
Topic-based delegation system
People could delegate to different addresses depending on the topic, project, team, etc.
Priority list
If person A doesn't vote but B does, vote as B regardless of C. But if B doesn't vote either, do as C says.
People could create priority lists like Twitter lists. Everyone could then use them to delegate or be part of any voting mechanism. For example, someone could make a list of MIT professors — and use it in different DAOs.
Cascading priority list
A priority list but cascading.
Majority list
If we don’t vote on a proposal, we want to vote as most people within a list.
Consensus list
Vote as the people on this list if all of them agree. If two or more disagree, send me an email to vote directly.
Delegation of individual proposals
Another voting mechanism could allow people to delegate individual proposals — not all proposals.
AI-assisted recommendation
When a person is involved in many votings, an AI-assisted tool could be handy. It could vote for us depending on our past votes, the votes from people that we follow, etc.
We could receive a daily or weekly email with the AI votes so we can override them if we disagree.
As we will explain later, this would benefit from two-layer voting. That way we could use recommendation systems built by people we trust — even built by us.
Composability
Voting mechanisms could be used in any combination. For example, a DAO member could use the following mechanisms:
A priority list
A topic-based delegation
An AI-assisted recommendation tool
Two-layer voting
A voting platform like Snapshot — on- or off-chain — could offer new voting mechanisms. Yet, members would be limited to the voting mechanisms that the platform or protocol supports.
What if DAO members could use third-party voting mechanisms — or build their own?
This would lead to more voting mechanisms. Also, you wouldn't need to trust, for example, the AI recommendation system from above. You could build and host it yourself or use one from someone you trust.
How could a system like this work? By splitting votings into two layers and decoupling the following:
The creation of proposals and definition of who can vote (1st-layer or L1 voting)
The voting mechanism/s a member chooses to cast their vote (2nd-layer or L2 voting)
A DAO would use one 1st-layer voting platform or protocol. Then, people would use any number of 2nd-layer voting mechanisms — not defined by the DAO.
Implementation of two-layer voting
L1 would consist of the following:
Creation of proposals to be voted.
Definition of which eth addressees have voting power. E.g. addresses with at least N tokens of this concrete token.
Definition of how the voting power is distributed. E.g. one vote per token, one vote per address, quadratic voting, etc.
Then, L2 would handle the voting of the proposals. This could be on- or off-chain.
In any case, any eth address — with or without voting rights — should be able to “vote”. If an eth address doesn’t have voting rights, its direct voting power will be zero. Yet, other addresses will be able to use their votes. They could delegate or use them in other voting mechanisms.
Some voting mechanisms could be smart contracts. Yet, others could be applications (providers hosted by someone). People would give their L2 voting providers permission to vote on their behalf for a period of time. But people could always vote directly to override their L2 voting providers.
If an eth address A delegates to B, A's provider would subscribe to changes of B. That way, when B votes, A would also vote. Then, anyone else who cares about the vote from A would know. This would enable advanced voting mechanisms.
Other considerations
Delegated votes could end 24h before direct votes. That way members could always override delegates.
Moreover, we could incorporate a rewarding mechanism for both delegates and L2 providers.
Conclusion
To sum up, to improve DAO governance, we could use new composable voting mechanisms. An optional step would be to allow members to build and use any third-party voting mechanisms.
👏👏👏