The Problem of Voting Rewards

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

The specific topic is voting rewards.

In my opinion, the current protocol spec is essential reading for these research topics.

Conclusions and Suggestions So Far (TL;DR)

I assume our goal with the voting protocol is for boosted proposals passing or failing to represent the collective views of all reputation holders.

We strongly incentivize people to vote on all boosted proposals — you get a GEN reward no matter how you vote, and you can’t lose reputation. The GEN reward was originally not intended, and it may be problematic in that it incentivizes bot-voting. I suggest either getting rid of it or trying some version of “budgeted voting” (see below).

We have weaker incentives to vote on non-boosted proposals, except when they have large stakes and the voter is confident, but non-boosted proposals aren’t intended to pass unless they get boosted anyway, so this doesn’t matter very much.

Reputation penalties and rewards from voting are very small, and only apply to non-boosted proposal voting, which we don’t incentivize strongly. It likely takes dozens of this type of reward in order to equal the reputation reward of getting your proposal passed. Is the voting reputation reward a useful system? Should we get rid of it? Should we change it?

Current State of Things

The current consequences of voting are as follows:

If you vote on a non-boosted proposal, then when the proposal fails or succeeds:

  • If you voted with the DAO’s decision,

    • gain (.8*total_rep_lost_by_opposite_voters) * (your_rep/total_rep_voting_right) REP
    • gain (0.5*(total_staked_for + total_staked_against)) * (your_rep/total_rep_voting) GEN
    • lose gas fee
  • If you voted against the DAO’s decision,

    • lose (.01*your_rep) REP
    • gain (0.5*(total_staked_for + total_staked_against)) * (your_rep/total_rep_voting) GEN
    • lose gas fee

If you vote on a boosted proposal, then when the proposal fails or succeeds:
(Intended: gain and lose nothing)
Currently implemented:

  • Whether you voted with or against the DAO’s decision, gain (0.5*(total_staked_for + total_staked_against)) GEN and lose gas fee

Please correct me if I’ve missed or misrepresented anything that’s currently implemented.

Currently, then, the incentivized voting behaviors, from most to least incentivized, are:

  1. Vote on a non-boosted proposal that has a large stake in the same direction the DAO will eventually decide on it (REP and GEN gain, gas loss).
  2. Vote on a boosted proposal (GEN gain, gas loss).
  3. Vote on a non-boosted proposal in the opposite direction from what the DAO will eventually decide on it (GEN gain, gas and REP loss).

To understand what strategies people might adopt, though, we also need to take into account absolute amounts of the various rewards and penalties.

  • REP loss of (.01*your_rep): it’s normal to have about 250 or 1% reputation right now, so you’d be losing 2.5 or .01%, a fairly small loss.

  • REP gain of (.8*total_rep_voting_wrong) * (your_rep/total_rep_voting_right): This comes out of the total rep lost. Let’s be generous and say 10 people lost 2.5 REP each, so the total_rep_lost pool is 25. Let’s say 11 people with equal reputation voted the other way, since on average it will be more people on the winning side. Each of the 11 would gain 1.8 REP, which is very little. Reference the average amount new members start with (100 or more) or the amount people ask for when proposing (50 or more), not to mention the baseline reputation successful proposers gain.

  • GEN gain of (0.5*(total_staked_for + total_staked_against)) * (your_rep/total_rep_voting): Many proposals have at least 100 GEN staked by the time they pass or fail (about $10 USD). If 10 people with equal reputation voted (which is something like the average), they would each gain 5 GEN, or about $0.5 USD.

  • Gas loss: Gas costs vary a lot, but in my experience a vote usually costs around $0.2 USD. It’s reasonable for GEN gained to be higher than gas costs, and could be much higher if the average stake goes up.

What are the profitable strategies here?

If it’s true that GEN rewards are implemented for all votes, not just those on non-boosted proposals, then people should vote on every boosted proposal, because they’ll get nearly risk-free profit. If this is the case, I would bet a few people who have voted much more than the rest have received rather large amounts of GEN from this.

People should vote on non-boosted proposals only if the proposals have large stakes and/or if they’re confident the proposal will pass or fail, since they will only gain GEN if there’s stake, and if they vote against the DAO’s eventual decision, they will lose reputation.

We should also remember that there are some important non-empirical incentives, such as:

  • If you vote on a proposal, it’s more likely to pass or fail, one of which you may intrinsically want
  • To vote for a proposal responsibly, you must spend the time to actually understand it

