SourceCred Trial Kickoff

With a large majority of participants voting in favor of trialing SourceCred to pay contributors (Signal poll), we are happy to announce the official start of the SourceCred trial! Starting today, SourceCred will be distributing DAI to community members based on their contributions to the Maker forum, including posts, replies and likes, with the intention of rewarding individuals for making valuable contributions (those which spark good discussion and receive lots of likes).

This post provides a summary of the trial, instructions for participating, a tour of the Maker SourceCred instance, and a preview of payout amounts based on last week’s activity. Further details, including how scores and payouts are calculated, can be found in Maker SourceCred Trial.

SourceCred support

I (@s_ben) will be the main point of contact for SourceCred questions. Feel free to ask any questions! Other SourceCred community members supporting the trial include @decentralion and @beanow. All SourceCred community members involved with the trial will be exempted from the trial, as will Foundation employees inside the community development department, or who otherwise have roles for which forum posts and community communication are considered ‘part of their responsibilities’

Maker SourceCred instance

An hosted instance of SourceCred running on the Maker forum can be found here.

Here, you can view users’ lifetime cred scores, as well as Topics that earned the most Cred in a given week, as shown below.

Trial Overview

The intention is to run the trial for three months, distributing at least $5k worth of DAI each month according to Cred scores. Each week (every Monday), SourceCred will publish updated scores to the forum along with payout amounts, giving community members an opportunity to ask questions and raise any concerns.

At the end of the month, contributors that opt in to receiving payments and have at least $10 in accrued payouts can redeem their balance for DAI. The balance available for redemption will be equal to the sum of weekly payouts posted to the forum.

Instructions for Participation


To receive payments, you must opt in, as not all contributors want to assume risks associated with cryptocurrency payments. To opt in, please send a direct message to @sourcecred-trial-adm indicating your desire to participate in the trial and providing an Ethereum address to send payments to. Participants in the trial will have up to one month after the end of the trial (Sept 1st) to opt in and redeem their DAI. After that time, any DAI not redeemed will be returned to the Maker Foundation.


OK, get to the payouts already!

The Maker Foundation grants program will allocate $5,000 worth of DAI for distribution in the first month, split into four weekly distributions of $1,250. If results are positive, it may increase this amount. The actual amount distributed by Maker will be less than the total monthly distribution allocated, due to payments being opt-in and other exemptions.

Trial Week 1 preview payouts (week ending May 31st)

Below are a preview for this week’s payouts for the top 20 contributors; these balances will be zero’d out and started for real next Monday. Payouts are broken into “fast” and “slow” components, whereby 20% of the DAI distributed is based on Cred earned in the last week, and 80% is distributed as a function of lifetime Cred scores. This is designed to keep the algorithm responsive, rewarding new contributions and newer contributors, while also incentivizing long-term participation.

For full scores and payout data, see this observable notebook.

If you have any questions or concerns related to the payouts or SourceCred in general, please don’t hesitate to ask!


In addition to the post detailing the trial, below are some resources that provide further information on the SourceCred algorithm:

Excited to see where this experiment goes!


There was a minor miscommunication initially regarding the date of the first payouts. Those shown above are previews based on last week. Real, redeemable payouts will start next Monday, based on the first week of June.

1 Like

Two odd questions:

So I sent off a request to add but have not seen something of an automated confirmation pm reply that the request was recieved.

The second would be a way to check if we were added. One might expect another pm reply that one has been accepted.

I was talking with @LongForWisdom on the UI to the above:

