Genesis Protocol
Last updated
Last updated
The Genesis protocol is an implementation of holographic consensus as a smart contract voting machine on our Infra layer.
Proposals are submitted to the DAO. Once submitted, they are “regular” proposals that require an absolute majority (>50%) of votes to pass, which is difficult to achieve.
Each proposal in the Genesis protocol also has a prediction market associated with it. This prediction market uses the GEN token. Members from the DAO or from the general public can stake GEN on proposals they think will pass (upstake) or fail (downstake) and get rewarded for correct predictions. By default, the DAO stakes GEN against every proposal passing (the "DAOstake"), which provides an economic incentive for predictors to find good proposals they predict will pass.
Proposals with total GEN predictions of passing above a certain threshold can be "boosted," meaning they only require a relative majority to pass, which is much easier to achieve.
In total, this lets the DAO pass proposals frequently and with high confidence, without requiring high voter participation, because the predictors are incentivized to insure high representativity.
An open proposal (i.e. with a pending decision) can be in one of the following stages:
Queued: All proposals, when submitted, are in a queued state by default and have a downstake (funded by the DAO) set by the minimumDaoBounty parameter. The proposal requires an absolute majority (i.e. > 50% of all voting power voting "yes" or "no") to resolve in this state.
Pre-boosted: A proposal moves from queued to pre-boosted if , where is the total upstake on a proposal, is the proposal's total downstake, is a constant, and is the number of currently boosted proposals. The proposal in this state is open for staking and can be moved back to queued state if the stake against it increases and proposals crosses back below the boosting threshold.
Boosted: Once the proposal has been in pre-boosted state for the period set by the preBoostedVotePeriodLimit parameter, the proposal moves to the boosted state. The proposal in this state requires a relative majority to pass (i.e more votes for than against). A proposal in this state is open for voting, but staking is closed. Thus, once a proposal is boosted it cannot be moved back to queued or pre-boosted state. The proposal stays in this state until the boostedVotePeriodLimit elapses.
QuietEndingPeriod: If the winning outcome of the proposal flips from 'pass' to 'fail' or vice-versa during the final period of time decided by the quietEndingPeriod parameter, then the proposal voting time gets extended by another quietEndingPeriod until decision does not switch during the period. This serves to prevent voters from "stealing" votes at the last minute.
The following are the possible outcomes of a proposal:
The proposal expires in queue without any decision. In this case, all the stakes are returned to the respective staker.
The proposal passes or fails. Losing stakers lose their stake, and winning stakers receive their stake plus a pro rata share of the loser's stakes. This includes the DAOstake, a downstake which the DAO places on each proposal automatically (if it has the funds to do so).
Note that for a given proposal, one can stake multiple times from the same address. In such a case all the subsequent stakes must align with the previous stake's vote i.e. if you staked in favor of the proposal earlier, you must stake in favor of the proposal in subsequent stakes.
Here is an explanation of the protocol's parameters, which you can find in the "Information" tab of any plugin that uses the protocol.
Address The Ethereum address where these parameters are stored (not where the protocol itself is). Example: 0x332b8c9734b4097de50f302f7d9f273ffdb45b84
Activation Time The date and time (represented in Unix time) when proposals in this plugin can first be submitted. Example: 12:00 PM UTC on July 14th, 2019 (active)
Boosted Vote Period Limit The length of time boosted proposals are open for voting. Example: 7 days (604800 seconds) DAO Bounty Constant This is multiplied by the average downstake on boosted proposals to calculate how large the DAO’s automatic downstake should be. Example: 10 Proposal Reputation Reward The amount of voting power given out as a reward for submitting a proposal that the DAO passes. Example: 500 REP Minimum DAO Bounty The minimum amount of GEN a DAO will stake when automatically downstaking each proposal. Example: 250 GEN Pre-Boosted Vote Period Limit The length of time that a proposal must maintain a confidence score (upstake divided by downstake) higher than the boosting threshold to become eligible for boosting. Example: 1 day (86400 seconds) Queued Vote Period Limit The amount of time non-boosted proposals (pre-boosted or regular queue) are open for voting. Example: 45 days (3888000 seconds) Queued Vote Required The percentage of all Reputation (voting power) that must be voting yes or no for a non-boosted proposal for it to pass or fail. Example: 50% Quiet Ending Period The length of time a vote’s potential result needs to stay the same in order to be confirmed as the official result. Example: 2 days (172800 seconds) Threshold Constant Controls how quickly the required confidence score for boosting goes up as the number of currently boosted proposals rises (threshold = threshold constant ^ number of currently boosted proposals). Example: 1.2 Voters Reputation Loss The percentage of a voter’s voting power they stand to lose if they vote against the DAO’s eventual decision on a non-boosted proposal. If you have 100 Reputation and this parameter is set to 4%, you stand to lose 4 Reputation. Example: 4%