At SporosDAO we recently embarked on a mission to solve the problem with sweat equity allocation for early contributors. Too often, contributor/employee upside doesn't meet expectations because important cap table decisions are made in the boardroom between investors and founders.
We are quickly learning that solving the problem is not that simple albeit very much worth the effort. Below I will share a few observations related to fair voting rules.
After a good amount of research we’ve decided to base our on-chain governance and legal entity on the KaliDAO framework. KaliDAO’s governance mechanics are based on best practices from previous success stories with Compound DAO, Maker DAO, Moloch DAO, Lex DAO and others.
There are three key parameters for KaliDAO’s governance contract: quorum, unity and voting period. Quorum sets the minimum amount of voting token percentage required for a proposal to be valid. Unity sets the minimum ration of YES/NO votes required for a proposal to pass. Voting period sets the time period for a proposal to remain active before votes are tallied.
Our intention at the outset was to ensure that any DAO wide proposal is approved by majority votes: quorum * unity > 50% of all votes (1 token : 1 vote). Sweat equity tokens are distributed weekly via on-chain self-submitted proposals for work done. It seems like a fair way to implement meritocracy based governance. Contributors who complete tangible observable work for the week, get allocations, others who do not contribute during the same week get diluted.
The default recommendation from KaliDAO for voting parameters for a DAO company template are: 20% quorum, 60% unity, 2 days voting period. Here is what we learned as we thought through these parameters:
Low quorum (20%), high unity (60%), short voting period (2 days):
- This configuration works if everyone gets a timely notification about new proposals and are able to cast their vote.
- However since there are currently no reliable solutions for push-notifications with escalation rules to ensure that all eligible voters are aware of a proposal, there is a risk that some voters won’t see a proposal. Thus a proposal with minority quorum (20%) will pass if the majority voters did not see it in time and had a chance to vote.
- Another attack minority voters could implement is obfuscation via spam. For example they could post a large number of meaningless proposals and bury in the pile one or few proposals with malicious terms. In this case the spam effect may discourage some voters to review all proposals and cast their vote on the ones that matter. The malicious ones will pass.
- Yet another possible minority attack in this case may be DoS (denial-of-service). This type of attack was carried out with good intentions during TheDAO hack rescue mission back in 2016. Minority voters can submit a proposal and immediately after that generate high traffic of transactions on-chain to effectively slow down ability of other voters to cast their vote. This will cost attackers gas fees so it would have to be worth doing this in balance, but it is possible.
- A less costly and more likely scenario is to time the attack and post a proposal during peak traffic and gas price period when tx confirmation takes a long time, requires multiple retries and costs are 10x or 100x what they normally would be - thus discouraging other voters from participating. This type of peak was observed recently with the Yuga Labs’ massive Otherdeed NFT mint that clogged the ETH network.
High quorum (75%), high unity (75%), short voting period (2 days):
- This is the configuration we started with. Our intention was to ensure we are all in alignment in the early stages of the project. However we are learning that it may not be optimal.
- There can be situations when not enough voters are available to vote in time. Due to traveling, internet connection issues, family emergencies or other factors. This leads to proposals expiring before quorum is reached. We patched this issue by extending the voting period to 5 days, but as it turns out there were other issues we may face.
- A malicious ransom attack is possible by minority voters. Minority voters (30%) can choose to abstain from voting thus blocking any proposal from passing. They may do so to force the hand of the majority to pay a ransom in order to unblock proposals. Similar ransom attack is discussed in ZKRollup vs Validium.
Long voting period (5+ days)
- Longer voting period helps with the lack of push notifications and voters traveling.
- However it introduces potential difficulties with timely decisions. Say for example a unique opportunity presents for the DAO to do a business deal and there are only 3 days available to make it happen. If the voting period is more than 5 days, the execution cannot take place in time.
These are just a few of the known issues with the latest best practices and tools available to us for DAO governance. It is clear that there is much more we will learn along the way.
The really good news is that all these new DAO experiments with on chain voting are recorded on immutable public ledgers that researchers can easily reference for analysis and look for mechanics with targeted optimal properties.
This is much different environment than the traditional corporate governance experiments which largely remain within private board room meetings stacked under layers of non disclosure agreements.
Traditional company board meeting notes are supposed to capture important board decisions, but the reality is that these notes are intentionally scrubbed from any information that may be discoverable in court and used against board members. This leads to survivorship bias that celebrates success but limits our ability to learn from mistakes.
Fortunately blockchain allows us to record mistakes on a public ledger and learn from them together.
If you are building a for-profit web3 product DAO, consider joining our peer support program at SporosDAO. Let’s figure this out together.