This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
voting_system_overview [02/07/2022 08:39] – gfactor | voting_system_overview [03/11/2022 15:02] – gfactor | ||
---|---|---|---|
Line 6: | Line 6: | ||
The Founder accounts will have a different weighted vote that is based on their blocks minted count PLUS level 10 blocks minted count. What we mean by this, as seen on the [[Leveling System]] wiki page, for an account to reach level 10 requires 4,074,400 total blocks minted. So Founder accounts will have a weighted vote of 4,074,400 PLUS their actual blocks minted count. For a simple example, if a Founder has 100 blocks minted, the account would have a weighted influence of: 4,074,400 + 100 = 4,074,500 | The Founder accounts will have a different weighted vote that is based on their blocks minted count PLUS level 10 blocks minted count. What we mean by this, as seen on the [[Leveling System]] wiki page, for an account to reach level 10 requires 4,074,400 total blocks minted. So Founder accounts will have a weighted vote of 4,074,400 PLUS their actual blocks minted count. For a simple example, if a Founder has 100 blocks minted, the account would have a weighted influence of: 4,074,400 + 100 = 4,074,500 | ||
- | When the first Founder | + | When the first Founder reaches level 10, those who were given pre-enabled levels from QORA will be given a ' |
- | Voting will be used to help steer the project’s direction. Rather than leaving everything up to the DevTeam, the community will be able to vote on certain matters | + | This penalty (just a technical term) is simply to be sure the voting system is fair for everyone who actually started at 0 blocksMinted at Genesis, including but not limited to the Founders. Therefore this is simply an effort to 'level the playing field' for those who did NOT have pre-enabled blocks minted. The Founders have level 10 + blocks minted, until the first Founders actually reaches level 10, then they are simply blocks minted like everyone else. At the same time, those who were given pre-enabled levels get the penalty for however many blocks they were credited with at Genesis. |
+ | |||
+ | Voting will be used to help steer the project’s direction. Rather than leaving everything up to the DevTeam, the community will be able to vote on certain matters | ||
Voting will also be used for the community to help approve new developers as an admin of the DevTeam. What this means is that we have two types of DevTeam members: 1) anyone can join the team and help develop the codebase who DO NOT have the ability to vote on the 60% approval to push updates to the chain, and 2) DevTeam admins who DO have the ability to vote on the 60% approval to push updates to the chain. The DevTeam would notify the community of the vetted developers being entered into a community vote, then the community will vote to approve the DevTeam admins to push the update with their 60% approval. This update will then assign the admin permission to the vetted dev(s) and it's official. It is extremely important to have this layer of security with these two types of DevTeam members as the DevTeam admins will be the only ones who can vote for a 60% approval to push updates. This creates a way for the community to have a say in who becomes a DevTeam admin, and the DevTeam admins keep the rest of the DevTeam in check as DevTeam admins are the only devs who can push the 60% approval updates to the chain. | Voting will also be used for the community to help approve new developers as an admin of the DevTeam. What this means is that we have two types of DevTeam members: 1) anyone can join the team and help develop the codebase who DO NOT have the ability to vote on the 60% approval to push updates to the chain, and 2) DevTeam admins who DO have the ability to vote on the 60% approval to push updates to the chain. The DevTeam would notify the community of the vetted developers being entered into a community vote, then the community will vote to approve the DevTeam admins to push the update with their 60% approval. This update will then assign the admin permission to the vetted dev(s) and it's official. It is extremely important to have this layer of security with these two types of DevTeam members as the DevTeam admins will be the only ones who can vote for a 60% approval to push updates. This creates a way for the community to have a say in who becomes a DevTeam admin, and the DevTeam admins keep the rest of the DevTeam in check as DevTeam admins are the only devs who can push the 60% approval updates to the chain. |