We're excited to share some of mechanics and technical designs of the DAOSquare Incubator, such as the voting system described in this article. The goal of these designs is to provide a better on-chain investment experience and make them conform to the concepts of decentralized, open, verifiable, trustless, permissionless, etc. In this article, we will introduce the voting system in DAOSquare Incubator.

In the DAOSquare Incubator, or the scenario of on-chain investment, the purposes of voting typically include the following aspects: investment decisions, member management, fund management, system parameter adjustment and contract upgrades. Unlike regular voting, voting in DAOSquare Incubator is executable. This means that the voting results will definitely be implemented, and there is no possibility of human control of execution.

For example, when an investment proposal is approved, the money will be transferred from the DAO to the investee, At the same time, a vesting contract is deployed for all investors participating in the investment to claim the investee's tokens during the vesting period (or mint NFTs for investors representing their share of the investment). This technology-based certainty protects the interests of both investors and investees. The investees can definitely receive the investment funds, and investors can definitely receive the tokens or future vouchers (share NFTs) from investees.

This certainty is also reflected in inviting a new member to become the role of Governors, modifying the maximum number of Investors, and so on. In short, in DAOSquare Incubator, voting follows a specific action that will definitely be executed.

Almost all DAOs have different voting strategies, which means that an open, customizable voting system is necessary. So we aim to provide legos so that users can customize the voting system to suit their needs.

Overall, the voting system consists of the following categories of 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: based on what to vote (Voting Asset), and how to give voters weights based on those voting assets (Weight Algorithm).
  • Voting Judgement Algorithm:  Providing judgment parameters to voting through various optional Support (support rate) algorithms and Quorum (participation rate) algorithms. DAOs can set values for Support and Quorum to determine whether a vote should be approved.
  • Period: Specifies the validity period of a proposal. It consists of two parameters, the Voting Period and the Execution Period.

Now, let's introduce them in detail.

Voting Eligibility

Voting Eligibility defines who is eligible to vote, but not how big of voting power. A member may be eligible to vote but may have zero voting power (which depends on the Voting Power Algorithm). Here Voting Eligibility defines “who is eligible” only.

In the DAOSquare Incubator, users can create and participate in three different modes of Venture DAOs, which are managed and maintained by the Governor role. The Governor role can be a group of people or a single person (depending on the type of venture and the mechanism design of the DAO). Matters under the Governor's management are usually decided by voting. Certain types of DAOs, such as Flex, also provide an Investor Poll, which has a similar voting mechanism.

Scenario 1:Governor Voting

Whether a user is entitled to participate in the Governor Voting (Governor Voting Eligibility) is determined by whether the user is holding the Governor role of DAO. As for how to become a DAO Governor and who qualifies to be Governor, we wll cover this in a future article. In short, the DAO Governor is eligible to vote for issues under the Governor's management scope.

Scenario 2: Investor Poll (Voting)

Flex DAOs in DAOSquare Incubator can choose to start a poll (aka temperature-check) to determine whether the investment proposal is necessary to launch. The DAOs also need to set who can participate in the Poll (Poll Eligibility).

Currently, Poll Eligibility in DAOSquare Incubator offers four on-chain verification methods (choose one out of four) :

  • ERC20: requires the minimum number of ERC20 tokens to be held
  • ERC721 (NFT): requires the minimum number of ERC721 tokens held
  • ERC1155 (NFT): requires the minimum number of ERC1155 tokens held
  • Whitelist: a list of wallet addresses

When a user meets the Poll Eligibility set by the DAO, he/she will automatically be eligible to vote in the Poll without the need for any role approval.

Voting Power Algorithm

The Voting Power Algorithm defines how to calculate a voter's voting power, needs a setting for Voting Asset and Weight Algorithm.

Voting Asset

Voting Asset refers to what votes are based on and is the basis for obtaining the voting power. Simply, a voter's voting power is the value (and proportion) derived by the Voting Asset calculated by the Weight Algorithm.

DAOSquare Incubator's voting system offers five on-chain verifiable options for Voting Asset:

  • ERC20: Use ERC20 tokens as Voting Asset. For example, a community-based fund could set up that community's token as a counting asset.
  • ERC721: Use ERC721 tokens as Voting Asset.
  • ERC1155: Use ERC1155 tokens as Voting Asset.
  • Deposit: Use the deposit balance of Investors in the DAO as the voting asset.
  • Allocation:  Manually allocated Voting Assets. DAO Governors can adjust the amount of allocated voting assets for voters through the DAOset proposal. The allocation of voting assets depends on the DAO's off-chain consensus. Once a manual allocation of voting assets has been made on-chain, the voting assets can also be verified on-chain.

Deposit and Allocation apply to DAOs in Vintage and Collective mode, but not to DAOs in Flex mode.

If the DAO sets the ERC20/721/1155 tokens or Deposit as Voting Asset, changes in the voter's ERC20/721/1155 token holdings or deposit balance affect their voting power over time.

The Voting Asset type of ERC20/721/1155 are to introduce open assets into the DAO voting system. The Voting Asset type of Deposit can establish a more direct binding between the DAO's governance rights and the DAO's interests. The Voting Asset type of Allocation can map the off-chain data or subjective-will to on chain and become callable data.

