We are happy to share some of our mechanisms and technical designs in DAOSquare Incubator, such as the voting system introduced in this article. The goal of these designs is to provide a better on-chain venture capital experience and make them consistent with the concepts of decentralization, openness, verifiability, trustlessness, and permissionlessness. In this article, we will specifically introduce the voting system of DAOSquare Incubator.
In the DAOSquare Incubator or in the application scenario of on-chain venture capital, the purpose of voting usually includes the following aspects: investment decision-making, member management, fund management, system parameter adjustment and contract upgrade. Unlike ordinary voting, the voting of DAOSquare Incubator is executable. This means that the voting results will definitely be executed, and there is no possibility of human resistance to execution.
For example, when an investment proposal is voted through, the investment funds will be transferred from the DAO to the invested party, and a Vesting contract will be created for all investors participating in the investment to claim the invested party's tokens during the Vesting cycle (even issuing an NFT representing their investment share to the investor at the same time). This technical certainty guarantees the interests of both parties, the financier can receive the investment funds with certainty, and the investor can receive the financier's tokens or future vouchers (share NFTs) with certainty.
This certainty is also reflected in inviting a new member to join the Governor, or modifying the upper limit of the number of Investors, etc. In short, in DAOSquare Incubator, voting means deciding a specific action that will be executed.
Almost all DAOs have different voting strategies, which means that an open and customizable voting system is very necessary. Therefore, we hope to provide a building block approach to allow users to customize a voting system that meets their needs.
In general, the voting system consists of the following parameters:
Voting Eligibility: Who is entitled to vote.
Voting Power Algorithm: The voting power algorithm defines how to calculate the voting power of each voter. It involves two aspects: what to vote with (voting assets), and how to give voters voting weights based on these voting assets (Weight Algorithm).
Voting Judgement Algorithm: Provides judgment parameters for voting through a variety of optional Support (support rate) algorithms and Quorum (participation) algorithms. DAO can determine whether a vote should be passed by setting the Support and Quorum values.
Period parameter (Period): The period parameter defines the validity period of a proposal. It consists of two parameters: Voting Period and Execution Period.
Below, we will introduce it in detail.
Voting Eligibility
Voting Eligibility defines who is eligible to vote, not the specific voting power. A person can have voting qualifications, but may have 0 voting power (the voting power depends on the Voting Power Algorithm ). Voting Eligibility only defines the qualifications.
In DAOSquare Incubator, users can establish and participate in three different models of Venture DAOs, which are all managed and maintained through the Governor role. The Governor can be a group of people or a single person (depending on the type of Ventures and the mechanism design of the DAO). Matters within the Governor's management scope are usually decided through Voting. Certain types of DAOs (such as Flex) also provide Investor Polls, which have similar voting mechanisms.
Scenario 1: Governor Voting
Whether a user has the right to participate in the Governor Voting (i.e. Governor Voting Eligibility) of a DAO is determined by whether the user has the Governor status of the DAO. As for how to become a Governor of a DAO and who is eligible to become a Governor (Governor Eligibility), there will be a separate introduction later. In short, becoming a Governor of a DAO means that the user has the voting qualification for the DAO within the scope of Governor management.
Scenario 2: Investor Poll (Voting)
Flex Venture DAOs can conduct a poll (or temperature check) before an investment proposal is launched to determine whether the investment proposal is necessary. DAOs also need to set who can participate in the Poll vote (i.e. Poll Eligibility).
Currently, Poll Eligibtliy provides four on-chain verification categories (choose one from four):
ERC20: Minimum number of ERC20 tokens held
ERC721 (NFT): Minimum number of ERC721 tokens to hold
ERC1155 (NFT): Minimum number of ERC1155 tokens to hold
Whitelist: Wallet address list
When a user meets the Poll Eligibility set by the DAO, he or she will automatically be eligible to vote in the Poll without the need for role approval.
Voting Power Algorithm
The Voting Power Algorithm defines how to calculate a voter's voting power. The algorithm consists of a voting asset and a weight algorithm.
Voting Asset
Voting Asset refers to what the vote is based on and is the basis for obtaining voting rights. Simply put, a voter's voting rights are the value (and proportion) calculated by using the weight algorithm to calculate the voter's voting assets.
DAOSquare Incubator’s voting system provides five on-chain verifiable voting asset options:
ERC20: Use ERC20 tokens as voting assets. For example, a community fund can set the community token of the community as a voting asset.
ERC721: Use ERC721 type tokens as voting assets.
ERC1155: Use ERC1155 type tokens as voting assets.
Deposit: The deposit balance of Investors in DAO is used as the counting asset.
Allocation: Allocation is a manually allocated voting asset class. DAOs can allocate or adjust the number of voters' Allocations through proposals. The allocation of this voting asset depends on the DAO's off-chain consensus, but it can also be verified on-chain.
Deposit and Allocation apply to Vintage and Collective DAOs, but not to Flex DAOs.
If the DAO sets ERC20/721/1155 Token or Deposit as the Voting Asset, changes in the voter's ERC20/721/1155 Token holdings or Deposit balance will affect their voting rights.
The ERC20/721/1155 voting asset type introduces open assets into the DAO voting system. The Deposit voting asset type allows a more direct binding between the DAO's governance rights and the DAO's interests. The Allocation voting asset type can map the data of off-chain assets and rights or subjective allocation intentions to the chain and make them callable.
Weight Algorithm
Weight Algorithm is a calculation method for converting Voting Asset into Voting Power. Using the Weight Algorithm to calculate the Voting Asset, we can find out how much Voting Power a voter (address) has in a vote. DAOSquare Incubator provides three weight algorithms: Quantity, Log2, and 1 Vote a Voter.
Quantity: Quantity is a very simple algorithm, which directly calculates the amount of assets held by voters. For example, if a voter deposits ERC20 Token RICE, Jack's voting weight is 1000. The same is true for ERC721/1155, Deposit, and Allocation.
Log2: log2 is a quadratic function (see Wiki for more information about log2). In simple terms, it reduces the gap between whales and small holders in influencing voting results. So log2 can reduce the impact of whale attacks on DAO governance to a certain extent.
1 voter a vote: If the 1 voter a vote weight algorithm is used, any voter who meets the Voting EligibIlity will be calculated as 1 regardless of the amount of voting assets held, as long as > 0.
Voting Judgment Algorithm
The Voting Judgment Algorithm is used to help DAO determine whether a vote should be passed. In the voting system of DAOSquare Incubator, the Voting Judging Algorithm consists of two parts: Support and Quorum.
Support
Support reflects the voting support rate, that is, the proportion of votes in favor in a vote or the absolute number advantage. Only when the support rate is higher than the proportion or number set by the DAO, will Support be counted as passed. There are currently two Support algorithms available for DAOs to choose from:
Algorithm A
Algorithm B
Quorum
Quorum reflects the voting participation rate, which is the difference (ratio or specific number) between the number of votes participating in a vote and the total number of votes that can participate in the vote. There are currently two quorum algorithms available for DAOs to choose from:
Algorithm A
Algorithm B
In a vote, the vote will be passed only if the support rate and participation rate both meet the Support and Quorum values set by the DAO.
Period
Period is used to set a valid time range for voting. Period includes two types of parameters: Voting Period and Execution Period.
Voting Period
Voting defines the length of the voting period (e.g. 1 hour, 3 days, etc.), during which all members with voting rights can participate in the voting.
Execution Period
When a vote ends and a result is generated, an execution action is required to trigger the contract to execute the voting result, such as investment payment, vesting creation, share NFT casting, etc. The ideal solution is that the contract can automatically execute these operations after the voting results are generated, but this will increase the technical difficulty and contract complexity, as well as the security risks that come with it. Therefore, we see that most executable voting systems (such as DAOhaus) manually trigger the execution of the contract (simple transaction confirmation), and the voting system of DAOSquare Incubator is no exception. Since the voting results have been generated, the voting results must be executed, so anyone can execute it, including non-DAO members.
The Execution Period only applies to investment proposals in Vintage DAO mode. Its purpose is to make investment proposals as unaffected as possible by redemption periods, refund periods (if the DAO sets these periods), and other investment proposals.
When a Proposer submits an investment proposal in a DAO in Vintage mode, the system will check the DAO's redemption period, refund period and other time settings. If the entire operation process of the investment proposal (voting period + execution period) conflicts with the DAO's redemption period or refund period, the system will reject the proposal.
Since Execution is a soft setting, there are two things to note:
Even if the system makes a time prediction when the proposal is submitted, if the proposal is not executed within 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, but the execution result may be inconsistent with the voting result (the vote passed but the execution failed). For example, the situation described in the previous note.
Example:
If a Vintage DAO does not set an Execution Period, an investment proposal may enter the redemption period after the voting period ends before it can be executed. The redemption behavior of investors is likely to cause the DAO fund balance to be less than the amount required by the investment proposal, causing the investment proposal to fail during execution.
If the DAO sets an Execution Period, for example, 2 days. When the Proposer submits an investment proposal, the system will calculate whether the "voting period + 2-day execution period" will enter the redemption period. If not, the investment proposal can be submitted. After the voting is over, the Governor (or anyone) has at least 2 days to execute the proposal. Of course, if it is not executed within 2 days, the change of funds during the redemption period may cause the investment proposal to fail to execute.
Due to the different operating mechanism, DAO in Flex mode does not have an Execution Period setting.
Example
Governor Voting
Voting Eligibility
Governor Role
Voting Power Algorithm
Voting Asset: Deposit
Weight Algorithm: Log2
Voting Judgment Algorithm
Support:: YES / (YES + NO) > 66%
Quorum: (YES + NO) / Total > 60%
Period
Voting Period: 3 Days
Execution Period: 1 Day
In this example, only members with the Governor status have voting eligibility, and their voting power is calculated using the Log2 algorithm based on their deposit balance in the DAO. The validity period of a vote is 3 days. When the support rate of a vote is higher than 66% and the participation rate is higher than 60%, the vote will be passed. The effective execution period of the proposal is 1 day.
Investor Poll (only for Flex DAO)
Poll (Voting) Eligibility
Type: ERC 721 (0x….)
Min holding: 2
Voting Power Algorithm
Voting Asset: ERC20 (0x…)
Weight Algorithm: 1 voter 1 vote
Voting Judgment Algorithm
Support: YES - NO > 10
Of which: YES + NO > 100
Period
Voting Period: 20 Hours
In this example, you must first hold 2 or more ERC721s to obtain Poll Eligiblity. The voting asset is an ERC20 Token, and the voting rights algorithm is 1 voter 1 vote, which means that anyone with Poll Eligibility is given equal voting rights, i.e. 1 person 1 vote, as long as they hold the ERC20, regardless of the number.
The effective voting period of a Poll is 20 hours. The minimum support rate is 10, and the minimum participation rate is 100, which means that the number of votes in favor must be at least 10 more than the number of votes against, and the total number of votes participating in the poll must be at least greater than 100 for the poll to be successful.
Summarize
The above is an introduction to the DAOSquare Incubator voting system. We hope to provide a decision-making system that can be applied to a wider range of scenarios, making on-chain venture capital easier to adopt, so as to better serve DAOs, institutions, communities, fund managers, and investors who are committed to decentralized venture capital. On the other hand, as technology advances, this system will continue to iterate (such as automatic execution). If you have any suggestions on mechanism design or technical solutions, please give us feedback, we will be grateful! If you want to try it, please contact us