The Genesis protocol is an implementation of holographic consensus as a smart contract voting machine on our Infra layer.

Quick Overview‌

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 or fail, and get rewarded for correct predictions. By default, the DAO stakes GEN against every proposal passing, 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.

In total, this lets the DAO pass proposals frequently, without requiring high voter participation, because the predictors are incentivized to insure high representativity.

Proposal States

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% vote) to pass in this state.
• Pre-boosted: Once the stakes in favor of the proposal crosses the required boosting threshold*, it moves from queued to preboosted state. Note that this boosting threshold can be fixed, or it can increase as the number of boosted proposals increase (explained at the end of this section). 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 preboosted state for period set by the preBoostedVotePeriodLimit parameter, the proposal moves to boosted state. The proposal in this state requires a relative majority to pass (i.e votes(For) > votes(Against)). A proposal in this state is open for voting but cannot be staked on. Thus, once a proposal is boosted it cannot be moved back to queued or preboosted state. The proposal stays in this state until 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 quietEndingPeriod until the above condition is true.
• A proposal is boosted if the following is true: stakes(For)/stakes(Against) > (thresholdConst)^(#already-boosted-proposals)

Note that thresholdConst can be 1, in which case you only need stakes(For) > stakes(Against).

Staking & Rewards

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: Staker(stake(for) amount)*daoBounty/(total winning stake)
• The proposal fails: Losing stake is lost

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 staked in favor of the proposal earlier you must stake in favor of the proposal in subsequent stakes.