Reputation Decay

Colony Whitepaper:

6.2.4 Reputation Decay

All reputation decays over time. Every 600000 blocks, a user’s reputation in every domain or skill decays by a factor of 2. This decay occurs every hour, rather than being a step change every three months to ensure there are minimal incentives to earn reputation at any particular time. This frequent, network-wide update is the primary reason for the existence of the reputation mining protocol, which allows this near-continuous decay to be calculated off-chain without gas limits, and then realised on-chain. The decay serves multiple purposes. It ensures that reputation scores represent recent contributions to a colony incentivising members to continually contribute to the colony. It further ensures that wild appreciations in token value (and the corresponding decrease in tokens paid per task) do not permanently distort the distribution of reputation but instead serves to smooth out the effects of such fluctuations over time

Verifiable Decay functions:

State Channel solutions:


Of course, and I’ve been very impressed w the state channels developed by Connext. Voting in state channels might come sooner than I thought

There are also commit, reveal schemes that can be done on chain and are technically pretty simple, but create UX problems. Proxy re-encryption might be another avenue, but again there would be lots of R&D to get there.

Reputation Borrowing Model


Hey, here’s an idea. Reputation as something you borrow and must return eventually.

Embedding the pay back of the “borrowed reputation” on the same function that awards it, where each rep earned has a “half-life” or expiration dates.

Imagine that when you redeem a proposal award, earning reputation, you also starts a clock that after x amount of time/blocks anyone can go there and “redeem” again, burning/paying back part of the earned reputation back (y%).

The exact values for x and y and the reasoning for the decisions should be built by the community.

Pro-Decay Arguments:


The ability to pass a proposal today with only 10-15% of votes for because the DAO lacks attention. We thus need a way to slowly shy away reputation from “inactive” users (and from @shiv explorer we get all user data in terms of staking/voting/proposing) as the % of inactive votes becomes majoritarian.

Right now reputation is diluted naturally by adding new people but it seems that it’s not enough to compensate for the absolute increase in inattention, if we introduce a decreasing scale of reputation % awarded to new users (the 10 thousandth member not getting 1.5% rep as the first member did) the problem could be either exacerbated or remedied (depending on relative aggregate activity of old vs new users).

As we don’t know yet the direction this would take for Genesis reputation decay would be the fairest/objective/transparent way to increase the % active reputation/votes at any time in the DAO.
The alternatives to this is either letting the situation fester or directly banning people based on their inactivity which could set precedents of “reputation stripping” and ostracising/purging people (which would probably happen anyways if the fault is grave enough)


Problems: low activity in voting, especially in boosted stage. In queue you have incentives to vote (getting from stacking taxes and rep), in boosted stage you have not incentives to vote (you see 2,9% on yes, so you think it will pass no need to vote and loose taxes to network, if you think it’s bad idea, I vote no, but you know yours 1,2% will not change decision, I will wait maybe other vote, why loose taxes ). If was rep decay in boosted stage it incentivizes people to be active more (example: you didn’t vote in boosted proposals you lose 0.5% of rep points, if proposal reached 50% in voting you lose nothing)
Now you have rep points and can go vacation (for month didn’t do activity), it’s no problem, but you rep points represents some % of all pool, so it’s harder to reach 50% ( ½ not active, you need 100% consensus to reach 50%). Rep decay incentivizes you to flag yourself “I am on vacation” and don’t lose rep, but your rep points “frozen” (taken from pool) so others % rise. This gives better visibility who active and better understanding of DAO’s situation.

Decay Skepticism:


But why is low activity of that kind a problem? As long as the outcome represents what people would have voted for anyway, it doesn’t matter, right?

I would say there is a problem with voting on non-boosted proposals: you can lose reputation from voting with the losing side on a non-boosted proposal, so there’s an incentive not to vote on a non-boosted proposal already trending in one direction if you want to vote the other direction. Not sure this is a major issue, though – people should mostly only need to vote on boosted proposals if the system is working as intended.

1 Like

One of the major obstacles I find within the Reputation System of DAOStack is that it lacks the ability to onboard new members efficiently.

Reputation is required for any meaningful interaction within Alchemy, and to gain that reputation one must submit a proposal and provide a convincing foundation for establishing their identity and their intention for such membership.

While there is nothing wrong with these requirements because they ensure the security, cohesion, and sustainability of the DAO, it does however create a bottleneck of sorts for future DAO’s who wish to make themselves “accessible to exploration” and discourages on-chain participation from new members.

It’s hard to say what value is gained/lost from this process, but I do believe it is something that will need to be addressed if a DAO desires to scale.

This leads me to the following question in regards to this thread:

Is it possible to develop a system that mints reputation for new/visiting users that decay at a significantly higher rate than already established members?

1 Like

The problem with arbitrarily minting Reputation is that it opens the DAO up to various Sybil attacks.

Currently there is no way to decay Reputation (discussed earlier in this thread) – but maybe this is a scheme that should be prioritized in terms of R&D.

So there’s two means of scaling:

  • Individual member adds
  • Granting Rep to other DAOs

I think (2) is much more scalable. You’re right though to highlight the issues with (1) – we’ve already experience a few “new member traffic jams” with Genesis over its life – and I expect this to be an issue for more DAOs. However, this can be mitigated to an extent by having a separate “membership application” scheme with Genesis parameters that support higher throughput.

1 Like