SourceCred Onchain Technical Design

Bringing SourceCred Onchain

This post is intended to provide deeper detail on the “SourceCred Feature Development” mentioned in GovAlpha’s Q3 Budget Request. I will be quoting heavily from the Technical Design Proposal we requested from @s_ben and @topocount of SourceCred.

Executive Summary

We plan to spend an additional 36,000 DAI (as detailed in our budget) to implement SourceCred distributions and cred calculations completely onchain. Currently, only the payments themselves are verifiable onchain, and require manual distribution.

In addition to simplifying the weekly distribution process, this will also make distributions “trustless” by removing the human labor of running the scores and distributing funds.

It is our goal that this will be finished at the end of the Q3 (start of October). @topocount (Kevin) from SourceCred is the lead dev on this project, with support from @s_ben. GovAlpha will be playing the role of project manager.


We expect these benefits from implementation in addition to those listed above:

  • This design will provide greater transparency over the SourceCred system, providing greater trust in the Cred scores.
  • This “first step” increases the likelihood that SourceCred parameters could be controlled by executive votes in the future.
  • Greater resiliency will be provided to the SourceCred distribution process.

What is changing?

Under the current system, someone from the SourceCred team (usually @s_ben) has to run the SourceCred algorithm locally and then submit a Pull Request to Github to update the distribution amounts every week. Funds are then sent out according to the monthly totals by SourceCred’s treasury, funded by DAI monthly from the GovAlpha Multi-Sig. There are many dependencies here and in general the system represents a lot of labor that could be automated.

To help understand what is changing here’s a quote from the technical design proposal:

SourceCred will develop new components that enables a third party (i.e. a “Cred oracle”) to publish signed, verifiable data to a Maker oracle feed… Funds will be distributed via a smart contract implementing a merkle distribution, allowing contributors to claim their DAI balance at any time. A time delay will be implemented between the calculation of distribution amounts and on-chain distribution of funds. This will allow on-chain distributions to be challenged/blocked in the event Cred oracles cannot reach consensus, indicating system failures or malicious behavior.

This implementation represents a few major changes to how we currently incentivize forum participation. Most notably, funds will no longer be distributed once a month, but rather claimable anytime by the forum participant.

As mentioned by the proposal, this necessitates a time delay, similar to the GSM Pause Delay used on Executive Votes in the Maker Protocol. While this is a potential attack vector to the funds allocated to SourceCred, we believe this system is preferable to the current state of affairs. This risk could be compared with the current custody risk of the DAI sent to SourceCred and the trust placed in the person running the algorithm.

What needs to be done?

First, @topocount will need to design an entirely new plugin to interface with the SourceCred algorithm.

Again borrowing a concise explanation from the technical design proposal:

The new plugin model will have distinct components, the Fetcher, DataProvider and DataArchive.

  • Fetcher: This component will periodically fetch a snapshot of Discourse’s data, which the DataProvider then stores in the DataArchive.
  • DataProvider: This component will convert API responses into structured data for storage, and store successful responses persistently to a DataArchive. It will also provide a read-only interface for the structured data needed to calculate Cred scores.
  • DataArchive: This component is a platform or package in which mirrored data is stored.

While a little complex, the problem at this stage is pretty simple, the system needs a way to grab and store data that isn’t a person running the SourceCred algorithm locally. The accompanying diagram from the proposal helps illustrate the technical complexity of the solution:

To help understand what’s happening linearly,
@s_ben added this visual explanation:

This plugin and database system to preserve the information represent the bulk of the work needed in this proposal.

Originally, the final step of distributions was going to be completed with the Keg, but with the Protocol Engineering team favoring DssVest, we will likely be completing the distributions with DssVest instead.

As we get closer to the completion of this project a decision will need to be made if we make this distribution available on Layer 2 or Mainnet. Since the end-user will be paying the gas fees to claim their SourceCred distribution, this decision does carry some weight. That cost must be balanced with the additional knowledge required to claim funds on an L2 and move them to Mainnet. Luckily from a technical perspective, there is little difference for implementation.

Timeline and Deliverables

It is expected that this project will take the full quarter to achieve. Deliverables have been broken down into three sections, each taking approximately one month to complete (again, from the proposal):

The components laid out in the Implementation section can be grouped into three main deliverables:

  • Trusted Fetcher : Implement a Discourse version of the Fetcher and scripts to periodically fetch snapshots of the Maker forum, sign, and publish snapshots to customized DataArchive (decentralized storage) and DataProvider interface.
  • Updated Discourse Plugin: update existing plugin to fetch snapshotted data, generate Cred scores and DAI distributions, and enable persistent verifiability of DAI distributions.
  • Timelocked Merkle Distribution: Implement smart contract that implements merkle distribution that allows community members to claim DAI distributed from the Maker protocol. Implement timelock to add ability to “freeze” questionable distributions.

GovAlpha will take the project management role for this project, with a focus on keeping the community updated on the progress and any deviations from what has been laid out in this post.

Why focus on this?

SourceCred was designed to be rather simple for any administer of a protocol to run the figures and distribute funds. While this open-source approach is super effective for bringing the technology to many different groups, it adds administrative work that does not scale well with a project of Maker’s size.

To cope with this, Maker has been leaning on SourceCred for implementation. Although there have not been any major issues with this set up, there is a severe continuity risk. On both the Maker and SourceCred sides of the equation, the departure of a key figure could lead to a pause or even complete stoppage of the SourceCred incentive for Maker forum participants. I believe that the only way to truly stamp out this risk is to get the entire project onchain and governed by Maker.

While this project does represent a decent chunk of the GovAlpha budget, it is relatively small compared to the amount we are already spending on SourceCred. It is my view that SourceCred is a vital tool in recruiting talent and participation on the Maker Forum, so making that incentive structure more resilient is DAI well spent.


This is neat–automation, love it–thank you @GovAlpha-Core-Unit , thank you @s_ben and thank you to the rest of the SourceCred Team.

Personally I would prefer to keep in on Mainnet (L1). Not sure if oDAI (optimism DAI) to DAI might incur a “reportable” tax event–one asset to another. Also, how would that work on optimism since oDAI needs to get burn when crossing the bridge back over to Mainnet.

BTW I believe the DAI bridge won’t be ready until Q4. Assuming it is not ready–initially we will all go thru the seven (7) day delay experience. Hence, why IMO we should keep it on the most secure chain, Ethereum L1.

@prose11 can you please make the second visual a little larger? :slight_smile:


Yeah sorry about that can’t seem to blow it up while keeping readable, have reached out to @s_ben to see if there’s a larger one at the Source! Otherwise will draw up a cheap imitation tomorrow.

Thanks for laying in on the L2 debate, I think in general I would like to keep it on Mainnet as well, perhaps we can just increase the distribution a few percent to help combat the gas fees.


I’m not an accountant, but I’m pretty sure the receipt of the Dai is the taxable event regardless of which layer it’s on.

If the l2 is trustless (e.g optimism) it’s probably a good long term strategy to deploy on there. It’s also great dogfooding for the Maker optimism bridge.


It was released a few hours ago (optimism for Uniswap) and it looks like the Alpha version is a bit centralized. For now, and understandable:

@ElProgreso, here’s high res version.

1 Like

Send it! I especially look forward to MakerDAO getting on Optimism and using the DAI bridge for L1 instant withdrawals basically cross selling L2 and DAI.

1 Like

Excellent approach guys, to continue growing, it seems to me that the gas issue is fair, so you save a lot on that. I prefer to keep the withdrawals in L1. :eyes:

:partying_face: Decentralize @s_ben !!!

Super stoked about the onchain present to future happenings being discussed here.