I noticed when I clicked on links (to say @LongForWisdom or whomever it would take me off the site. A lot of sites will simply create window with some name to open a new window and use that exclusively, or pop a new window every time.

I was also curious how initial conditions were determined. Meaning how do you determine something like a users influence (initial CRED value) to then use the CRED flow metrics to distribute it. At some point I am going to sit down and look at the reference materials so if I have asked something here that is in those I apologize just refer me to them again.

I am also posting here to bump this thread a bit to let people know if they are interested in getting some of the free DAI for forum participation - ya have to opt in with a wallet address for DAI to be sent to. Fortunately on subsequent reading I see this doesn’t expire until 1 month after the 3 month trial (Oct 1 I guess). So people can wait to see how much DAI they might get before opting in.

Not sure if you guys will do this or whether this is a forum feature but I was talking to LFW about sending PM’s to people who have not opted in letting them know when they hit $50, $100, $200, $500 to claim. :wink: MIght also be a good idea to pm people in the list that have > $10 DAI each week before their DAI expires on Oct 1 in September…

I am sure I will have more as I dig into this a bit. This should be an interesting experiment.

1 Like

Great questions!

Did you send the PM to @sourcecred-trial-admin? Unfortunately, due to character limits, Discourse cropped that to @sourcecred-trial-adm (no i). I’ve been just manually replying to PMs to this address letting people know they’ve been added.

Agree this is better. Have created an Issue suggesting we implement it. We’re in the midst of a big UI redesign actually, which should give us something way better in a few weeks. So not sure the team will prioritize implementing it in the current UI, but we should be fixing this soon in some form.

I can imagine plenty of ways to get out the word. PM’ing people I think would be effective. My general idea is to give it a few days first, see what traction we get just from posting here. So far we have 9 opt ins (including you when I get your ETH address), which is a decent start IMO. I also think we’ll see more interest as those DAI balances grow :money_with_wings: I generally defer to @LongForWisdom’s wisdom (badum bum) on promotion, but open to any ideas.

1 Like

Interesting I just clicked on the @sourcecred-trial-adm and then finally looked at the message it formulated “For MakerMan” so no I guess I didn’t send a message to the correct user. This might be a forum thing? I have not used private messages here much and thought just clicking on a user would automatically create a private message to a particular user.

I was just looking at the 25 minute video to learn up on SourceCred just because I have had an interest in the topic of ‘trust’ as well ‘content value determination’ for a while now.

Thank you for the reply. Yeah LFW was telling me that the UI was under serious rework. I only posted just because it was on my mind and I like to do multiple things at once. bumping this thread seems important now this is kicking off.

Making an easy link for people to click on that constructs the pm would be even more helpful. This is for a forum admin I think. Either that or instructions if some are required. I am going to double check a few things and then get back here to edit this with some more info.

EDIT ADD: I just checked and clicking on the above looks like the forum picked another user here the first time. I generally have not used pm’s much so never really looked at who it was sending to. I did just check again by doing the same thing a second time (clicking on nickname above) to send another request to @sourcecred-trial-adm I actually tried to manually type in the correct user and the pm page simply would not allow me to do it. I did verify it went to the -adm

Regarding promotions I suggested to LFW that we just put it on CC agenda for a bit to just remind people the trial is on and it is an opt-in then just promo a link to this thread or something. Like I said a easy link to opt in with a properly constructed message only needing a ETH address might help. Clearly 8 other people figured it out. I always seem to have the wierd stuff happen.

I am excited to see the new frontend UI and am sure I will have some decent feed back once the new one kicks out for comments. Feel free to ping me once your team has something ready for release but want alpha/beta feed back before the final release. I can’t say I will have time, but if I do, and have inclination, I will.

A follow up post to previous.

The talk was a good intro. The following paper linked above also a pretty nice reading intro pretty much answered my question regarding how the node cred is initialized and then calculated. Not quite enough detail but i don’t expect that out of an introductory paper.

Do you have a link to a more advanced paper that shows in detail the math being used? I’m a bit curious how you guys handled the epoch’s. I guess it is similar to doing something like a blockchain state save rather than having to back calculate everything to determine the state at some point. There is a lot here that is interesting but I find the concept of managing past cred states (and ofc grain payouts etc.) against current cred with the condition that cred or grain doesn’t decrease is interesting. How is grain used against cred to maintain this condition and what kinds of deficits are managed. Also given that you are using something like a matrix formulation with eigenvalues to manage the cred you just renomalize the cred sum to be what you need for the cred growth you want? It is not entirely clear to me the connection between cred and grain from this article.

Even so I think the approach is interesting and definitely useful. I found one comment in the video talk to be interesting and that is that if left alone the cred signal will be entirely gamed vs. ones where a more dynamic approach via management of the cred edge profile (can’t remember the term you guys used for the cred configuration) by the community of interest. I think this means that cred is a kind of decaying value component that has to be offset in some way by direct community management so it is isn’t something you just get and keep even though a comment was that cred wasn’t meant to decay like this. (a contributor that makes a contribution that was not utilized for some time could still get cred later).

One thing in my thoughts on this topic that comes up is the idea of relative age of contributions or their relevance. There is two ways to deal with this that I think generally work:

  1. Have cred have a decay rate - using the epoch slowly decay cred.
  2. Have contributors themselves put a cap on the amount of cred or grain they require before a contribution is considered ‘paid’. This is a nice mechanism for contributions to formally enter the community with a previous value that disassociates from future value creation.

Conceptually while people would desire to make money off of contributions in perpetuity practically this doesn’t work well. examples are patents where at some point it is more beneficial to society for these patents to enter the ‘public domain’ vs. to keep someone paying a royalty etc to use them. Timeframes on these things are important in relation to revenue generation against potential use and litigation processes. One has to have potential to create enough compensation for the creation of something during the time frame the contribution is active for revenue generation.

Using 1 to create a decay curve gives a longer time frame for something to generate revenue (even if small). Using (2) above formalizes the completion of the compensation and transition into the public domain with a better time frame than (1). Literally a single benefactor could then pay the contributor the amount in (2) which then would allow the contribution to enter the public domain.

I am not sure if the decay or set value idea would help within sourceCred or even needed but these were things that came out of my research on this topic generally.

I found it quite interesting the use of a common 80:20 division approach to the slow:fast cred modelling. I like it as a simple easy to calculate approach that also probably could be arrived at by a cred decay model.

Anyway those are my thoughts. If there is a more mathematically rigorous paper on the SourceCred model please do post for those of us who are interested and have a solid math background. Ultimately I could look at the source code and ferret out the math but find it easier to look at the math generally vs. looking at code to figure out the math.


I didn’t find me on the list, it seems that I still need to work hard.

Hey @hongbiao_li, you’re on the list! It’s just a bit hard to find at the moment. If you go to the observable notebook where payouts data is hosted, it’s only currently displaying the “top contributors”, defined as those who have at least 1% of weekly or lifetime cred. But if you click on the distributionHistory.json link (admittedly hard to find), you can see your score:

                "alias": "discourse/@hongbiao_li",
                "fast": 118,
                "slow": 2

Keep in mind these raw numbers are not denominated in dollars, but cents. So your total of 118+2 = 120 = $1.20 worth of DAI.

So, you will need to work a bit more to get to the minimum $10 in accrued DAI you need to do a redemption.

Next week we will make it easier for anyone with a score to find it!


Great questions @MakerMan. It’s nice to have community members that can understand some of this stuff on deeper levels. My knowledge of the algorithm is more high-level, but hopefully I can point you in the right direction.

No more advanced paper yet, in part because we’re undergoing a rewrite of the algorithm, called CredRank. The basic functionality and scores will be the same, but it will allow us to improve performance (faster calculation and smaller output), better interpretability (i.e. we can answer more questions of the types you propose) and flexibility (i.e. we can create features that enable more cryptoeconomic models). You can find more about CredRank here,

How epochs work is beyond me… Will ask the algo designers for input.

As for state changes, we currently do just re-download all the data and recalculate the graph from scratch each time we generate new scores (state). The algorithm is fairly computationally intensive, so not something you could calculate on the Ethereum blockchain for instance (not 1.x anyway). One nice property of the Page Rank algorithm however, is that while it is expensive to calculate, it’s very cheap to validate. And, CredRank will when merged significantly decrease runtime and output size.

SourceCred does plan to launch Grain as an ERC-20 token, and is working on a Grain ledger that does a better job of automating accounting that is currently done in a more manual, messy way.

As for Cred and Grain, I would think of them as separate things (for now anyway). When we implement Boosting, Cred and Grain will interact and affect each other. But for now, in SourceCred and the Maker trial, Grain (or DAI in Maker’s case) is just distributed weekly based on Cred scores. You can think of Grain as immutable, which it will literally be once DAI payments go out on-chain, while Cred scores can change based on new data, re-evaluation of old data, and changes to the algorithm. How Cred and Grain interact depends on the cryptoeconomic model the project uses, and the design space there is large and relatively unexplored in practice. We have some really smart people exploring the theoretical possibilities though, for SourceCred and more generally. SourceCred has a #cryptoeconomics channel on our Discord you might find interesting. We’re also interacting with the Token Engineering (TE) community (Discord), as well as with other researchers in the cryptoeconomics and governance realms.

Back to the core algorithm, below is a “paper” that explores how PageRank is applied. This will help you understand, for instance, the alpha parameter, one of the main “knobs” you can use to steer the behavior of SourceCred.

This paper goes into some of the social science and game theory involved,

And here is a quite out of date, but thorough and perhaps useful description of the SourceCred algorithm.

This is another deep area of thought. There are many different “employment”/economic models one could implement here. SourceCred is exploring a Sponsorship model, where a sponsor (e.g. Protocol Labs) agrees to pay a set dollar amount per month, in return for a share of the contributor’s Cred, de-risking their income. Other models are being discussed. Which one is appropriate for a given project will likely depend on the needs and culture of the project. I agree that balancing rewards over time (temporal dynamcis), is one of the more important, trickier aspects.