The Predictor's Bias Problem

This is part of the Genesis Protocol V0.2 research umbrella.

The specific topic is predictor’s bias towards success of proposals.

Here is the currently implemented protocol.

There was a bunch of discussion in the comments of the google doc on this one, and I thought it might be helpful to try organizing it a bit here.

The Problem

Anyone can boost a proposal by putting sufficient upstake all at once and leave no downstake whatsoever, and thus no skin in the game to call for “negative voters.”

Attempting to put it another way: Starting with a brand new proposal with 0 staked GEN on it, we can see from the protocol that there is an incentive to place upstake (stake that a proposal will pass) – you will receive a share of B1, the DAO bounty for stakers, if the proposal passes, even if no one else stakes – but there is no incentive to place downstake until after someone has upstaked – downstaker rewards draw only from failed upstake.

It’s also fairly affordable to pay for the entire upstake necessary to boost a proposal all at once, or at least very quickly. When that happens, no one has a chance to place downstake on it, since boosted proposals cannot be staked on.

Since new proposals only incentivize upstake, and then that upstake boosts the proposal quickly, there is often never an incentive nor much of a chance to downstake on a proposal. That’s a problem because it’s probably not very collectively intelligent: instead of taking advantage of the wisdom of crowds, it’s often just the “wisdom” of the lucky person who gets to stake first.

Community Suggestions So Far

An idea from Daniel Shavit: change the boosting threshold to require not only a certain score based on stake (upstake - downstake), but also a minimum number of staking addresses. If the problem is mostly that a single person is taking the proposal from 0 to boosted too quickly, we could require stakes from multiple addresses to slow this down. The minimum number of addresses might depend on the DAO’s activity level (ahem measure of collective attention supply) and on the current number of boosted proposals (as the current threshold does). One issue with this is that it’s fairly easy for one person to stake from multiple addresses, since staking doesn’t require Reputation.

  • Another option here: create rules for maximum positive stake sizes that prevent one address from boosting a proposal from 0 in one stake. (maximum size of stake n = stakeNeededToBoost / someConstant^n, something like that?). Has similar issues to the above idea, though.

Idea from Matan’s doc: Put unboosted proposals into two categories: upstake-only, and downstake-allowed. At first, proposals would only allow upstake. Once their score passes the boosting threshold, though, instead of boosting right away, we delay boosting for a certain period and allow both upstaking and downstaking in that period. This guarantees that there is some chance to downstake on every proposal.

  • Daniel brought up the question of what happens to the proposal if its score goes below the boosting threshold during the downstake-allowed phase: does it still get boosted after time is up? Does it go back to upstake-only? Does it stay in the downstake-allowed phase until it either times out or has a score of the boosting threshold for a minimum amount of time?
  • Pat built on Daniel’s point by suggesting that enough downstake could “unboost” a proposal and return it to the regular cue (not sure how exactly this suggestions interacts with Matan’s, perhaps Pat can clarify)
  • Here’s another version: instead of upstake-only, downstake-allowed, and boosted (no staking) proposals, we keep the current two categories (unboosted and unboosted), but we change the rules a bit. For the first x hours a proposal is boosted, you can still upstake and downstake on it. If its score goes below threshold in that time, it gets unboosted. If its score goes back above threshold, it gets boosted again, and the x hours (along with the voting time limit) get reset.

Idea from the related downstake before upstake discussion: Pay a small DAO bounty to downstakers (smaller than the current rather large one for upstakers), and prevent a spam proposal-creation-and-downstake attack (farming the DAO bounty) by offsetting the downstake bounty with a modest proposal submission fee.

1 Like

To have a clear dimension:

what are the drawbacks of a simple method to fix a period of time for stacking to boost up and to boost down?

Fixed period ends —count the results of stacking — proposal is boosted or is not.


Good question, Dmitry. That’s a new idea to me. Some drawbacks might be:

  1. It would add to the minimum time it takes to pass a proposal via relative majority. Not sure how big a deal this is, perhaps some others can offer thoughts.

  2. Proposals have just one chance to get boosted, which they might easily miss in a confusing way. For example, say proposal 1 is submitted before proposal 2. The score that proposal 2 needs to reach by the end of it’s minimum staking period is partially determined by whether or not proposal 1 reaches it’s threshold. You might think that proposal 2 is above the threshold because proposal 1 looks like it won’t be boosted, but then proposal 1 is boosted at the last minute, meaning proposal 2 now needs a higher score. If it doesn’t get that score in the remaining time, it will never be boosted under this system, right? With a chain of 10 proposals instead of 2, this might get pretty crazy.

1 Like

The answer is fairly simple, in my opinion. It seems like bad UX. The proposal queue already uses a lot of screen space: prioritizing a “third” category representing the period of time before a proposal jumps queues would use even more space – and I’m willing to bet would add an additional layer of complexity that would confuse the end user.

Added some points about this issue: (and keep editing).

1 Like

Thank you for your replies!
I`ve looked through the discussion in a ‘No-downstakers bias’ doc also.
I like “limited time downstaking” solution.

But from my perspective even in this solution there are two nuances:

(1) according to the Holographic Consensys concept rep.holders vote only on boosted proposals -
that is the purpose of boosting - to signal to voters about the current level of attention. If the proposal is deemed boosted it is ready for voting. “Boosted” means it had gained enough attention already. Accordingly, all that up- and down-staking tug-of-war must happen and come to the end before the proposal would be considered boosted. How the proposal is supposed to be boosted and then unboosted and then perhaps boosted and unboosted again - from the logic of voting on it?

(2) to my mind its better to keep voting period completely distinct from staking period. Staking period should better stop before a voting period starts. Stakes made - signal for voters produced - voting period opens.

~ do we also keep upstaking open during this period? yes, to give opposite parties equal chances
~ do we push a proposal back to regular queue if downstake reduces it off boosting criteria…? yes, but better not to let it pop up from a regular queue until the end of boosting tug-of-war


“it will never be boosted under this system, right”?
That may be, but with a slightest difference - this proposal is not boosted in this session of boosting tug-of-war.
It returns to the regular queue, all stakes nullify and boosting race can start again )

1 Like

Hey D! Yes, keeping staking and voting mostly separate is vital, I think. It could be okay to let proposals get boosted and unboosted, though – given that the time limit is reasonable. If the proposal can only get staked on at the beginning of it’s boosted period, it’s likely that few votes will accrue while staking is allowed, so the conflict of interest shouldn’t often be an issue. It would technically be possible for a proposal to go back and forth between boosted and unboosted, continuing to accrue votes, but if it remains unclear whether the proposal will pass or fail, the stakes should still be relatively honest.

Also, I realized I was being maybe a little silly saying proposals have just one chance to be boosted in the minimum staking time model: after the time limit ends, proposals could just default to the current system, right? They could be boosted instantly anytime with enough upstake after the minimum time passes.

This makes me think of another idea: connect the remaining staking time with the absolute value of the “reputation score” of the proposal (where reputation score is something like (reputation_voting_for - reputation_voting_against)/total_reputation). The higher this “absolute reputation score,” the more decisive the voting is, the more compromised staking would be, and the less staking is needed to bring the attention of the DAO – so as absolute reputation score goes up, the remaining time for staking should go down. This could potentially be an entirely separate system than boosting: let proposals get boosted all they want. People can continue staking until decisive votes start coming in, at which point staking must stop. What about that?


The closer a teacher is to the classroom door, the quieter are the students))) Its a marvelous idea!

1 Like