Episode 49: August 22, 2019
00:00: Intro with Rich Brown
02:55: Q&A about Governance Facilitator Role with Rich Brown
13:45 : Recap of Forum Topics with LongForWisdom
17:46: Risk Teams Mandate discussion with Cyrus Younesssi
53:22: Analysis with Vishesh
01:06:56: Post-call discussion with Matthew Rabinowitz
Summary & Introduction 00:00
- Give us feedback about the call.
- DISCUSSION HAPPENS IN THE FORUM
Q&A for Governance Facilitator Role
02:55: Concern #1: The timeline seems too short to get meaningful community engagement.
- We’ve been wrestling with this. The amount of time it takes to evaluate these things properly is one of the main first questions we need to decide on as a community.
- We made a guess and put a timeline of two weeks because we don’t know how much time is needed. The expectation was that if there were low community interaction and debate, then we would move it to a forum poll and then into the Governance Polls. If we were to see a lot of community interaction and debate, we could easily delay things and tune it to the preferences of the community. Nothing is set in stone, and it’s possible to push things up due to so many open questions.
- LongForWisdom: the proposal itself is great, I just have this feedback from a process standpoint.
- These are broad strokes, and this is an iterative process. We’ve identified three different schools of thought about how to move ahead with Governance:
- Canonical source of truth model: suggesting we create a framework with sufficient resolution and represent the community as one unified guidebook of principles and processes. If the community says no, we revise and try to resubmit a better-suited framework as a whole.
- Manual model: Setting prudent rules for all the processes and defining a clear manual for how Governance should be run.
- Iterative model: We take an approach of making one decision at a time, and doing our best to imrove the idea by implementing it and revisiting it in the future to see if we can make it better.
- We think Governance is an iterative process, and this is all just a way of saying we don’t exactly know the best way to move forward, but we expect the community to guide us in the right direction.
- As the Foundation, we need to be mindful of the fact that we are not a small project. We shouldn’t be having radical experiments. Governance should plan in baby steps that can be improved as we move forward in time.
- There are more concerns to cover, but in the interest of time, we will leave it here for now. We encourage you to join the discussion on the forums where we will be going back and forth on other concerns. We may continue some Q&A in the post-call discussion.
Forum Activity Recap 13:45
Risk Team Mandate Review & Discussion 17:46
- Mandate: Risk Teams
- The history of this mandate: From the early days, there has always been this notion of having decentralized risk teams. When Steven came, he framed it as a decentralized risk function. In getting closer to MCD launch, there are specifics about how Risk Teams operate that need to be answered. As we started to explain and discuss many of these open questions online, we created this document to capture some of the answers that seem to make the most sense.
- There aren’t just operational questions for candidate risk teams, but for MKR holders themselves as well. We realized that we need to get everyone on the same page for how Risk Teams function in our community to minimize any potential chaos and lack of clarity.
- It’s difficult for a Risk Team to come along and engage in arbitrary negotiations with a DAO. To make things easier, this document is meant to benefit MKR holders and Risk Teams by defining some things clearly.
- Ratifying this mandate through an official governance poll will help with the process of ratifying Risk Teams.
- One concern we had with the purely decentralized version is the amount of overhead that would go into onboarding a risk team, risk models, parameters, etc.
- By creating this mandate, we are putting forth a first pass at how we might do a practical implementation of Risk Governance.
- This is a good introduction to people who are interested in becoming risk teams.
23:04: Summary of the mandate itself.
- In this mandate, we tried to strike a balance between specifics that we can define now and allowing for vagueness on issues that we will have more clarity on in the future. This document was designed to set a threshold for safety and responsibility for how risk teams might operate while leaving room for growth and iteration.
42:55: comments on how Risk Teams get compensated.
- a fuller framework will be developed over the coming months.
38:32: How do we enforce that with actors that don’t follow the rules?
- That’s part of the reason this mandate is being put up for a vote to be ratified. Actors who circumvent this proposal should not be legitimized. Presumably, this would be one of the roles of the Governance Facilitator.
- There will be a particular set of checks and balances in place to ensure quality and rigor. If a Risk Team is not living up to standards, there will be a way to out them.
44:09: How do we handle consensus around changes and deviations from the general model?
- Risk Teams would need to resubmit an iterated model and explain why their thinking has been updated. If you want to make changes to the general model, it needs to go through a vote.
- We need to focus our disagreements on the methodologies of the Risk Models rather than the outputs themselves to avoid unneeded disputes.
47:03: Question on how responsibility works for Risk Teams & MKR holders.
- Ultimately MKR holders vote in all these risk parameters. Risk teams can only output suggestions.
- From a community standpoint, it should be on us the manage and oversee these risk models and outputs. There should be some scrutiny at all times, which can be achieved in understanding that MKR holders have complete responsibility. Risk teams are contractors.
Dai Analytics 53:22
Santiment Maker Data
Graphs about Maker
Graphs about DeFi Loans
DAI 24hr VWAP Graph
- ETH price has been down; It took a sharp jump down around the 15th of August.
- The total USD$ value of collateral has gone down. Though, in nominal terms, the actual amount of collateral has been relatively flat.
- Over the last 7 days, the trading volume has been relatively low, around 2MM per day.
- The price has been sitting slightly above a dollar for the previous 7days & 24hrs.
- The supply has been relatively steady around 76-78MM.
- The overall Collateraization Ratio has come down, which indicates a higher risk in the system since the amount of total debt stayed the same.
- The amount of leveraging behavior has been comparatively low lately.
- Price movements of ETH have not significantly impacted drawing and wiping activity.
- As has been previously discussed, the Stability Fee is a modifying variable that affects what happens with Dai supply through ETH’s price action as an input.
- I don’t imagine that lowering the Stability Fee slightly would have a significant effect on the Dai price. Though there is a case to be made that given the reduced demand, we should lower the SF slightly.
Secondary Lending Platforms
- The rates have been more or less steady.
- There is a 2-3 point spread between borrow and supply rates since the beginning of July.
- Borrow volume has picked up slightly but is overall remaining steady.
- Supply volume has continued to increase, although the increase has been slower on Compound rather than dYdX in the last week.
- The utilization rate on Compound has come down to around 75-78%, and for dYdX it was holding steady in the 70s and has been in a relatively stable state. This means that the buffer that exists on SLPs is still just sitting there.
Questions & Comments to Vishesh
01:05:46: We are very close to a lowering of the SF to 18.5%
- What tools were used to allow Dai to float at $1 when it first launched in the immature market? The reason I ask is because we should consider the practical details on how a new Dai from MCD will behave during first launch, and whether we should be concerned considering the market has matured and it may take more in the beginning to bootstrap the peg.
- Rich: we don’t have an answer at the moment, we need to revisit this question next week.
- When you go from system A to system B, the lack of immediate demand on system b might be burdened with downward pressure of supply. That is the crux of my concern.
01:13:02: Lasse - One mitigating factor is that the migration contract will also allow for the conversion of MCDDai to SCDDai. So if there is a significant price difference, there will be an incentive to arbitrage between the two Dais.
- The migration contract creates one CDP where all SCDDai can be deposited and based on this in MCD, MCDDai can be issued from that. And vice-versa, if you want to move your MCDDai into SCDDai the contract would remove the SCDDai collateral and give it to the user.
- This is a proposal for the migration mechanism.