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.
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.
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.
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.
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.
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.