Weight Algorithm

The Weight Algorithm is a calculation method that converts voting assets into Voting Power. The Weight Algorithm applies to the Voting Asset to determine 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 that directly counting the voter's holdings of voting assets. For example, if a DAO decides to use ERC20 token $RICE as a Voting Asset, Jack holds 1000 $RICE, and Jack's voting power is 1000. The same applies to ERC721/1155, Deposit, and Allocation type of voting assets.
  • 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 whales and small holders. So, in some ways, log2 can reduce the whale effect (whale attack) on DAO governance.
  • 1 voter a vote: If the 1 voter a vote weight algorithm is used, any voter who meets the Voting EligibIlity criteria, as long as it holding voting assets is bigger than 0, voting power of the voter will be counted as 1.

Voting Judgment Algorithm

The Voting Judgment Algorithm is used to help a DAO determine whether a vote should be approved. In DAOSquare Incubator's voting system, the Voting Judging Algorithm consists of two parts: Support and Quorum.


Support is the percentage or absolute number of the difference between pros and cons. Support will only be counted as a pass if it is higher than the percentage or number set by the DAO. There are currently two support algorithms available for DAOs to choose:

Algorithm A

Algorithm B


Quorum represents the voting participation degree.  It can be the ratio between the number of participated votes and total eligible votes. It also can be the minimum requirement of a total number of participating votes. Below are the two quorum algorithms available to DAOs:

Algorithm A

Algorithm B

In a vote, only if the Support and Quorum meet both the values set by the DAO, will the vote be approved.


The period is used to set a valid time range for voting. The period includes two types of parameters: The Voting Period and the Execution Period.

Voting Period

Voting Period defines the length of a voting (e.g., 1 hour, 3 days, etc.) during which all voting members are allowed to vote.

Execution Period

When a vote is completed, an execution action is required to trigger the contract to execute vote result, such as investment fund transfer, vesting deploying, investment share NFT minting, etc. Ideally, the contract would perform these actions automatically when the vote is done, but this would add technical difficulty and contract complexity, as well as security risks. Thus we see that most executable voting systems trigger contract execution manually (simple transaction confirmation), and hence DAOSquare Incubator's voting system is no exception. Since the result of the vote has already been generated, the result of the vote must be executed, so anyone can execute it, including non-DAO members.

The Execution Period applies only to investment proposals for Vintage DAOs. The goal is to keep the investment proposal as unaffected as possible by the redemption and refund period (if the DAO sets these periods), and other investment proposals.

When Proposer submits an investment proposal in a Vintage DAO, the system checks the DAO's redemption period, refund period, and other time Settings. If the entire processing time of the investment proposal (voting + execution period) conflicts with the redemption period or refund period of the DAO, the system will reject the proposal submission.

Since Execution is a soft setup, there are two notes:

  • Even if the system makes a time prediction when the proposal is submitted, if the proposal is not executed within the Execution Period, an approved proposal may still 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 not be consistent with the result of the vote (the vote passed but the execution failed). For example, the situation described in the previous note.

Example of Execution Period

If a Vintage DAO does not set an Execution Period, an investment proposal may enter the redemption period before being executed after the voting period. The investor's redemption behavior is likely to cause the DAO fund balance to be less than the amount required by the investment proposal so the investment proposal fails at the time of execution.

If the DAO sets an Execution Period, such as 2 days. When proposer submits the investment proposal, the system calculates whether the "voting period + 2-day execution period" will enter the redemption period, and if not, the investment proposal can be submitted. After the vote, the Governor (or anyone else) has at least 2 days to execute the proposal. Of course, if it is not executed within 2 days, changes in funds during the redemption period may cause the proposal execution to fail.

Flex mode DAOs do not have an Execution Period setting due to their different operation mechanisms.


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 the governors are eligible to vote, and their Voting Power is calculated using the Log2 algorithm to calculate their Deposit balances in the DAO. Voting Period lasts for 3 days. When a vote has more than 66% on Support and more than 60% on Quorum, the vote will be approved. 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
  • Quorum: YES + NO > 100
  • Period
  • Voting Period: 20 Hours

In this example, first, you must hold 2 or more of a certain ERC721 tokens to gain Poll Eligibility. The Voting Asset is an certain ERC20 token, and the Voting Algorithm is 1 voter 1 vote, which means that the user with the Poll Eligibility, as long as the ERC20 is held, no matter how many, are given the same voting rights, that is, 1 voter 1 vote.

The Voting Period for the Poll is 20 hours. The minimum support requirement (Yes - No) is 10 and the minimum quorum requirement (Yes + No) is 100, which means that the number of YES votes must be at least 10 more than the number of NO votes, and the total number of votes cast must be at least 100 for the poll to be successful.


That's all about the DAOSquare Incubator voting system. We aim to provide a decision system that can be adapted to a broader landscape and make on-chain ventures 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, the system will continue to update (e.g. automate execution). If you have any suggestions on the mechanism design or technical solutions, we would appreciate your feedback!

If you wish to try the DAOSquare Incubator as an early bird, please do not hesitate to contact us.

January 26, 2024