7. DAO Voting

When setting up a DAO, it will be possible to define parameters related to DAO voting, including defining who is allowed to vote: all GT wallets (DAO participants) or only those that meet certain criteria. It can be implemented that wallets admitted to voting receive special NFTs. In this case, only those wallets that have the required minimum GT balance and corresponding NFTs will be allowed to vote. Examples:

· For a certain DAO, the KYC procedure is mandatory for voting participants, which can be carried out by an external provider, for example, Blockpass. DAO participants who have successfully passed KYC will receive the appropriate NFT and will be allowed to vote;

· In order to protect against attacks, the DAO may decide that it will only allow GTs that are held in their customers' wallets or have been staked for at least N months at the time the votes are cast.

In addition, when setting up a DAO, it will be possible to determine:

· Minimum and maximum deadlines for the Proposal and Investment Project to pass all required stages.

· Priority of a Proposal in the Voting Queue, depending on its level of support at the stage of the Proposal List.

· How many Proposals and Investment Projects can be voted on by the DAO at the same time (in the basic setting — 1).

· If there are Investment Projects in the Voting Queue that have been approved by already "dismissed" Protectors or Experts, should the Platform once again recalculate the Expert and Protectors' votes on them (as a result such projects may be rejected) or do nothing?

· Disabling/enabling Ragequit functionality.

· Ragequit Cancellation Threshold. How many GTs must be submitted for the Ragequit redemption so that the decision can be canceled and the Ragequit will not take place.