Funding SourceCred from Maker Protocol

1

In a little over a week (Nov 2nd-4th), the Maker-SourceCred working group will submit a formal proposal to integrate SourceCred directly with the Maker protocol. This is very exciting! If accepted by MKR holders, this will be SourceCred’s first integration with a protocol running on a blockchain. Maker Governance Facilitotor @LongForWisdom has put together a technical subproposal, MIP13c3-SP6: SourceCred Funding, which provides a high-level overview of the integration for MKR holders. From my own understanding and initial conversations, the requirements in the proposal are within our capabilities. However, to be sure I wanted to reach out to the wider community for feedback. This also presents a nice opportunity to start fleshing out design ideas, as this may help uncover potential issues and prepare us for tough questions by Maker stakeholders during the governance process. Below, I try to provide as much background and context as possible, and also toss out some initial ideas with the hope of spurring better ones :sweat_smile:

Background

Maker has been trialing paying contributors on its forum according to Cred scores for ~5 months. As detailed in the final report on the initial phase of the trial, the Maker-SourceCred working group and contributors are generally happy with SourceCred, and want to pursue a technical integration whereby contributors are paid directly from the protocol. This will help further MakerDAO’s goals around fully decentralizing and eventually dissolving the Maker Foundation (which is currently funding our work via a development grant).

Governance Process

Our technical subproposal, MIP13c3-SP6: SourceCred Funding is a Declaration of Intent. If passed, it will signal that MKR holders are on board with building a technical integration. The current trial will then be extended for 6 months, during which time we will build the technical integration. Once the integration is complete, MKR holders will hold another vote on whether to turn the integration on.

The Declaration of Intent will pass through Maker’s November monthly governance cycle. Below is a rough timeline of that process.

  • Nov 5th (Thurs) @Gov-Facillitators review formally submitted MIPS, determine if MIP13c3-SP6: (SourceCred Funding) will be put forth in Inclusion Polls.

  • Nov 9th - 12th (Mon - Thurs), Inclusion Poll (poll to determine if MIP13c3-SP6 is included in the Monthly MIP Governance Poll)

  • Nov 12th (Thurs) - During weekly Governance and Risk Call, @Gov-Facillitators perform Inclusion Poll Review and determine if MIP13c3-SP6 is eligible for Monthly MIP Governance Poll

  • Nov 16th - 19th (Mon-Thurs) MIPs Governance Poll

  • Nov 19th (Thurs) During weekly Governance and Risk Call, @Gov-Facillitators perform Governance Poll Review.

  • Nov 23 - 27th (Mon) Executive vote

Maker Governance Context

Any workable technical integration should be aware of a number of technical, governance and political issues Maker governance is currently grappling with.

Decentralized Funding

One of the biggest open questions the DAO faces is how to fund decentralized teams in general. The closest thing to SourceCred’s MIP is probably MIP14: Protocol DAI Transfer. This MIP seeks to define a generic process whereby MKR holders could authorize DAI transfers to any party. Theoretically, this could have been used to pay people using SourceCred, at least as a first step towards a tighter integration. However, back in June, an on-chain poll was conducted to include MIP14 in the June monthly governance vote, and MKR holders voted it down by a large margin. An informal poll was taken to gauge what issues MKR holders had with MIP14. While this poll was largely speculation on the part of regular contributors, as MKR holders vote anonymously, a number of potential issues were raised, including:

Image of a Discourse poll on the Maker forum, including four items (multi-choice; totals sum to more than 100%): 50% of voters (8 people) were worried about MKR dilution via the potential to cause flops; 43% of voters (7 people) only wanted to use system surplus for DAI transfer; 43% of voters (7 people) wanted to see a fund management structure in place before approving MIP14 (eg adding core personal such as a treasure or accounts domain team); 43% of voters (7 people) were worried about sending DAI to an external address not controlled by Maker Governance (would prefer to have funds move from the protocol to a governance-controlled address (eg cash account) before final dispersal).
Image of a Discourse poll on the Maker forum, including four items (multi-choice; totals sum to more than 100%): 50% of voters (8 people) were worried about MKR dilution via the potential to cause flops; 43% of voters (7 people) only wanted to use system surplus for DAI transfer; 43% of voters (7 people) wanted to see a fund management structure in place before approving MIP14 (eg adding core personal such as a treasure or accounts domain team); 43% of voters (7 people) were worried about sending DAI to an external address not controlled by Maker Governance (would prefer to have funds move from the protocol to a governance-controlled address (eg cash account) before final dispersal).1080×946 168 KB