Both of these qualitative motivations mostly incentivize people to pay attention to only boosted proposals, since they are realistically the only proposals with good passing chances.

What problems are there?

One suggested problem is “bot-voting”: in a DAO where I don’t care about the outcomes of proposals but I have reputation, why not just run a script that automatically votes randomly on every boosted proposal to farm GEN? There are a few answers here: one is to eliminate the GEN reward from boosted proposal voting. That might work, since the strong intangible incentive to vote on boosted proposals (whether or not you want the proposal to pass) might be enough to maintain acceptable participation rates.

A better solution, though, might be some form of “budgeted voting”: if I have 200 reputation, I can vote by “placing” 100 of it on a proposal. I have only the second 100 left for voting until the first 100 is freed up by the proposal passing or failing. (You could place more reputation into a proposal before its time is up, but not take any out or switch the direction of your vote). This would prevent effective bot-voting and perhaps have a positive effect on the DAO’s intelligence.

There are also problems with the incentives for non-boosted proposal voting. To maximize rewards, voters should really act as predictors, predicting what they think other voters will think, instead of expressing their own views. If too many people vote that way, what has happened to the DAO’s collective intelligence? This is confusing, but luckily, I think it doesn’t matter very much, since 1) there isn’t strong incentive to vote on these proposals, 2) that has played out in the DAO’s behavior so far, 3) what we really care about for non-boosted proposals is predictions, and that’s what staking is for.


Thank you for breaking down the REP rewards for proposals for those who are new like myself. To expand upon your description of “budgeted voting” you should also be to realize rewards beyond proportions to your staking amount.

For example, proposals that conclude in opposition to the predictors could reward their voting body with more REP (possibly mined from the predictors who lost). This would benefit the collective intelligence because you could imagine this would be giving more influence to those with better local knowledge to that proposal (the successfully formed coalition). Especially if the predictors experience an upset, you could payout logarithmically to not just the speculators but voting body itself.

One vulnerability I see in both systems is that what if another DAO starts forming between members within the protocol and it starts aggregating rewards from proposals its published. It can then distribute those rewards to other members within the GenesisDAO to try and continue to create it’s own incentives to participate, boost proposals, etc. Generally speaking, not being able to determine members of DAOs / from actually members themselves makes this even more complicated when you want to determine who are these voting coalitions or bad actors.


How would budgeted voting address the bot voting issue?

A bot could repeatedly place all its REP on the majority side of unboosted proposals that are close to ending. If you always vote one or two blocks before the proposal expires, then you can still vote with full power on all proposals that aren’t ending simultaneously. You wouldn’t even need to be very confident that the proposal will pass or fail, just needs to be leaning slightly above or below 50%.

Budgeted voting could improve preference signaling when used by humans who diligently allocate their REP across active proposals, but I don’t see how it affects the payoff/penalty matrix around using a bot. These bot votes would harm collective intelligence since they are effectively “free-riding” on expressed preferences– gaining the benefit without putting in the due diligence effort.

I think it makes more sense to remove GEN rewards and keep REP rewards/penalties. GEN has economic value that can be immediately realized for profit. In contrast, profiting maliciously from REP would take significantly more time and planning. GEN would still create a network effect around the predictor market, incentivizing good predictions and penalizing bad ones.


That’s true, Ori, I didn’t think about the timing. What if we just stopped giving GEN rewards for votes on a proposal with less than X hours left? That would make spamming much more difficult with a budgeted voting system.

In general, I’m probably most in favor right now of 1) a budgeted voting system for the preference signal improvement and 2) also eliminating GEN rewards from voting on boosted proposals–it seems like there will always be a strategy to abuse those rewards. I think the motivation of wanting a proposal to pass or fail may be strong enough on its own.

REP rewards and penalties for boosted-proposal voting have the exact same issues, I think. I don’t see how profiting maliciously from REP farming is less dangerous: you can do a 51% attack on the DAO, controlling everything it does forever (grabbing significant chunks smaller than 51% is also pretty problematic). If you reward voting for a boosted proposal that eventually passes (or vice versa) with REP, the strategy of last-minute voting is still abusive. You also incentivize people to vote with the perceived majority instead of their own beliefs. If you just reward all boosted-proposal votes with REP, then the strategy that exists now of voting on everything abuses that.


