Cred Weighted Voting

Implement Cred Weighted Prioritization

Status: proposal


Initiative Description:

As discussed here, we’d like to use cred-weighted voting to prioritize SourceCred initiatives. We can then give the prioritized initiatives a nice cred bounty.

As a practical matter, I propose that we use cred-weighted, dependency-aware conviction voting.


Voting power will be based not on number of votes, but based on the amount of cred behind each vote. We can experiment with different flavors of cred weighting. For example:

  • Raw cred weighting: We weight every vote based on the cred of the voter. This will give enormous power to two individuals who have ~70% of the cred, and disenfranchise most people who have very little cred. We could add some constant to each voter so that everyone still has some voice.
  • Square root cred weighting: We weight every vote based on the square root of the user’s cred, plus some constant. This will likely shift voting to be more democratic, but still give top contributors a significant voice.
  • Logarithmic voting: We weight each vote based on the logarithm of the user’s cred. This would greatly reduce the relative power of the highest-cred contributors.

We could also do other things like having the cred weighting take into account “cred freshness”, so recently earned cred has more voting power than stale cred.

Also, users will be able to split their voting power between multiple initiatives.

Dependency Aware

When voting for an initiative that has unresolved dependencies, a large chunk of the voting power should flow through to the unresolved deps. This way our process produces viable prioritizations.

One approach could be to simply re-use our PageRank logic here, modeling dependency edges between the initiatives. The seed vector would be the raw cred-weighted voting output, alpha would be reasonably high (say 0.2). The result is that dependencies of important initiatives(s) would get prioritized first.

Conviction Voting

The idea behind conviction voting is basically that votes grow more powerful the longer the underlying preference has been expressed for. So if I have been saying “we should do X” for 8 weeks, that’s a much stronger than if I’ve been saying it for 2 days.

You can read about the Commons Stack proposal here: Conviction Voting. One twist is that while I want the votes to get more powerful over time (positive first derivative), I want the rate at which the vote gains power to get lower over time (negative second derivative), until the vote is “refreshed”.

Basically: if someone votes for something in 2019, and then disappears, it shouldn’t be the case in 2021 that their vote is now the most powerful in the system. After a certain period (maybe a few months) the vote loses its power until the author comes around and re-votes for it. Someone who is paying attention could re-vote every week and keep the power strong, but I want there to be some degree of conscious attention needed.

Voting Frontend

We will need a system for recording votes. Since the initiatives are presently reified as Discourse topics, we should do the voting through Discourse too. However, the builtin Discourse poll option is insufficiently flexible for our needs. Instead, we can make a new category (CredSperiment/prioritization) and have individual posts correspond to votes for initiatives. (A post could include votes for multiple initiatives, weighting of the different initiatives, and even explanation of why the voter made the choices they did.)


Implementing cred-weighted prioritization will give the SourceCred community the ability to guide its own development and priorities using its internal ruleset. This will make SourceCred much more “autonomous” (in the sense that DAOs are autonomous).

Implementation plan:

For ease of iteration, let’s do the cred-weighted prioritization inside observable notebooks. We’ll need to do the following:

  • Decide on initial formula for cred-weighted voting
  • Export initiatives from Discourse (need new APIs)
  • Export votes from Discourse (need new APIs)
  • Export PageRank code from sourcecred/sourcecred so we can use it for dependency weighting
  • Implement formula for conviction voting
  • Wrap it all together in a notebook
  • Document + demo how to vote on initiatives

Estimated Work (hours):

This is a substantial initiative. I expect that (in addition to dependencies) it will take at least 10-30 hours of work.



None yet


@decentralion expressed renewed interest to start using Cred weighted voting in the forum. @burrrata then researched Discourse Polls and created the first poll on SourceCred’s Discourse. Then the community discussed and @burrrata discovered how to create a public poll. @Beanow confirmed that public polls can be retrieved via the Discourse API.

1 Like

Is the intention here to create a Quadratic Voting mechanism?

Quadratic voting is a different thing. I’d be open to using it though.

@blueridger Does weighted voting have some correlation to the /tally bot you have designed?