While SourceCred may not need to solve all of these problems, these problems likely need to be solved for a successful SourceCred integration to happen. Namely, we need to figure out how to get DAI in a reliable, orderly way from the surplus buffer (currently holds up to 2M DAI, though may soon be increased to 4M), and how to manage and distribute the received DAI in a trust minimized way.

A related declaration of intent currently working its way through Maker governance is MIP13c3-SP3: Declaration of Intent - Strategic reserves fund (SRF). If passed, this MIP would create a strategic reserve fund, which aims to create a decentralized treasury. This could potentially feed into a SourceCred integration.

By being narrower in scope than MIP14 or the Strategic Reserves Fund (SRF) MIP, SourceCred may hopefully not have to face all of these issues. It could also just be a good opportunity to move the conversation forward for Maker generally, by figuring out more about MKR holders’ desires and reservations.

Requirements of technical integration

From MIP13c3-SP6: SourceCred Funding:

This funding should:

  • Come from the Maker Protocol using funds from the surplus buffer or generated through MKR minting.
  • Be distributed according to cred scores generated using weightings ratified by Maker Governance.

The technical implementation of this funding system is flexible, but should:

  • Allow variable amounts of value in the form of DAI to be drawn from the Maker Protocol for distribution.
  • Follow best practices and be audited by one or more Smart Contracts Domain Team personnel.
  • Be presented to Maker Governance in the form of a technical MIP.

The technical implementation of the distribution system is flexible, but should:

  • Allow for variable amounts of any token to be distributed according to cred scores.
  • Ensure that off-chain cred scores are communicated for on-chain distribution in a trust-minimized way.
  • Follow best practices and be audited by one or more Smart Contracts Domain Team personnel.
  • Be presented to Maker Governance in the form of a technical MIP.

In addition, the following point should be addressed:

  • Off-chain cred scores should be calculated in a reliable and trust-minimized way.

Initial Ideas

Below are some initial ideas. My hope is that this can at least expose some potential risk and issues so we can make sure we don’t paint ourselves into a corner with the requirements in the MIP.

Transmitting scores in a trust minimized way is somewhat challenging. The SourceCred algorithm is too computationally intensive to run on a blockchain (certainly on Ethereum 1.0). Further, the algorithm is still evolving rather quickly. It has not yet “ossified”. This makes it difficult for a third party oracle to serve reliable scores. One potential solution would be to build a web API that an oracle service (e.g. Chainlink) could call to serve data from. Another, perhaps more practical in the near-term solution, would be for SourceCred to simply continue providing the scores, and having a third party validate them. The potential for SourceCred to abuse this trust could be minimized in other parts of the solution. I imagine the minimum information a smart contract would need is just what is necessary to calculate the DAI payouts (or just the payout amounts themselves), and how much (if any) DAI needs to be taken from the surplus buffer.

To avoid Flop auctions (minting MKR and selling for DAI if the surplus buffer is empty, which MKR holders seem adverse to), I imagine a “rainty day fun” address could be created. This address could hold enough for perhaps a few months worth of distributions. This would provide enough DAI to continue paying contributors even if the protocol faces a long DAI shortage, as it did after Black Thursday. This would also provide on-chain guarantees to contributors that there was at least X months of payouts coming. This fund could be topped up periodically from the surplus buffer if there was available DAI. Should MKR holders decide to end the program, this would act to soften the blow, acting as a kind of ‘severence package’. It could also keep payments going if MKR holders were simply too busy with other governance issues to approve payouts, or did not reach quorum for some reason. This fund could potentially be controlled via a multi-sig scheme, keeping any one party from being able to unilaterally drain the fund or hold up payments. For instance, we could implement a 2-of-3 multi-sig between SoruceCred (or 3rd party oracle), the Foundation, and MKR holders. This would allow SourceCred (or oracle) to continue distributing payouts even if MKR holders missed a vote to approve funds because it was too busy with other issues or did not reach quorum. It would also allow the Foundation and MKR holders to stop payments should they decide to end the engagement, or if SourceCred (or oracle) went rouge.