Thanks for the super detailed rewards breakdown Ezra.
“1. Vote on a non-boosted proposal that has a large stake in the same direction the DAO will eventually decide on it (REP and GEN gain, gas loss).
2. Vote on a boosted proposal (GEN gain, gas loss).
3. Vote on a non-boosted proposal in the opposite direction from what the DAO will eventually decide on it (GEN gain, gas and REP loss).”
Members should learn to recite this like a prayer.
I like the budgeted voting altho i can see some attack vectors (for example bait and switch by locking your opponent coalitions into less meaningful votes) and would rather have bots vote (to bring out the A of DAOs).
100% agree GEN farming opportunities should be eliminated.
I was thinking for REP of a degressive rewards scale over % voted in, such that early voters are rewarded and the more you go forward the less it’s beneficial, while leaving some residual profit. In this way voting on everything is not profitable as the reward becomes small and given a certain % of losses should not compensate you for the winning random bets.
To be bespoke for a DAO the speed of the decrease in awarded REP could be dynamic and change according to the moving average in % needed to win a vote in a DAO.


I like stopping GEN rewards near the end of the voting period to address the problem. GEN rewards could even be scaled down along some curve– let’s say linearly– to reward early voters who vote with the DAO’s decision more than those who “follow the crowd”. As an aside: I think a mechanism like this could be even more useful for the predictor’s protocol… instead of just splitting the reward among successful predictors in proportion to their stake you also at a weighting factor to give earlier predictors a bit more and later ones a bit less.

These suggestions would work to prevent bot-voting even without budget voting so I think they should be considered as their own class of anti-gaming measures.

One quick thing to note about budget voting is that while it could ultimately improve preference signaling, in the short-term it might just confuse users who are used to binary yes/no voting. A good U.I. for distributing a finite amount of votes across different proposals sounds pretty challenging.


Looks like @cryptodani had a similar idea about time digressive rewards^^ Nice!


Definitely has the potential to confuse! (edit: referring to budgeted voting here – so many posts so fast) It isn’t too too different from staking, though, which gives me some faith people could figure it out. It would be a big change, though, one I’m not sure is in the possible scope for this upgrade period. Matan will have to say for sure on that.

Stopping the rewards near the end of the voting period does only help for budgeted voting, though, since if you don’t have to “spend” your REP, there’s no reason a bot/spammer would have to wait til the end of the period to vote (as long as the outcome for voting on a boosted proposal is always a reward).

Edit: Also, to be clear I think the schelling point reward/penalty model has a detrimental effect on preference signaling: it incentivizes you to predict what everyone else will think rather than express your own views. That’s the incentive we want for stakers, not for voters. So even though this mechanism helps stop abuse, I’m pretty against using this type of reward/penalty system (for GEN or REP) in boosted-proposal voting. Unless I’m missing something? Is there a better way to include REP penalties in boosted-proposal voting?


“As an aside: I think a mechanism like this could be even more useful for the predictor’s protocol… instead of just splitting the reward among successful predictors in proportion to their stake you also at a weighting factor to give earlier predictors a bit more and later ones a bit less.”

Rewards could be allocated this way either with a proposal specific bonded curve contract in which the staked amounts are put into (with a possible reserve going to finance the DAO or subsidising other groups) , or adding a pre-calculated time discounting factor to the following formula from Genesis v1:
Gain=0.5*(total_staked_for + total_staked_against)) * (your_rep/total_rep_voting) GEN
Time discounted gain=(0.5*(total_staked_for + total_staked_against)) * (0.5( (your_rep/total_rep_voting)+(t))) GEN/

Where t is a time discount factor between 0 and 1 described by a function which can be of any shape in order to incentive different time responses (for example skewing rewards significantly towards early stakers).
If a member increases his stake at different times we can weight t according to time of stake.
We can also modify the weighting (here 0.5) between reputation and time.


Very into this! We should port this over to a thread about staking, though, since there are also a few research topics in that area this would be relevant to.

1 Like

Great stuff Ezra!

— almost correct. We strongly want to incentivize voting on every boosted proposal indeed. In practice, in the current version of Genesis we actually reward voting only on proposals before they get boosted (but it’s not well described in the Genesis doc: ; the spec that was eventually implemented is here: , I’ll add it to the pinned documents). But you’re right, my original intention was to reward any voting, pre or post boosting.

— please note that in Alchemy it is GEN that is rewarded to voters because GEN is also the Genesis DAO token (in addition to the universal predictors network token). In general though, the token that would be used for proposing fee would be the DAO token (from which voters will receive their reward). If the reward would come from the GEN management pool, then it’d be GEN after all.

