Voting is a critical decision-making method in any mode of Venture DAOs in DAOSquare Incubator. Scenarios such as investment decisions, eligibility of DAO roles, and the setup and upgrade of DAO contracts all require voting. However, since each DAO has a different governance philosophy and strategy, the DAOSquare Incubator provides a customizable voting system for DAOs to meet the governance needs of different DAOs. This section describes the voting system in detail and how to use it for customization.
The DAOSquare Incubator's voting system consists of three categories of parameters:
Parameters Categories | Description |
Voting Power Algorithm | The voting rights algorithm defines who is entitled to vote (Eligibility), votes with what assets(Voting Asset), and how much influence that user has on the outcome of the vote (Voting Weight). |
Voting Judging Algorithm | The vote pass algorithm determines whether a vote should be approved or rejected. It consists of the Support and Quorum parameters. |
Voting Period | The voting period setting defines the active period of a voting activity. It consists of two parameters, the Voting Period and the Execution Period. |
Next, we will introduce each type of parameter in detail.
Voting Power Algorithm
The voting rights algorithm defines who is entitled to vote (Eligibility), votes with what assets(Voting Asset), and how much influence that user has on the outcome of the vote (Voting Weight).
Eligibility
In the DAOSquare Incubator's voting system, a user's right to vote in a DAO is determined based on whether the user owns the DAO's Governor status. A user can become the Governor of the DAO in two ways:
- Be invited to become Governor through Genesis Governor when Summoner deploying the DAO.
- Be nominated and approved to become a Governor through the Governor-in Proposal.
When inviting a member to become Governor through a Governor-In Proposal Proposal, the DAO can use Governor Eligibility to set the screening criteria for which category of people is eligible to be nominated to become Governor of the DAO. DAOSquare Incubator's voting system offers five Governor Membership on-chain verification categories, which are:
- Deposit: the member's deposit balance in the DAO (only for Vintage and Collective DAOs)
- ERC20: minimum number of ERC20 tokens held
- ERC721: minimum number of ERC721 tokens held
- ERC1155: minimum number of ERC1155 tokens held
- Whitelist: a list of wallet addresses
When a user meets the voting eligibility limits set by the DAO, that user can be nominated as the Governor of the DAO. If the proposal is voted through, the user will become the Governor of the DAO. What should be noted is:
- When a user is nominated to become Governor through the Genesis Governor, he/she won’t be subject to Governor Eligibility
- Governor Eligibility can be set when the DAO is deployed or through the DAO-set Governor Eligibility Proposal. Governor Eligibility is optional, if the DAO does not set Governor Eligibility, that means anyone is eligible to be nominated as Governor of the DAO.
- The ERC20/721/1155 Token in Governor Eligibility settings must be on the same network as the DAO. For example, if your DAO is deployed on the Ethereum mainnet, then when you set the ERC20 Token as Governor Eligibility. The token address must be circulating on the same network as the DAO.
Voting Asset
The DAOSquare Incubator offers five types of on-chain verifiable voting asset options for DAOs: ERC20 Token, ERC721 Token, ERC1155 Token, Deposit, and Allocation.
- ERC20. The holding of an ERC20 Token is used as the voting asset. For example, a community-based fund could set up that community's community Token as a voting asset.
- ERC721. You can also set the holding of an ERC721 Token as the calculated object of vote power.
- ERC1155. The ERC1155 is very close to the ERC721
- Deposit. Deposit, which applies to both Vintage and Collective DAOs, refers to the user's deposit balance in a DAO.
- Allocation. Allocation is a manually allocated asset class for voting votes. If a DAO's voting system chooses Allocation as the voting asset, a user will be manually assigned the count asset number when invited to become the DAO's Governor. We can easily see that ERC20/721/1155 and Deposit are good choices if you want DAO governance based on an open, permission-free philosophy. Deposit establishes a more direct correlation and binding between DAO's governance rights and Investors’ interests. Allocation can be used to meet the needs of those who want to use off-chain voting assets, such as company equity.
Weight
Weight is used to calculate how much Voting Power a Governor ultimately has. The DAOSquare incubator offers three weighting algorithms: Quantity, Log2, and 1 Vote a Voter.
- Quantity. Quantity is a simple algorithm that directly calculates the Governor's holdings of voting assets. For example, in a DAO with ERC20 Token $RICE as a Voting Asset, Jack holds 1000 $RICE, and Jack's voting weight is 1000. The same applies to ERC721/1155, Deposit and Allocation.
- Log2. The binary logarithm (log2) is the logarithm to the base 2 and is the inverse function of the power of two functions. Check the Wiki to learn more about log2. Simply put, it reduces the gap in influence on voting results between large whales and small holders. So, in some ways, log2 can reduce the whale effect (whale attack) on DAO governance.
- 1 voter a vote. In this weight algorithm, all voters have the same power to vote (1 vote) regardless of the type of Voting Asset. For example, if the Voting Asset is ERC20, the 1 voter a vote algorithm will not count the number of ERC20 tokens of the voter, but will only count 1 vote.
Voting Judging Algorithm
The Voting Judging Algorithm is used to help a DAO determine whether a vote should pass. In the DAOSquare incubator's Voting system, the Voting Judging Algorithm provides two judgment parameters: Support and Quorum.
Support
Support is the percentage or number of votes cast in favor of a vote. The Support judgment parameter is counted as a PASS only if the percentage or number of votes is higher than the DAO set. The DAOSquare Incubator's voting system offers two Support algorithms:
Algorithm A
The number of votes in favor divided by the total number of votes cast is greater than a specific proportion.
Algorithm B
The YES votes outnumbered the NO votes by a specific number. X can be customized by DAOs.
Quorum
Quorum represents the participation rate of voting, which is the difference (proportion or number) between the number of votes cast and the total number of votes entitled to vote in a single vote. The DAOSquare Incubator's voting system offers two Quorum algorithms:
Algorithm A
The total number of votes cast (YES + NO) divided by the total number of votes entitled to vote is greater than a specified proportion.
Algorithm B
YES + NO votes outnumbered the total votes in DAO by a specific number. X can be customized by DAOs, even 0.
In a vote, only if the actual participation rate meets the Quorum requirement and the participants’ support rate meets the Support requirement, will the vote be passed.
Voting Process
For all proposals that require voting, the following steps are taken:
Proposal Submitted → Start voting (if applicable) → Voting period → Grace Period (if applicable) → Execution
Start Voting (if applicable)
After the Proposal is submitted, go to the voting page. There are two situations:
- For the investment proposals in Vintage DAO and Collective DAO, and the Member-In and Top-up proposal in Collective, the Start Voting button is a trigger for the investment period. Only after clicking Start Voting, the voting period is opened.
- There is no Start Voting step for proposals other than those mentioned above. Once you are on the Voting page, the Voting period begins directly.
Voting Period
The Voting Period is used to help the DAO set a valid time frame for voting. Voters will not be able to vote during the non-valid time frame. Voting Period defines the length of a voting period (e.g., 1 hour, 3 days, etc.) during which all voting members are allowed to vote.
Grace Period (if applicable)
Not voting for every proposal in every mode of DAO has a Grace Period. The Grace Period exists only during the voting process for investment proposals in the Collective DAO.
In Collective DAOs, there is a Grace Period after the end of the Voting Period of the investment proposals. Anyone who is not satisfied with the voting result can redeem part or all of their funds to protect their own interests.
Execution
When a vote is completed, an execution action is required to implement the vote result, such as transferring the investment funds to the investee and transferring the tokens of the project to the Vesting contract. To minimize contract complexity (and improve security), in the DAOSquare Incubator's voting system, all voting results are performed manually (simple wallet transaction confirmation). Since a vote has already been cast, this means that the vote must be executed, so anyone can execute it, including non-DAO members. Therefore, the Execution period is a time set aside so that anyone can execute the result of a vote after it has closed.
There is a Execution Period setting in the voting system of Vintage DAOs. In these DAOs, the Execution Period is a soft setting to provide anticipation for certain money-related transactions in the DAO. For example, in a Vintage DAO, when a proposer submits an investment proposal, the system checks the DAO's Redemption period, Refund period, and other time Settings. If the process of the investment proposal (including the execution period) enters the Redemption or Refund period of the DAO, it means that the proposal is likely to fail due to insufficient funds due to the redemption or refund behavior of the passed proposal, so the system will reject the submission of the proposal.
Since Execution is a soft setting, there are two caveats:
- Even if the system makes a time prediction when the proposal is submitted, if the proposal is not executed during the Execution period, it may fail due to changes in funds during the redemption period or refund period.
- Although the Execution period of a vote has ended, it can still be executed, the execution result may not be consistent with the vote result (the vote passed but the execution failed). Take for example the situation described in the first note.
Examples
A vote in the Vintage DAO
- Voting Power Algorithm
- Voting Asset: Deposit
- Weight Algorithm: Log2
- Voting Judging Algorithm
- Support: YES / (YES + NO) > 66%
- Quorum: (YES + NO) / Total > 60%
- Voting Period
- Voting: 3 Days
- Execution: 1 Day
In this example, the voting power of a voter is calculated by using the Log2 algorithm to calculate the balance of the voter's deposit in the DAO. The minimum support rate is 66% and the minimum participation rate is 60%. The voting period is 3 days and the execution period is 1 day.
Note: Before fundraising, voting weight is One person, One vote
A temperature check in the Flex DAO
- Voting Power Algorithm
- Voting Asset: ERC20 (0x…）
- Weight Algorithm: 1 voter 1 vote
- Voting Judging Algorithm
- Support: YES - NO > 3
- Quorum: YES + NO > 30
- Voting Period
- Voting: 20 Hours
In this example, the voting asset is an ERC20, and the voting algorithm is 1 voter 1 vote, so the holder of the ERC20 asset is granted the right to vote according to the holder's one vote. The minimum number of support users is 3, and the minimum number of participating users is 30. The voting period is 20 hours.
← Previous
Next →