As for generating ‘weights ratified by Maker governance’, I think what we need is a minimum number of variables that Maker governance can use to ‘steer’ the instance in response to feedback and changing conditions. This minimization strategy is essentially what Maker pioneered with its own governance, and should be understandable to MKR holders. On the algorithm side, this would presumably be the alpha parameter and node and edge weights (i.e. what’s in the config file). To determine payout amounts, presumably we’d need the total amount distributed (e.g. for a given month), % of lifetime Cred vs immediate Cred (last week) Cred (a good proxy for ‘old guard’ vs new contributor cohorts), and a whitelist of ETH addresses for recipients. One can imagine other parameters being introduced for more fine-grained control, but for now, these seem to be the basics. Additionally, if Maker was more concerned about stability and credible neutrality than new features, we could limit scope (e.g. just stay on Discourse) and upgrades, at least for the initial integration. I think that for these parameters to make sense to MKR holders, we’ll probably need to continue conveying info about how the integration is going. This could be though the dashboard, continued reports, or other comms as needed. This would give MKR holders confidence in voting on monthly distributions without having to do intensive audis of every distribution. In time, this could be phased out if the algorithm proves stable, credibly neutral and highly trusted.

Phew! If you’ve made it this far, thanks for reading! If you see any potential issues, please let us know so we can investigate and update the MIP before Nov 4th.

4 Likes
2

Transmitting scores in a trust minimized way is somewhat challenging. The SourceCred algorithm is too computationally intensive to run on a blockchain (certainly on Ethereum 1.0).

True!

Further, the algorithm is still evolving rather quickly. It has not yet “ossified”.

It never will!

This makes it difficult for a third party oracle to serve reliable scores.

Perhaps—is there a reason that it’s insufficient to pin to a fixed version of SourceCred until upgraded by governance consensus? Given that you’re running sourcecred==0.7.1, the algorithm is stable/ossified.

The “current state of the algorithm” is just one big important weight.

Or do I misunderstand the problem?

2 Likes
3

Nope, I think pinning a version is a good idea. It would simplify a lot, and I think that the algorithm has been performing well enough for a long enough period of time that not upgrading for a while would be acceptable. The version could just be one of the high-level variables governance approves.

4

Wow @s_ben great job this is super exciting! Ya MIP14 scared me too basically for those reasons… I still think the most elegant way to get dai out of the surplus buffer is to take a fixed amount or fixed percent upon trigger of flap auction and send to SC “rainy day fund” as you described it. I describe a similar mechanism, calling it a “reservoir” in my Grainmaker P1 post which covers some of the other issues you may run into with such a system. To be clear, transferring a fixed amount upon flap will make for irregular payment intervals, but this would be: 1) easier to pass with MKR holders I think, 2) reflect actual profitability of the protocol make it more sustainable and aligning incentives, 3) be smoothed out into regular monthly payments by the rainy day / reservoir buffer system. Cheers :wink:

2 Likes
5

@wchargin, this just caused another issue to pop into mind. If we fix the version, that makes it easier to calculate scores. However, what about the data? If an oracle (e.g. Chainlink oracle) recalculated scores, then 10 minutes later Maker, or another oracle (who is verifying other oracle’s output) recalculates scores, those scores could be different, no? All you’d need is one like on a Discourse post to happen in between. Would it be difficult to time-filter the graph? Is this really an issue? Do the scores need to be exactly the same, or just within some bound?

1 Like
6

Yes, certainly.

Time-filtering the graph isn’t sufficient in general. If someone unlikes a post in the target interval, or deletes a post, or a previously hidden entity in the target interval is made public—then, too, will the graph and outputs change.

You have to save some intermediate outputs. If you have the plugin graphs (or the merged graph), then computing the scores is deterministic, so it suffices to retain the graphs. If you have the plugin cache directories, and the plugin code can load from cache without relying on external data*, then it would also suffice to retain the cache.

Now, of course, if you have the input graphs/caches and can see that they map to the output scores, you also have to trust that the input graphs/caches are correct. But at least this is refutable: you can point to missing/extraneous nodes in the graph to expose a discrepancy. And it’s kind of unavoidable: since we depend on the state of external systems at particular points in times, you need to record that state and trust the chain of custody.