— see my comments in the issue doc, it’s not 100% clear whether bot-voting is a bug or a feature.

— true, and I think that’s fine. In fact, in some versions of the protocol we even open voting only after boosting takes place.

— a) true, reputation flow (as we call it) is a small effect. Clearly it’s a configurable parameter, but for the time being it is configured to be a small effect. b) I believe it’s very important, but getting it right is also pretty challenging (in Backfeed, most of our research for 18 months was around reputation flow). c) we should separate (as I’ve done recently in the issues doc) voters reputation flow (gain/loss) and voters token reward; they are actually pretty different issues with somewhat different logics. This current issue should focus on voters token reward.

— Note that these are all configurable parameters, which will be configured and re-finetuned by the DAO over time. I think that the parameters you wrote here are the ones implemented in the last version of the Genesis DAO but I’m not 100% sure (could be checked). I believe your summary of gains and losses is correct.

  1. Yes. The logic here is to incentivize providing of information (voting “correctly” —as the DAO turns to vote retrospectively early— early on, before boosting).

  2. Yes. The logic here is to incentivize and reward for voting.

  3. Why are you incentivized to do that? You’re not incentivized to vote opposite from the DAO, but you’ll get tokens regardless.

Once again, let’s put reputation flow in another thread/issue and focus here about token reward. The logic is simple,

  • we want to incentivize and reward voting, thus reward tokens to voters regardless of their votes
  • the issue is that in that way we generate incentive to vote always, and thus bot-voting
  • the question is, is it a problem? can it be treated better?

The tension here is that if you tune reward with “vote success” in terms of what the DAO has decided you incentivize voters to vote according to what they think will happen rather than what they think should happen. This is why token reward should be detached from success. (The rep flow logic is a bit different.)

— Again, rep flow in another thread. But yes, it’s a small effect since this protocol is very preliminary and not well tuned. With the current parameters you’d need to vote 50 times(!) wrong in a row in order to lose only 40% of your reputation (0.99^50~0.6).

— This is an important point, we need to arrive to a situation were voting is returning value roughly according to (reviewing) work done. This is also related to comment post by @orishim. Right now it’s not implemented accurately, and it’s also not trivial what a good solution would look like.

— This is another good point, voting should not be disincentivized by gas cost (or rather should be incentivized enough to cover for that cost, in addition to work done).

— From the pure economic point of view that’s correct. But taking into account rep flow as well (to dig in in another thread, but taking into account that rep is gained/lost if voting was with/against the DAO), people should be more careful with voting.

This is fine. We still need to decide if there’s a good reason to incentivize pre-boosting voting.

Budget voting is a good solution against bot-voting, and is also easier to implement. It has the downside that it limits your participation capacity even if you’re a dedicated voter. Not sure if the upside is larger than the downside but it’s good to have this idea in mind. (This was our earliest thought re voting, but at some point I thought the limitation is too much of a downside; I’m happy to re-open this discussion.)

1 Like

Thanks Cory!

We’ll open a separate reputation-flow thread, but you’re right, giving more influence to those with better local knowledge is exactly the right direction.

One thing that I’m not sure about (which is implemented in the current version but I’m not sure it should be there), is about the predictors taking part in the reputation flow (both gain and loss). The idea behind it was to accelerate the reputation flow into a much larger circle, but I’m not sure it makes sense (and again, it’s a long discussion, related with the reputation bootstrap problem, so let’s have it in a separate thread).

I’m not sure I understood your example.

Thanks @orishim!

  • Let’s separate rep flow from token reward (and focus here on vote token reward).

  • The Bot-voting problem is related with token reward, not rep. Rep is / should be given only to early voters (voters who informed correctly before this information was available — this is a big research chapter).

  • But you’re right, one could bot-vote on a boosted proposal just before its ending and thus mitigate the budget voting limitation.

  • “unboosted proposals that are close to ending” doesn’t exist: unboosted proposals are by definition not close to ending, they have the boosting period ahead of them. So you cannot know about an unboosted proposal whether it’d pass or fail (you’ll only discover after its boosting period).

  • I think you have to keep token (DAO token, it happened to be GEN in Genesis DAO) reward for voters, since they actually do work. Perhaps there’s a better way to implement it (ideas?) but some sort of reward should be there to reflect value created. Whether bot-voting is a problem or not is still to be understood.

  • Rep flow between voters is a much more subtle issue, which is both very important (to increase coherence in the DAO) and challenging (to be un-manipulable, to reflect local information right).

  • Not giving GEN out for voters and the end of a proposal is an option. I’m not sure the criteria needs to be time (getting closer to ending), or convergence (getting strong signal between Yes and No), or attention (total amount of rep voted). I’m still not convinced that budget voting is necessary, or than bot-voting is a problem.

  • Internal motivation —wanting a proposal to pass or fail— is the best (quality wise) incentive, but I’m not sure it’s strong enough. Perhaps you’re right. Also in terms of actual work, I can imagine some voting procedures taking actual time and thought.

  • Rep flow wise, we definitely don’t want to reward “later voters” — which is obviously manipulable. You only want to reward Rep to voters retrospectively with the DAO, but before this information was available. How to implement this logic in a reflective (reflecting this logic) and non-manipulable (that cannot be abused) way is a big open question. We’ve had some models around this question in Backfeed, which were kind of OK, but to be honest I wasn’t super happy with any of them.

