00:00: Intro with Rich Brown
08:41: Governance at a Glance with LFW
MIP 0 with Charles St. Louis
1:09:24: State of the Pegs with Vishesh
Welcome to the April 16th edition of Scientific Governance and Risk meeting, my name is Richard Brown, and I am the interim Governance facilitator. Today we're going to hear from Vishesh; he's going to give us a state of the pegs. Possibly LongForWisdom, I haven't given him a heads up, but maybe he'll do "Governance at a Glance." And we're going to hear from Charles St. Louis, as we dig into
MIP 0, the biggest
MIP of all. This is going to be an important discussion because we are getting more sophisticated, and the process is being brought to the table. And it's going to change the way things work if the community ratifies these things. We're going to be existing in a world that's different than the one we're in right now; soon, the time is rapidly approaching. The general idea is that at some point in May, we're going to flip over into a more
MIP-i-fied cadence that requires a re-think or a shift in the way we do things. Charles will give us a refresher on what
MIP 0 is all about and how it has implications for the way we govern the ecosystem and how we interact with each other. That's going to be a big discussion, so I'm not going to use up a lot of time.
What I do want to talk about is me. Let's talk about me for a second. I have a lot of different hats at MakerDAO, one of those hats that are more relevant to this community or group is being the
Interim Governance Facilitator. This role as a facilitator has a fairly sophisticated mandate associated with that role, which is in the forums. I want to focus on the key part of that title, "interim." The way we develop things at MakerDAO as a whole is that we need to decentralize. We need to refine and build out this protocol so that we can hand it to the community, and the community can take the reins, and we can all sit back and enjoy the fruits of our labor. In order to do that, it's our opinion that we need to bootstrap parts of the ecosystem. So we created these reference implementations, come up with ideas that are good, provide resources and funding, and frameworks around those groups of actors or tooling. Parts of the ecosystem, basically. Once it's up and running and has been refined and thought about, and revised, and edited, then the next step is to begin to find people who can assume those responsibilities for us, or with us. I think we're there(with regards to the Governance Facilitator role,) so this is super exciting for me.
I posted a thread in the forums about me nominating the first truly community-sourced Governance Facilitator. I think that many people who've been paying attention to this ecosystem will not see this as a surprise. I think there's no better person who can step up and assume a leadership role in the governance ecosystem than LongForWisdom. I've given him tons of really embarrassing compliments and praise in that forum thread, so I encourage everybody to take a look at it and consider some of my arguments for expanding the role that I currently occupy and formalizing, rewarding, and recognizing the incredible amount of work that Long has been doing over the last, who even knows how long? Feels like years, but it's probably closer to months.
He's really stepped up and has done a fantastic job. Personally, I think it's impossible to find somebody who better represents the needs of the community than LongForWisdom. So please have a look at that forum thread and let the community know what you think. Long, did I sufficiently embarrass you? I can give more praise publicly if you'd like.
Discussions happen in the Forum.
LFW: I do not have a speech or a presentation prepared. I'll respond on that thread in a couple of days. In general, nominating me is very gratifying, so thank you.
Rich: Aww, I think we just had a moment. Thank you, Long. To be serious, though, I could not possibly be happier with the level of work that you've put into the ecosystem, the diligence, deep thought, and idealism that comes along with your work. I've built out Governance ecosystems in different organizations in my long past, and I don't think I've ever seen anyone with as much chops as LongForWisdom, so Maker is fantastically lucky to have a resource like this. I'm extremely happy and looking forward to not being all alone in the Governance Facilitator world and watching this role develop as he puts his own stamp on it, and we eventually increase the number of Governance Facilitators and increase the throughput of this role.
Cyrus: Is this an additional Governance Facilitator role, or is this a replacement?
Rich: It's an addition. With an eye for replacement in the near future. With these interim roles and this bootstrapping process, we establish the norm and then move into a hand-off phase. I talk about this in the original mandate that it's my hope we understand what an Interim Governance Facilitator actually is. The next step is to onboard people from the community to begin assuming those same responsibilities. Then we have a team of Governance Facilitators, and it expands to begin addressing needs we haven't really spoken about that much but need to be addressed. Having governance facilitators in other parts of the world that have deeper insights into other demographics. Why don't we have one for the Latin American market? One for the APAC region? The list goes on. There is enough work to go around. My hope is that at some point, we have 2, 3, 4 facilitators. Once that machine is up and running, then the Foundation can take a step back, and the community can own it completely. That's the goal.
Discussion on the
MIP 0 and
MIP 3 have attracted a lot of feedback.
We had a new member of the forum, FullStreets, create a post regarding confidence in the peg, which is something that probably needs to be discussed more. This user is urging more aggressive action to address the peg.
Rich: We see the same conversations arise in the subreddit. One of the interesting things is that there are strong opinions that the peg must be fixed. The solutions seem to be diametrically opposed. Is there a consensus forming in the forum?
LFW: No, I don't think there's much consensus yet. From our perspective, we have basically done most of, or basically all of, the short-term things we can. The other things are onboarding collateral, or super long-term like changes to the protocol, like negative rates, or inject liquidity into the ecosystem. I don't think there's consensus, but we should be discussing it because we haven't seen much change in the last few weeks.
Will has been investigating updates in the GSM delay and has created a signal request for that. Questioning if we should set it back to 24 hours, or keep it at 4 hours, or something in between.
There's a request to see if we want to set a delay before a shutdown happens so that the ecosystem processes have time to do the things they need to do and be confident on the fixed date, as it's more difficult to define a date when we're relying on the executive vote to pass.
The Governance Poll passed, but we are currently in the middle of better understanding the details before deciding how to move forward with this issue.
Rich: (With regards to the topic of compensating vault holders)Do you have a sense that the community has aligned on a path forward? This is an interesting discussion because we've been talking about Governance Facilitators. I don't know how long I've been in this role and I've never really exercised any real power associated with it until the string of polls associated with the compensation strategy deviated significantly from established norms and signaling guidelines, and so I asked the community to form an ad-hoc working group to collect a plan on how they want to address things next week, so we can start dividing up those polls and get this show on the road. Does it feel like there is alignment there? Is there a group of people formed to solve this problem, or are we waiting for more discovery? Is it on MakerMan at this point?
LFW: There might be things I'm not aware of, but my understanding is that Makerman is working on the analysis of the auctions generally and specifically to Black Thursday. I don't think anyone's drastically objected to stopping the second poll, so there's no widespread outrage or anything.
Rich: The first poll was significant: is the compensation a good idea? Does the community want to do it, yes or no? The answer is yes. That's a big decision, very cool to watch happen. The second poll was what denomination should that compensation be in? That's where I felt like we've gone from macro to very micro, almost immediately. If we go down that road, there's going to be a lot of micro polls showing up. I hope that the community can align on a working group to establish stakeholders, figure out what the plan is, come up with the next steps, and then, as an ecosystem, divide what decision-making processes need to go along with that.
Makerman: I pretty much said it in the thread. I ran into a small hitch; I'm not sure if cmooney can talk about this or not, but the hitch slowed it down. My analysis should be complete by the weekend; I'm hoping to post it by Sunday or maybe Monday latest. My issues are in defining what we call Black Thursday and compensation. Do we do it with the first third of the zero-bid auctions and the last end or what? And then running the scenario analysis for compensation: at what level and how the money works. Doing it in Dai is a lot harder to think about and digest than to do it in ETH. I'm going to do it in ETH and then wait for the poll to thrash out.
It's going to be hard because when you can't see what the numbers look like in Dai, I don't know how we can vote on it that way. I have a real issue with defining this in terms of USDC or Dai, where ETH is pretty clean. And then it's just a matter of determining the time frame. Other than the hitch that I reported to cmooney, which I think has made its way to the Maker Foundation, that something I discovered in these analyses, that's it. I have my data set, and I'm ready to go through it. I was up all last night taking the data I had, putting it together, and getting it set for the final ruffle through and doing the consistency checks on it to make sure that it looks right.
MakerMan: I have a couple of missing vault numbers that don't look substantial. But otherwise, this should be pretty clean. I'll focus on these zero-bids, and I'll include, as a contrast, Vault 2288. A guy who self-liquidated through, I think, it was DeFiSaver, which gives you kind of a handle as a comparison: if you did this yourself, what would you have gotten. So there's at least one of those, maybe more. That's it on my side.
For those that don't know me, my name is Charles St. Louis; I work at the Maker Foundation on the Engineering General Team. I've been responsible for the research, architecting, and formalizing of Maker Governance on behalf of the Foundation.
Before I get started with the presentation, I want to provide a brief overview of what it will entail. So I'm going to give an introduction to the self-sustaining Maker initiative. Not too many details, just a recap. Then I'll introduce the
MIP framework itself, I'll walk through
MIP 0, and lastly, I'll provide a timeline update on what's to come in the next couple weeks.
So we officially kick-started the self-sustaining Maker initiative approximately 15 days ago, and then Rune went on to the following Governance call and talked about the three pillars of a self-sustaining DAO.
These three pillars (on the slide) are what long-run governance will need and what will eventually make MakerDAO self-sustainable.
EPCs and Domain Teams: Think of them as the decentralized workforce serving the DAO.
MIPs the way to effect change that EPCs, Domain Teams, and community members will use to maintain and improve the protocol and governance.
Vote delegates: You can think of them as politicians serving the broader community needs and helping them make the best decisions possible for the DAO.
With those key pillars in place, we will reach the position of implementing the first Governance Paradigm and be on our way of actually having a self-sustaining DAO.
MIP0 is structured:
Preamble: This is an administrative thing. It also helps with the management of long-term
MIPs. I'll go through the structure after.
Summary: gives a brief overview of what this
MIP is for.
Motivation: why is it needed in general.
Specification: the proposal details. What you're actually proposing. If it's a technical
MIP, the code. Including the executive code that will be needed to implement it if it does get ratified.
MIP0's case, there are no dependencies, but for example, in the collateral onboarding
MIP set, a lot of the
MIPs are relying on each other. So you then indicate which ones work together or are dependant on each other.
There's a section for replacements. In many cases, some
MIPs may become obsolete over time, or they aren't really in progress or being used, so you can create a new MIP to replace that with updated information, updated processes, and then you'd be indicating which one you'd like to replace.
These are the components of
MIP 0. I'm not going to go into too much detail about the first one because you can just read through them, but they do help provide a lot of context for specific words that are used throughout the entire initial 13
MIPs in terms of language and how they all relate.
c2 outlines the Core Principles. There were initially three, but, as part of the Request for Comments phase, LongForWisdom proposed two other ones which I'll get into.
c3 is the
MIP Lifecycle, which is very important. It highlights nine main steps that a
MIP needs to go through before it becomes ratified or rejected.
c4 is the Components and the Component Types. They break down the core specification of the
MIP itself. They can also be used to add technical types of proposals within them.
c5 is the Replacement Process is how you go about replacing a
c6 contains the templates.
c11 are the Domain Role Dependencies will rely upon for support as well as have to elect and remove them.
As an example, if you look at the collateral onboarding process, it needs to have all the components that someone can use to get collateral onboarded to a protocol, or else it's not complete.
Clarity and brevity are the new core principles that LongForWisdom proposed.
These are the nine steps that a
MIP has to go through before being ratified. In the interest of time, I've summarized them. There are a lot more details that you can find in the GitHub page or forum that talk about the criteria these stages and statuses need to meet before they can move to the next one.
Request for Comments(
RFC) is the stage where we're at right now. It's important to know that the ultimate edits are completely dependant on whether the
MIP author actually wants to do it. If they don't accept the community's feedback is ultimately up to governance to decide if they like it or not.
feedback period is in many cases 3 months, and then there's the
The Executive Vote is the final stamp for a MIP's ratification. If the
MIP gets voted through, it's granted the "accepted" status. This is to help maintain them overall and manage them more effectively.
The MIPs can have multiple components, as you can see with
MIP 0 there are 11. It helps satisfy completeness and readability.
MIP it's replacing would have to redirect all the ones that it depends on to make it more clear for people to follow.
I didn't mention it, but there are few other statuses that
MIPs can take. There's
withdrawn status (if the
MIP author deems that he doesn't want to continue at this point),
obsolete, or another willing community member can pick it up and finish the work there. That transition process is done with the support of the
There are three types of templates. General, technical, and sub-proposals. The General
MIP template is what
MIP 0 is.
MIP template is practically the same thing. Although the specification has a few other key elements that need to be included.
This is the proposed code, which includes the executive code that will need to be used to effect that change.
Security considerations, which are very important. You can be as thorough as you want with the security considerations, but it does help when you can be proactive, assuming what could go wrong with the introduction or implementation of a technical solution, such as including if it's backward compatible or not.
Auditor Information and their report. With technical solutions, it's important to have it audited.
Lastly, listing the needed license(s).
You can think of it as a mini-process to onboard new things, or remove, in many cases.
The sub proposal component is actually used for this
MIP itself for both electing the
MIP Editor and the
Governance Facilitator and also removing them. As you can see, there are formally named by the MIP number, the component, and then the SP number.
I, Charles St. Louis, will propose myself to be a
MIP editor next week, and then others will join from the community as we progress through.
So I didn't want to take up too much time with going over how the Domain Roles are elected and removed. They are fairly well laid out within the document itself, but these are the components that detail the removal processes and election processes for these roles. They're quite similar; the template is pretty much repeated other than the title.
Lastly, I want to provide a timeline.
Regarding the Request for Comments phase, I wanted to take a moment and tell you guys that I really appreciate any edits or further feedback; there's a lot on the forums. I've been working with LongForWisdom, especially making the edits. I know a lot of you have strong opinions. So if you have some time, please continue to do that.
If you want to have more details on what the other options are, if the ratification is delayed for one month, you can reference it on
MIP 0. I just didn't have enough space in the slide to detail it.
That was a lot of information, but I'm done now. If there are any brief questions that anyone has, I'll be happy to answer them if we have time. Otherwise, please go to the forums or the RocketChat channel (it's just #MIPs), and I'm looking forward to hearing from all of you.
LFW: I have a question about the timeline, rather than content. You mentioned the Smart Contracts team would do a sub-proposal to onboard themselves officially. Do we need to make sub-proposals for the Risk Team as well? They already went through a ratification vote. Would we need to go through the process again just so that it's recorded as an accepted
CTL: As of now, it could go either way. The risk team has officially proposed itself as the risk team to the public, as well as the Governance Facilitator, Rich himself, so it's kind of hand-wavy.
LFW: Yes, as you know, I'm not a fan of hand-wavy things. There's going to be a sub-proposal for the Smart Contracts teams onboarding, and that's going to go in the mix repository presumably and exist forever. Do we want the paper trail for the other teams? There's a list of the ratified teams in one of the
MIPs. I forgot which one it is. Do we just add the currently ratified teams to that?
CTL: There are two ways we could do it: we could add the currently ratified ones (the Governance Facilitator and the Risk Team) to the list prior by making a change before April 27th. Or we could submit sub-proposals to actually ratify them through the process themselves. I guess we can base it on community feedback and general consensus.
LongForWisdom: Ok, cool.
Will Remor: I'm not sure if I got that right from the proposals. There was the notion that was specifically for the Risk Team proposals, and I just wanted to clarify whether I understood it right around the counter-proposals. Because if the Risk Team is submitting a general risk model or a risk model for a particular asset, and then the counter-proposal needs to happen within an X period. I actually haven't seen a lot of people producing a risk model in 2 weeks. I was not sure whether that was the kind of proposal that was taken into account or the proposal of including some new Risk Team as part of the
MIP. It was a little bit uncertain the way that it was raised, so I just wanted to clarify whether risk modeling comes under those timelines as well.
CSL: When I was speaking to the competition proposals, if the timing says that we want to delay the ratification votes of the
MIPs, community members can propose anything that's directly competing with one of the 13
MIPs and provide it as an alternative for the community to choose.
CSL: The general risk model sub-proposal, you can make a competing proposal, but it doesn't necessarily need to be during this time. After the
MIPs framework is in place, there are general risk models that can be proposed, and it's up to the community to decide whether they want to use it or not. Cyrus might be able to cover some answers there.
Cyrus: I think the idea is
MIP 11 allows a template for any new risk team to essentially apply to be a risk team and submit whatever methodology they have for evaluating assets. Then, pending approval from the community of such a risk model, they could then propose asset evaluation risk parameters for any asset they want, of course, in conjunction with what the community wants. If there are competing assets or competing risk teams for the same asset, that shouldn't really be a problem. The community would essentially select one or the other.
WR: Yeah, I think the easiest way to frame what I was thinking was to imagine a competition where different risk teams are submitting competitive models for the same asset or the same purpose. So you have two playing around, and the one with the best parameters or the best accuracy leads the part.
C: I think that's generally the idea. Competing risk teams and essentially MKR holders will ultimately decide which methodology they want to go with. I don't think it's easy beforehand to declare which one is better.
W: Yeah, it was not about declaring beforehand, it was about the timeline, but I think that Charles has clarified that, so that sounds good.
chat Maker Man: wasn't sure I wanted to take the mic. But put as simply as I can community will have to decide whether what is put forward is sufficient. It is my opinion all of these will need revisiting, given time constraints. A question to everyone is whether something is better than nothing at this point unless a competing
MIP proposal can be put together. Right now, I don't see external community resources going after alternative
Maker Man: As follow up to my chat comment, my reaction to the
MIPs is, given the time frame, what we're doing, we're going to decide whether to go with what we have. And that's going to be for everyone to decide in terms of just MKR voting. Right now, I don't see external community resources going after an alternative
MIP set, I know LongForWisdom and I have discussed it, we both don't have the time to go after right now, we have other priorities. Someone else in the community can step up on doing an alternative
MIP set; we'd like to hear from you guys and talk to you. But I don't see it happening, so we're going to be looking at what we have and whether we want to vote it in as a placeholder. We'll have to revisit all of this, I think. I'm going to leave it at that.
Rich: Charles, can you maybe speak to how malleable or iterative the
MIPs sets are, and what happens if the community comes up with input in the next month or something after ratification?
Charles St Louis: In general, if you don't feel like you have the time to create alternative
MIPs, or competing
MIPs rather, all the more emphasis on putting a lot of effort into this Request for Comments phase and trying to make the current
MIPs as adopted as possible. The
MIPs framework, in general, is built upon iterative improvements, and as I mentioned, there's an entire component in
MIP 0 dedicated to replacements of
MIPs. There's no timeline for replacing a
MIP in the future.
Maker Man: I was going to say, that's the whole point. If we look at what we have now and decide, we can always redo it later. It's not that critical, and when I look at the scheme of what's going on. I mean, it's important, yes. But what we get in place when and how, what it means, it's going to be how we use it, really. We all know we're going to be going through these things when we finally start doing them and going: "Oh, we got to change this" or "We should add this."
One thing I was going to suggest: I don't like the sub-proposal idea, and I don't think it works. My case here is that if it's in the proposal, it should be a component. If it isn't, it should be its own
MIP, if it can be separate. If it doesn't have to be and accounts for the whole thing you're trying to describe, just stick it in there. The idea of templates for what Domain teams have to execute
MIPs, those are in templates, we just vote on them. We change the list like a vote revision; when you think about it from that context, the details of who and what you put in things, think about it in the sense of lists and templates of what they do, and who does it.
"Who's doing what with what
MIPs," those are lists of things. You have stuff in the templates of literal lists of things, that's just a list for who gets to do
MIP 0 or who's dealing with governance,
MIP 1 or what they're doing. Generally, in terms of names and domains, EPCs, all the contracts that we're going to be dealing with, Oracle suppliers, and who we give Oracle information to, etc. All this kind of stuff is off to the side in template information in some of these
MIPs. How do we change governance parameters? That's going to be a kind of template. E.g., what numbers we change. For doing financial governance and risk governance. They don't have to be their own
MIP. They can be a template of data within a
MIP that we execute as a sequence. And not specifically laid out in a
MIP, just its own little list.
CSL: So basically there would be less
MIPs and more components with sub-proposals, is that what you're saying?
Maker Man: That was my point on the sub-proposals. They're not sub-proposals, they're data elements to the
MIP. One's that Governance then later decides what to add to, and who to remove, and whatever conditions they want to put on them generally, which ideally would go in the
MIP itself. It reduced the number of
MIPs, and it puts just the details of how these people access and operate what and how.
CSL: That's great feedback. If you could write it down and have it posted somewhere where we can iterate on, that would be really helpful.
MM: Well, that was the forum comment. Let's revisit this another time.
Cyrus: let's post the link to the forum for the
MIPs, as I'm not sure it's been posted yet. And there's also a Rocket.Chat channel for discussion.
MM: If there's anybody out there working on an alternative
MIP set, I just want to know. I just don't think it's happening. So Governance is going to sit here and go "well, do we take it or no?". Just look at it from a governance perspective, right? We're going to have to vote on this in the time frame presented, and it will be done as is. The amount of work that can be actually done to change it is kind of limited. The people here who would work on this are kind of under different guns now realistically. Unless somebody else steps up, please, do!
LFW: I would be interested to hear if any of the community members even if they're not willing or have the time to work on an alternative
MIP set themselves, I'm interested to know if anybody actively wants there to be an alternative. Does anyone think that we need an alternative? Does everyone think the current versions are fine?
Rich: That's an interesting question. Maybe we can make an informal poll. I'm also interested in knowing how much the community has a mental model of what the
MIPs process is all about. I think there's a lot of cognitive overhead here, and I'm unsure of how well this process has been absorbed by the general ecosystem. We might be getting slightly ahead of ourselves to find out whether people have already begun creating mental models of alternative
MIP processes and how many people are trying to wrap their heads around what the actual
MIP process is.
WR: Working by example, do we have quite a significant number of
MIPs that have been submitted that actually fit into the model, or are they mostly just at template level at this point?
CSL: Can you repeat that? I wanted to make a slight correction when I was talking about the domain teams that have been ratified before: the risk team actually never officially proposed themselves as a risk team. That was only Rich for the Governance Facilitator. The risk teams are only judged based on the general models. I just wanted to make that correction. Sorry for that mistake.
Cyrus: I think that goes in line with Will's earlier question about how new risk teams are essentially evaluated based on the content they're producing. I think the current structure for the
MIPs, regarding the risk teams, is essential that they would be proposing a general model for review by the community. That's what gets voted-in as opposed to a specific risk team based on the individuals. The idea being that any discussions or issues with the risk parameters or methodologies can stem directly from the model itself and not the people behind it. If I'm not mistaken, there isn't necessarily, at least for
MIP 11, it would just be the general model that's proposed, and I guess the risk team would be part of the domain team aspect? Sorry.
LFW: I'm pretty sure that the general risk models need to be submitted by the domain risk team.
CY: Yeah, I think I confused myself there actually.
WR: So then there is a workflow of one then the other, kind of thing. Am I getting it right? First, you sign yourself in as a risk team, and then you submit a model, or you can actually submit a model not being part of the risk team?
CSL: The first one.
LFW: What did you say about the risk team not being ratified? Did we never ratify the interim risk team?
CY: Yes, that was a correction; the current risk team was never officially ratified as a risk team of any sort in the same way that Rich was.
MM: I was just posting on the side chat that I think it's interesting, with respect to the
MIPs here, we have a one-bidder auction for
MIP set. When I see the one-bid auctions in the liquidations, I cringe because those are the worst ones all the way to the zero levels. We got the same kind of thing going on here at Maker. I'd love to see multiple bidders for the positions and functions, talking about risk, Governance, legal, it's an interesting idea. How many bidders do we have for our functions?
Rich: Yes, I agree. That's why I wanted to get this general temperature of the room about the visibility on the process, and how well it's been absorbed. It feels like we have people, like engaged stakeholders, that have deep insights into
MIPs, some have vague insights, and others that have no insights. Trying to get everyone up to speed at the same time is a little bit of a challenge. I guess the question is for Charles: how do we accelerate? It's an open question. I'm hesitant to lead a conversation because particularly when we haven't addressed all the comments on the side chat.
Mitote: The biggest thing we need to keep in mind is what are the goals, what are we trying to achieve, what we are trying to do, and how do we want to do it. Realizing that the
MIP process is mainly a perspective on how to organize ourselves socially in order to agree on things and move things to MKR holders. I guess in terms of alternatives, if people have alternative
MIP sets, then that's awesome, and let's see them. But aside that, continuing the way we have been building up the signaling process, the collateral onboarding, there are all sorts of other questions like compensation, domain teams, and all that. There are other ways to think about how we organize ourselves socially.
CSL: The main goal of this framework is to enable the community to drive the organization of governance and effectively help maintain and improve the protocol over time. In 10 years, there might be a whole different framework, a whole different type of process. The whole point is that we're really trying to kick-start this next step of having everything be community-driven and built from the roots up.
Mitote: What I'm trying to say is, to some degree, it already is. People are already organizing, and people are already influencing things. I think one of the bigger questions is: how should domain teams interface with Governance? Those people have deep knowledge and skills on certain things, so we should be leveraging that a little bit more. MakerMan is making a good point in the side chat: that at the end of the day, MKR holders are the ones deciding. All of this needs to be understood in that context. This process isn't going to change that fundamental fact.
CSL: Do you have any ideas for how you would propose the domain teams working with governance or any alternative framework? I would be interested in that.
Mitote: Yes. I think I've sent some stuff in the past in the working group before. I've been toying with other ideas where each different domain having main heads, kind of like how it is now, Rich with Governance, Cyrus with Risk, Mariano with Smart Contracts. Having MKR holders allot budgets to them, maybe they bring a couple of other people on the leads too, and those leads distributing and contracting other people in their networks that they know they're doing good work for Smart Contracts or Risk. How would MKR holders know who's good at it? I'd much rather trust Cyrus to hire or contract someone to do some work, rather than guessing or trying to figure it out myself.
CY: That's a great point. The evaluation process or the hiring of new Risk teams is going to require its own fairly significant initiative. I don't think it's going to be as simple as "Oh, here's a
MIP," and it just says "vote X, Y, Z as an Oracle team," and then that's the end of it. I would view these
MIPs as an explanation of things that need to get done, but the actual process behind that will be significantly more involved, I think, in a good way.
M: At the end of the day, it is just people talking to each other and trying to figure out how to do it. Also, how we pay people. I have no idea how the Foundation pays Vishesh or whoever, but I'm guessing that might be different from how Smart Contracts people work, or how Rich works at the community development department. It might be hard for MKR holders to figure it out.
R: Yes, it's fantastically complicated, and we're running out of time, so I'm going to try to put a bow on this thing if I can. But to speak to that one specific issue, this is something that we have talked about on calls back to the beginning of time. We have the Foundation, and we have the community. As we become more sophisticated, the community self-organizes. So the community we have now is nothing like we had one year ago, or two years ago. We have PR teams, risk teams, and we have collateral onboarding teams, and people are self-organizing, which is ideal. That's exactly what we need to decentralize. But this is a long process. Once groups of actors self-identify or get identified by the ecosystem, and then we look to fill those roles. The Foundation has to bootstrap those things because there's no funding mechanism sitting around right now that we can use to allocate to the ecosystem. It's built into the protocol, and it's part of the plan, to have the buffer and MKR stability fees inevitably be funding these things. One of the major evolutions, or growth spurts, that the community has to go through is how does it handle an allocation of its own budget to fund the actors that it's identified? That's when EPC and domain teams come into play. There are working groups that started recently to clarify what the implications of that are, how they can work, and all the rest of it. There will be communication and presentations and all kind of things coming about how that happens. As far as I'm concerned, that's a major paradigm shift, that's when true autonomy happens. When, ultimately, the ecosystem needs to be able to identify its own requirements and allocate some resources that satisfy those requirements. It's going to be enormously important, but there's no clear picture of exactly what that looks like right now, other than the fact that the protocol needs to be able to pay for the protocol operations, so we'll see what that looks like soon. I feel that I might be preemptively ending this debate, which I think is super helpful and healthy, so we have to continue it.
Rich: Here's a summary: we have
MIPs process, we have
MIP 0, which is sophisticated, and that is going to launch us into
MIP 3. And
MIP 3 is what the government life cycle is all about. And there's an aggressive timeline associated with this. On May 4th, we begin a new governance cycle that's outlined in
MIP 3, so the community needs to have an understanding of what that implies and what the responsibilities are and how that will change things, assuming that the
MIPs are ratified. I encourage people to engage with this process, so have a look at the forum thread posted here. Express your feelings and your thoughts and suggestions for improvements.
The long story short is that there has not been a significant change in what's going on with the Dai supply overall. So, those values are sitting at a pretty steady-state, now that Dai from USDC is down to under a million. Obviously, that part makes sense, given the reduced need for that at the moment and the higher cost.
In terms of the collateral portfolio, ETH has been sitting pretty constant from where it was last week. The collateralization ratios have not changed that much.
As you can see that the liquidation prices are primarily between $103 and $80, so that's still pretty constant.
For DAI trades, what we saw in the last 24 hours was a decent volume on Uniswap. This is a small, atypical data point; usually, it's not such a large percentage for Uniswap. We saw a fair amount of slippage there.
The Volume Weight Average Price (VWAP) of Dai is still sitting above peg at ~$1.02.
Over the last 24 hours, the Sai trades, though relatively few, were trading down below peg. This is interesting because Sai and Dai usually follow each other pretty well. Perhaps that's an indication that things are a little shaky on the Sai peg.
In terms of USDC, a large chunk of the CR is closer to the 120% requirement, since there's low perceived volatility.
Though some of those positions do maintain more collateral than they need.
In the last week, Dai trades are very similar. Mostly hovering at a $1.02 with a bit more trading on the last day. All still steadily above the peg.
LFW: I noticed Dai locked in the DSR is decreasing, which is, I think, good. It's not quick, but still coming down. Do you have any thoughts?
V: It was sort of weird that Dai in DSR wasn't coming down faster earlier, given that the rates were adjusted. That makes total sense; the weird part is that it took so long.
Rich: We've seen this behavior before though, these apps are fantastically sticky for some reason. There is maybe some sort of threshold I'm unclear on what it is, where people start breaking out hardware wallets and start moving things to other areas. Maybe it's a lack of better alternatives if the DSR is 0.
V: Presumably, the people who do use it in that way see is relatively risk-free or a free parking spot on a monopoly board. In that context, to them, the yield that's available for supplying it in other platforms maybe doesn't justify their perceived potential risks in using those platforms. They view it as, "ok, I'm eating the capital costs." But from their perspective, it's a risk-free option.
V: The gist is, not much has changed this past week, it's been relatively quiet.
Rich: I'm going to summarize some stuff:
We had a long presentation from Charles, please join the forums for the discussion and engage with the MIPS discussion. There are many weighty decisions that we'll have to make in the coming weeks. There are many things that we did not address in this call that are happening, so many things that I'm probably not going to remember all of them. Here's a list:
GSM. Needs to be understood and reviewed.
Mechanisms for dark fixes. Who do we trust? How do we trust them? There is a social layer there that needs to be understood when it comes to fixing problems in the protocol.
SCD shutdown: there's a topic worthy of conversation. It's fairly monumental. The community has signaled that they want to do it on the 24th. There are issues that need to be discussed here, though. And this is a topic that I'm going to be revisiting more and more in the coming weeks, the difference between intent and feasibility.
Rich: We have an open-source governance ecosystem, where people can come in, make a proposal, the MKR holders can signal agreement or disagreement. But, that doesn't make the world turn backward. If the community wants to do a thing, they can say they want that thing to happen. But there is this missing piece of the puzzle where feasibility comes into play. Is it possible to do that thing?
How long will it take to do that thing?
Who needs to do that thing?
What order those things need to happen.
This is, probably, a highly technical group, so we all been through this process in our own specific domains. Coming up with a good idea is one thing, getting a project plan, road map, and implementation (and all the rest of those wonderful things) in order is quite another.
To loop this back to what I was talking about. The community has signaled that they want to shut down by the 24th, but we all have to understand what does that actually mean. How does that work? How are we going to tell people about it? Does the rest of the ecosystem know it's coming? There are lots of conversations that need to happen. If you have an interest in SCD and its imminent demise, please join the forums as well.
Cyrus: On Tuesday and Wednesday, the risk team held additional governance calls. We encourage everyone to check out the recordings where we discussed some collateral risk modeling type stuff.
Questions from Will about if we're going to continue these risk calls like last week. As of right now, I think we will. I think we'll try to do some additional ones outside the regular Thursday circuit, but we haven't quite locked down the details about times and dates about that.
Will: Yeah, awesome. The calls from last week are the ones that I'm more interested in being at. I missed the notification, so it's all good. Looking forward to the risk and data-focused calls in the future.
Rich: Thanks Cyrus, for that clarity. We can look forward to that. A lot to absorb, so I'll summarize: join the forums. That's where governance is happening, that's where your voice can be heard, where the community creates consensus. The social layer that the MKR holders, by and large, follow. If you want to fix the protocol, make it better, improve it, alter it, that's the place to go. Thanks, everyone, great call. Talk to you next week.
SCD: The Single-Collateral Dai system
MCD: The Multi-Collateral Dai system
CR: Collateralization Ratio
DC: Debt Ceiling
ES: Emergency Shutdown
EV: Executive Vote
GP: Governance Poll
SF: Stability Fee
DSR: Dai Savings Rate
MIP: Maker Improvement Proposal
Tim Black produced this summary.
David Utrobin produced this summary.
Igor Teslya produced this summary.
Juan Guillen produced this summary.
Everyone who spoke and presented on the call (listed in the headers.)