* This is a desirable property found in some systems as a distinction between “fetch” and “build” phases. In SourceCred, the GitHub plugin almost has this property (all the main data is loaded, but the plugin makes one GitHub query to resolve the repository IDs; if desired, we could cache this, too). My understanding is that the Discourse plugin does not have this property because its likes have poor cache properties, but I’m not certain; I don’t know about the Discord plugin.

In my opinion, verifiability is an important goal, because it improves our ability to trust the integrity of the data. We’re talking about a hybrid centralized–decentralized system; I support any checks that we can place on the centralized system to keep it honest.

By persisting the graphs (and optionally also caches), we can ensure that the scores are exactly the same, and we should do so. Plus, we want to store the graphs, anyway, since that’s needed to explore the distribution and get any more info than “yep, your score is this arbitrary number”.

2 Likes
7

It looks like the current graph.json for the Maker instance is 24.8 Mb, which isn’t too big. This could make decentralized storage easier…It looks like that is only ~1Mb larger than the cache file as well, so both are presumably roughly equally useful. We could also create a hash of the file, which would only be a few bytes, potentially storable on the blockchain. This can only be used to validate that data is exactly correct, but that could be useful, for instance if we’re backing up data on IPFS/filecoin.

This also raises an interesting larger issue of immutability. Currently, with the scores updated every time the algorithm is run, history can be rewritten in meaningful ways. This has some nice properties, and some worrying ones. If we occasionally save intermediate outputs (or hashes of outputs) to a blockchain, you essentially create an immutable “Credchain”.

This is where time delays might be a problem (concurrency in CS terms?). Let’s say we have 3 different oracles, all sending scores to a Maker smart contract. We can’t just send those oracles the graph or cache, because then Maker has to trust us to send the correct data. We might as well just send the scores directly. So presumably, to be maximally decentralized, the oracles would need to pull data from Discourse themselves (presumably using the same version of SoruceCred) or some 3rd party source (e.g. Ocean data provider?), calculate the scores, and transmit those to the Maker smart contract. But what if (and this could happen in a busy forum), a like is created after oracle #1 has pulled the data, but before oracle #2 has pulled the data. The change in scores is likely negligible (unless it’s a @wchargin super like :sweat_smile:). But can the smart contract trust both oracles?

I assume this means you agree non-exact matches are OK? That feels right to me…This would allow us to do something similar to what Maker oracles are already doing with price data. The smart contract just takes the median of prices reported by a number of trusted oracles. This means hacked/compromised oracles can’t move the price too far, as it’s a statistical outlier. It also allows for some variability in pricing data, which is unavoidable due to latency issues, different soruces of price info, different models for estimating prices from order books, etc. Actually, if we just treated each user’s Cred score and DAI balance like a price feed, we may be able to reuse a lot of the existing oracle work.

1 Like
8

@DeltaFreq, I’d totally forgoten about your Grainmaker P1 post, but remember it now. Your “grainy day fun” (wah wah) totally could have been the inspiration of my idea for a rainy day fund! If we end up going with this idea, we should at minimum link to it (as I have above). If it becomes valuable enough in the future, may this paragraph be entered into evidence :woman_judge:

It’s also good to have someone from the Maker community with context on these issues provide feedback. Your ideas around managing a rainy day fund I think are sound. As @decentralion was commenting in the Grainmaker P1 post, it may not be appropriate for many communities using SourceCred, as it has certain assumptions that may not be valid for all (e.g. no fractional reserve, non-floating price, etc.). However, it may map well onto the Maker use case. I wonder if the formulas you suggest are a little complex here though? Unlike a generalized SC org (or scorg as you call them), which has variable revenue and expenses, contributors paid via SourceCred are going to have a bit more predictability (hopefully). Instead of variable revenue that needs to be modeled with say, a gaussian distribution, it’s just pulling from the stability fee buffer. There may be volatility due to shortages, but presumably there won’t be the problem of what to do with excess input and the buffer overflowing…this raises the issue for me of what logic should be embedded into a smart contract, and what should be calculated in the oracle. My hunch is that if we can keep the logic simple enough, just keeping it all in the smart contract might have some nice properties (e.g. more trustless). But just starting to wrap my head around that…

I was imagining the contract just calling the suck() function and pulling DAi from the surplus buffer when there was a need and the buffer wasn’t too low. The logic is simple, and if you didn’t suck ‘too hard’ at any one time, you wouldn’t endanger the buffer. However, perhaps flap auctions would be better. Are those called often enough to be depended on? Would it require a larger rainy day fund?