Thanks Dani!

This is roughly the direction we’ve taken in the Backfeed protocol, but making this into a concrete scheme that is not abusable and doesn’t have failure modes turns out to be challenging (although I’m still optimistic there’s an optimal solution).

Yes to the general idea of scaling along some curve. But we don’t want to implement that on voting “right” (=with the DAO) — this would create an incentive for voters to vote what they think will happen (i.e. what the DAO will think), rather than what they think should happen — which will lead to bad collective intelligence.

Indeed. The challenge there (again) is twofold: a) finding the right curve that makes sense, is not manipulable, etc. and b) implementation — any such curve design makes smart-contract implementation (potentially much) more complicated and should be treated with care. In particularly, you don’t want to need to store local data about each and every stake/vote. But generally I agree that “ordering stakers” is right, once done correctly and effectively.

Yes, but not to token reward for voting. Yes for Rep reward to voting, and token reward to staking.

That’s very true. Irrespective of budget voting I’m thinking about the feature of letting voters vote with portion of their reputation (rather than the whole thing — it makes sense once Rep flow is there, to express their level of confidence), but indeed UX is the largest barrier in there (which I think is solvable but challenging).

Ezra, you’re spot on:

we don’t want to use this mechanism for token reward for voters, which will incentivize the wrong schelling point; we want to use it for Rep gain/loss for voters (why and if it makes sense there is a long discussion, for another rep-flow thread) and token gain/loss for stakers.

Holy replies, Batman. Thanks, Matan. And thanks for the 0.1 protocol document! That’s definitely what we need, I think.

I have two questions:

  1. It sounds like we have implemented currently no GEN rewards for boosted-proposal voting. Is that right? If it is, then that doesn’t seem like it needs urgent change. (In fact, there are no rewards/punishments of any kind here, right?)

  2. Rep rewards / penalties seem quite relevant to this issue to me, since they provide a similar motivation to GEN or other token rewards. If we wouldn’t want a focal/schelling point reward system for GEN in boosted proposals, why would we want one for Rep? I see how it has a different dynamic – people who are better at voting with the majority will accumulate rep faster, leading to a more coherent DAO. But coherency isn’t actually the end goal for pretty much any DAO – the goal is coherency around some cause/mission/etc. And for that, I don’t think we want to punish people who think they have important “local knowledge” that the crowd might disagree with.

As far as bot-voting being a problem, I see different problems with it depending on the reward scheme:

If boosted-proposal voting rewards voting with the winners, bot-voting with the majority every time is the abuse strategy, and it screws up the DAO’s intelligence by over-reinforcing the majority opinion. However! If, like in budgeted voting, it only makes sense for bots/spammers to vote at the last minute, this is less of an issue. There are other problems with this reward scheme, though (see my second question above).

If boosted-proposal voting rewards all voters regardless of outcome, bot-voting randomly or always in the same direction is the abuse strategy, and it screws up the DAO’s intelligence by simply adding noise–votes that don’t represent any thought process.

It’s true that people might create more advanced bots/delegation systems that let them include their preferences in the bot-votes, but would they really do that when making a simple, noisy bot is so much easier and has little drawback? Especially if it’s easy to build up a reputation from 0 in some DAOs, you could get into DAOs where you really didn’t care about the outcomes except for your abuse.

We should keep in mind there are other defenses to spam/bots, too, e.g. identity systems to confirm real people with one account or DAO-funded bot hunters. Perhaps with such a defense in place, bot-builders would be forced to make “smarter” bots that would be aligned enough to be acceptable to the DAO. For example, I could make a bot with a whitelist that always up votes proposals from addresses on the whitelist, a group of people that I have a huge amount of trust in. That seems pretty acceptable to me, as long as the bot’s owner keeps the whitelist up to date.