9

@s_ben Cool! I agree that if we implement smart contract logic which only pulls DAI from maker protocol when:

  1. There is more than X DAI in Maker’s surplus buffer, and
  2. There is less than Y DAI in grainy day fund

then we won’t have to deal with overflow in the rainy day fund. This may be fine, but I will point out some potential issues. The main one is that by extracting surplus DAI according to our own smart contract logic, we will be adding complexity to the redemption dynamics of MKR, thus impacting it’s value in a way that not only reduces it, but is also harder to predict and understand. What I mean by this is that MKR’s value comes from 1) voting power in governance and 2) redemption for discounted DAI via participation in flap auctions. Basically the discount from market price at which flap auction sells DAI amounts to an interest paid on MKR as protocol debt. Anyways, the point is that MKR’s value is dependent on how much surplus DAI gets auctioned off, so any subtraction from the DAI surplus reduces MKR’s value. This is inevitable for our purposes, and should be acceptable so long as the expected gain in MKR value due to well paid contributors is greater than the short term loss due to reduction in MKR redemption opportunities.

What is not inevitable though, is the added uncertainty in MKR value due to complexity around when and how much DAI will be subtracted from the surplus. Right now, the mental calculus for a MKR holder is very simple: The protocol earns a profit from stability fees and liquidation penalties. Once it has earned more than a certain amount, the surplus get auctioned back to MKR holders in a sort of pay day event. Now, you are telling me that there is going to be a little leak in the surplus buffer, that pulls out dai according to some logic and thus reduces the frequency of flap auctions. Even if some logic is reasonably concise, it makes me wonder if there will be extended periods of time when all excess dai goes to contributors and not to MKR holders. Depending on the exact parameters in some logic, I may not be able to redeem my MKR for cheap DAI for a while, it’s hard to say. On the other hand, if you tell me that each time a new 10k DAI lot (the current “BUMP”/ auction lot size) is auctioned by the flapper, 2k DAI will be sent to contributors via SC, then I’m like: okay at least we are getting paid at the same time, and only when the protocol is making a a healthy profit. For this latter mechanism, the MKR holder barely has to update their mental model, since basically no new moving parts have been added.

Here you can see that the flapper has been quite busy recently. Scroll down and click “load all history” to see more. I have not collected and analyzed the historical data for flap auctions. This analysis would be pretty essential to determining what the appropriate amount to send to rainy day fund would be. Overall though, you can see that my proposal shifts complexity away from MKR holders onto SC contributors, which is kind of annoying but again may make it easier to pass.

Also, this document defines suck() as “mint unbacked stablecoin (ie dai)”, unless I am missing something, I think this is not what we want to do. We are talking about getting paid from protocol profit / dai surplus, not arbitrarily minting new dai in a way that is discontinuous with protocol profitability.

Regarding the complexity of equations in Grainmaker P1, I think it’s deceptively simple actually, my write up is just bad lol.

Sorry if any of the above is unclear, happy to clarify or expand anything as needed :slight_smile:

2 Likes
10

This is super helpful @DeltaFreq!

I think MKR stakeholders’ mental bandwidth may actually be the most scarce resource here. Optimizing for that makes sense. I also think that sourcing DAI from the flap auctions as you suggest might also be a good way to align MKR holder and contributor incentives. If contributors don’t get paid if MKR holders don’t, this will affect contributor decisions, especially if the reserve is running low. Security around income could be negotiated perhaps around the size of the rainy day fund, % diverted into the fund, or other clean mechanisms that are easy for all parties to understand. Which could be voted on by MKR holders when they vote on the other high-level parameters, such as the amount of DAI distributed every month, algorithms weights, etc.

Great to know this analysis is possible.

I would argue the value prop of SourceCred is, in a way, abstracting a way tons of complexity in regards to valuing contributions. Compared to the main SourceCred algo and the Maker system generally, the complexity of managing variable payouts from the protocol seems small by comparison.

Yeah, something like what you propos in Grainmaker P1 post could be totally workable and fairly elegant.

My sense from reading threads about this on the Maker forum is that some think “unbacked” DAI is fine, others have issue with it. Best to remove any cause for concern we can though.

1 Like