Sorry in advance guys for interrupting your deep discussion with my may be quite a dumb point of view.
To my mind the best reward for voting is the right to keep voting.

Inside a Holographic Consensus model we want to (in a manner of speaking!) crossbreed a cooperative and a casino. I believe its a genius idea actually. But the outputs of both are different. So may be let us keep flies and beefsteakes separately? Namely, stakers make their money, voters make their job - vote. Obviously the only goal of predictors is to gain profit by staking. For me is similarly obvious that the main goals of reputation holders are to cooperate and to achieve DAO objectives, which are delivered only by means of voting, not by gambling.

Rep.holder votes to help to hit the targets of the project, not to receive a salary. If a rep.holder misses a voting round, his reputation should be reduced automatically. Every time a rep.holder is inactive in voting, his reputation should melt drop by drop untill totally dissapear if so happen. And no rewards for voting. Its a privilege to have a right of managing funds of a DAO and be a partner of other rep.holders. Dont like it - feel free to leave a boat. Lets take a step backward to a DAOstack whitepaper.

While working on the Holographic Consensys Visualization model (see on Discord eponymous channel) I`ve got pretty much acquainted with it:
“Each agency can assign reputation scores to its members. Reputation is a representation of one’s professional credibility, and thus influence, within the organization. As opposed to traditional blockchain-based tokens, reputation is not transferable. It is awarded to or earned by specific members, according to their merits and contributions made to the organization.”
Key takeaway? We can know for sure all the future rep.holders of a public launch and can control their “quality” beforehand not to be afraid of bots and cheaters.

To indemnify DAO from other unwanted suprises I suggest also to pay additional attention to procedure and to embed in a protocol the following features:
(1) limit the right to submit any (!) proposal one can imagine (have several strickt templates with limited amounts of funds to be spend);
(2) have a short pre-check stage for verifing compliance of a proposal;
(3) fix a mandatory discussion period about three to five days before submitting a proposal;
(4) give time for staking for and against a proposal before it gets boosted;
(5) dont let vote on proposals on which rep.holder had put a stake;
(6) make blind voting when voters do not see the current voting score untill the end of voting period.
(Im not suggesting to make blind stakes and show only current overall amount of GEN stacked cause youll say its really too much :wink: )

These features wont severely constrain DAO`s scalability. My strong believe is that DAO is not really a machinegun to shoot out a hundred ether per second just to be super rapidfire.
To summarize my opinion:
(A) voting reputation reward is not useful,
(B) budgeted voting is not nedeed,
© list of suggested changes to protocol see above.

Thanks for your patience!


(1) limit the right to submit any (!) proposal one can imagine (have several strickt templates with limited amounts of funds to be spend);
(2) have a short pre-check stage for verifing compliance of a proposal;

I really like the idea of using templates. They can give us a way to structure what goes into proposals and what we deem to be of quality. We could maybe even require timelines/roadmaps depending on the circumstance. This topic would warrant its own thread to discuss fully imo.

(3) fix a mandatory discussion period about three to five days before submitting a proposal;
(4) give time for staking for and against a proposal before it gets boosted;
(5) dont let vote on proposals on which rep.holder had put a stake;

All of these rules seem like common sense including your point to blind voting. But one thing to consider about decaying REP, is that it incentives people to vote on proposals they may know nothing about regardless if you implement rewards. I would simply write a script with a web driver to vote on proposals once a day at random just to maintain my REP.

Removing rewards uses consistency as a signal to represent credibility in your system, but voter rewards can also be used to incentive that same principle. For example, we could apply penalties to GEN you receive when a proposal you voted on successfully won. So let’s use @ezra_w’s formula and expand it: (0.5*(total_staked_for + total_staked_against)) * (your_rep/total_rep_voting) = gen_payout.

Where, voter_decay_penalty = gen_payout * ( (days_gone / 100) mod 1) (this could be tweaked to be less severe it’s just a toy). And so your actual payout could be deducted possibly by the full amount if you haven’t voted in a hundred days.

My main gripe from a philosophical point is if I’m working towards the success of the DAO and earning REP on my own merits of passing proposals etc. why should I ever lose account of that? Like if your friend from 10 years ago you use to work with needed a job he still has some reputation to you. The act of him being gone alone doesn’t diminish his previous contributions.