00:00: Intro with Rich Brown
08:02:''The Self-Sustaining MakerDAO Initiative'' with Rune Christensen
1:22:43: Dai Peg Analysis with Vishesh
Hello everyone, Welcome to the April 2nd edition of the Scientific Governance and Risk meeting at MakerDAO. I am the head of Community Development, and in this context, I'm the Interim Governance Facilitator. We have a really interesting call today; We have a special guest who I will introduce in a second. There will be a lot of questions and debate, looking forward to it.
If you have questions and access to a microphone don't be shy about speaking up. We have a highly intelligent group of people here. We need to hear from everyone. If you don't have access to a mic or are pretending to be working somewhere, type your questions in the side-bar. I'll keep an eye on that and will try to ask those for you.
Keep an eye on the disassociated chats, there's been this trend recently where we have multiple conversations happening. One in the call, and one in the chat.
Setting the context, I'll continue to mention the cycle of urgency, apathy, distraction, and denial. It's a meta-cycle that we go through in the ecosystem as a whole but also the Governance community as a microcosm of that same cycle/pattern of behavior.
What that looks like is: something happens and we need to furiously address that issue and it's all hand on deck. We're laser-focused on fixing that problem. Once the urgency passes, seven days later we start with the next thing. we frequently miss these dangling threads that we have lying around. Something bad just happened and we got through that thing, and now we're not talking about it anymore. It's kind of weird. An apathy phase can kick in. We start hitting distraction phases where we find a new emergency, new shiny object, or initiatives happening and we try to get through those and lose track of the past initiatives.
It may sound esoteric but I made a list! These are things we have been talking about over the last 2 months.
MKR token authority
DeFi consortium (led by RichCL)
Collateral onboarding as a major initiative
Flop auction tweaking
PR teams that are self-organizing, which is super healthy
Governance vote cadence
Voting types: Ranked-choice versus first-past-the-post voting
How do we handle Engagement
The list of threads goes on-and-on. We've talked about this in the past; Governance requires operational overhead, particularly open-source-governance, like what we have here. Where the hierarchy is flat and people need to step up to the plate. We need to maintain initiative, momentum, agility, and at the same time, it's very complicated. It's my contention, and I try to avoid making judgments or conclusions in these calls, that we've reached a cap on what cognitive, bureaucratic, and operational overhead that we can handle as a group with the methodology that we've been using. We've hit this stage where things drop off the radar. The question is how do we handle this world we live in that's for more complex than the one we lived in just 16 months ago. How do we move forward and maintain momentum?
Here's the segue(pronounced segway): Rune and Charles have been working on this issue for a while; giving it deep thought, and have a plan for us. Rune will articulate this plan today, how this ecosystem and group can handle some of the overhead. Some of the thread gathering that needs to be done. How we can collaborate on moving forward and tackling the fantastic amount of work for us.
Discussions happen in the Forum.
This slideshow has been used internally in the Foundation, aligning for the next steps. We've launched
MCD. Delivering the big piece of technology that the foundation existed to deliver. What is the next step after that? What is the final phase of the Foundation? The answer is to make MakerDAO self-sustainable and governance fully empowered to the point where the Foundation can disappear entirely, and ultimately Maker can reach its full potential as a decentralized project.
I'm going to go through the slides, but my idea is to make this as a discussion rather than a solo presentation. I expect every single slide to have points that people will be interested in, so potentially there will be questions and discussion. Hopefully Rich and Charles can also chime in with stuff. We should also make sure to move the conversation along; there is something like 7 or 8 slides in total and we have to make sure we get through the whole thing and we don't rabbit-hole on just one topic.
Overall, this is a very brief, general, high-level overview of all the different pieces that are going to come together in order to spell out the future of the project, from the perspective of the Foundation.
The standing point is: the Maker Ecosystem Growth Foundation(Full legal name of the Maker Foundation) fundamentally exists to bootstrap the DAO. It was born to create the technology and then to empower the community to become increasingly decentralized over time and ultimately take over control completely. This was actually spelled out in the Foundation proposal, which at this point is probably ancient history that most people don't know about. The concept was ratified in the community that the Foundation would start off as having a lot of responsibility in the community and ecosystem, but gradually will step back, decentralizing the project further and further.
With MCD delivered, it is time to accelerate the decentralization. We can really see the final step, the last mile, from the community running a lot of things, to the point where there's no need for the Foundation because the community can handle everything on its own, which is what we call: Self-Sustaining MakerDAO.
For that, we need a new generation of core governance contributors, of technical contributors, of people being more empowered with resources and tools to deal with this new world of self-sustaining Dai. And the point that is important to make is that the Foundation does have a finite runway.
It has a lot of capital because it distributed all of the MKR, but at some point, that is meant to run out. The strategy has been that the Foundation takes a lot of action, does a lot of stuff, has a lot of employees, ultimately because we want to very quickly get to the point where the community is fully empowered.
This is a starting point. Of course, the Foundation is not dissolving anytime soon. There are several years left where the Foundation will be operating at full steam. And then from there this process of dissolution will begin. It's important that we already, now, in the community, begin preparing governance to take over the system.
Richard Brown: I can try and seed some discussion; I'll pretend I don't know the answer to this question. Is there a timeline in mind for this gradual decentralization?
Rune: It's very important to note that the rollout of this self-sustaining MakerDAO initiative is going to be a step-by-step process with an emphasis on safety. We shouldn't jump off of a cliff taking drastic action without understanding the consequences. The timeline can't be fixed in stone; generally, the idea is about 2 years from now the Foundation will begin the dissolution process and the dissolution will be gradual. The process will be taken slowly and in-hand with the community.
chat Akiva(read by Richard Brown): In relation to the 3rd point; Is the Foundation's revenue included in calculating the runway?
Rune: Great point. This speaks about the broad plan for what the dissolution looks like. Without going into the details, the Foundation is preparing a transparency report with much greater insight. This would give the community resources and materials giving a much greater insight into what is going on within the Foundation, what are the different teams and functions and so on. The different assets that the Foundation controls. The Foundation has a lot of assets. One example is Oasis, which is a very popular DeFi front-end. The plan of the dissolution is that some of these assets can actually become self-sustaining in their own right. They don't have to be attached. Oasis could become its own self-sustaining DeFi project. The Foundation team will not go away and leave the community. The team will change and be in a different form. Hopefully, as many people as possible and as many assets as possible will be regular members of the community, like everyone else and continue contributing without any official status.
Now I will get into the details of what self-sustaining MakerDAO actually means.
We have defined three core pillars. The goal is to achieve long-run governance. A state where the community is able to run all aspects of the protocol, covering all risks, take advantage of all the opportunities, manage every single dynamic of the protocol for the long-run. With no gaps, nothing where there's some sort of reliance on a central party or the Foundation or some external parties. To achieve this, to build this concretely, there are these three pillars that the Foundation considers very important. These are not new concepts, they are all continuations of formalizations of what's organically emerged in the community already.
The first is the Elected Paid Contributors(EPC) and Domain Teams.
We already have several domain teams: Risk Teams, the Governance Facilitator, an Oracles Team. All of these teams operate in a somewhat formal environment and have been empowered by the community. This has to be developed further. The crucial element of compensation by the Maker Protocol needs to be added to it so that governance has full autonomous control over these resources in the long run.
The second is Maker Improvement Proposals; these were introduced by Charles in the forums yesterday.
The Foundation will make a series of MIP's to bootstrap this entire concept. The goal is to formalize a structure that is already happening organically in the community. We see in the forums, with signal request polls, where this decision-making begins in the ideation-conception stage, and then becomes a more formal proposal and ultimately goes to vote. MIPs are a way to completely formalize and structure this concept and then make the process entirely transparent end-to-end, so there's no black box. It's to really spell everything out in order to maximize access for everyone and make it very accessible and easy for voters to consider and see the whole process end-to-end.
Finally, we have vote delegates. People or entities that are assigned MKR votes by MKR holders.
The Foundation believes that vote delegation is incredibly important to overhaul the way voting currently works. To move it away from being mainly dominated by a few whales/large MKR holders.
Additionally, sometimes it's not easy to understand why exactly they're voting in the way they are. This pillar will help us enter a new paradigm where public delegates somehow interface directly with the community and are directly accountable for how they vote and provide a better connection between the discussion happening in the community and the outcomes from the voting on-chain.
These three pillars need to be wrapped-up and implemented in what's called a Governance Paradigm. This is a technical term, a complete set of processes that covers these things and a complete team of elected paid contributors and domain teams that can actually carry out the work that needs to be done within these processes. As well as a healthy ecosystem of voting and decision making with delegates that have good relationships and good communication with the community and can actually react with the emerging will of the governance community. I'll go in-depth on all of these things but want to see if any questions have popped up.
Mitote: Long term, what do you think of domain teams having voting rights?
Rune: This is one of the things that need to be put up for debate. MIPs will allow us as a community together to clarify and figure out how we want these rules and concepts to be decided by the community. From my perspective, I think that the domain teams, well I like to make the analogy to politics and governments. I see Elected Paid Contributors and Domain Teams, where people such as risk teams, and smart contracts developers are paid by the protocol to make it sustainable, and they are like public servants.
They are similar to people who work in the government, for the government, and running the different ministries and executing all the different operations that a government needs to do. On the other hand, you have the vote delegates, who are like the politicians, they make the big decisions. When the course of action isn't totally clear, it is up to MKR voters to make the decision.
The domain teams are more about implementation rather than them being the political actors that are meant to push particular opinions in the community. The community as a whole needs to discuss that, and start defining the Maker Improvement Proposals to define these proposals and figure out the pros and cons.
lastmjs: How will the payments work legally? If I'm a contractor that needs to be paid by this nebulous organization, what kind of documents will I need?
Rune: Great question. There's no answer to it right now. There is an internal working group within the Foundation, being led by our HR function that is focused on coming up with some ideas for how the community will decide to actually structure this. One idea that's been floating around a lot, that I'm a fan of, is the idea that the DAO may want to have a decentralized network of legal entities. Potentially having a lot of foundations around the world that are able to be funded directly from the protocol.
You can use those as a kind of intermediary. All of that is speculation at this point though, and the foundation will work diligently on some real analysis to figure out what are some good options for this. Ultimately, it also comes down to what the community wants. There's a tradeoff. You may want to go in one direction, putting the protocol toward paying out the money through the code and letting the recipients figure it out. Or the community can go the other way: the DAO will take care as much as possible and make it as easy as possible to be a contributor in order to attract more contributors. And the Foundation will try to come up with some data points on this with as many insights as possible to help make the right decision and ultimately propose a structure.
Rune: Why is it so important to get started now? The number one priority should be that when the Foundation starts dissolving, it should not have a negative impact on the performance of the project.
The community should be fully set up to handle everything, to cover all risks, and take advantage of all opportunities. And really, the dissolution of the Foundation should be an inflection point that sees the project improve significantly. It should not be a set back where we aren't quite ready and then the community goes into a tailspin and has to react and figure out how to deal with that now that not all the bases aren't covered. The community needs to have the ability to do long-run governance in advance so the transition of the dissolution of the Foundation can be as smooth as possible.
For this, we will need governance processes that are well-defined and formalized; that's the MIP process. That by itself is not enough. We need practical tools. The community needs to already have this experience of governing the system through formalized processes. It's not like from one day to the other suddenly we have these processes and we need to figure out what to do with them. Instead, when the Foundation starts dissolving, no one should notice because we're already operating through this paradigm. It should be this gradual step-by-step replacement of the Foundation responsibilities with formalized processes in the community.
Of course, we also need to significantly improve the state of the whole ecosystem. Both, from the Foundation and also from the community. The technology needs to be more polished, so we don't have unexpected behavior happening. Everything needs to documented. We need to have a completely different rigor when it comes to documentation because nothing can be left as oral history. Everything has to be written down and clearly available as documentation. And then we need to do knowledge-sharing from contributors within the Foundation to this new generation of elected contributors that are going to work directly for the Protocol.
This is crucial, especially for technical security. If you don't have a knowledge share of skillset and knowledge to the new generation of contributors, it might reach a point where it would be unsafe to leave the protocol running. If we lose the skills to autonomously keep the Protocol safe, that would not be a very good situation to be in. Because it's so complex and there is so much unique knowledge required to create secure smart contracts. Ultimately, this is an exercise in doing things practically. The theory around this is great but the only way that we can know whether we're in the right place is by having practical experience and by having done things and having run through all of these concepts for real, rather than just thinking about them.
AndyT: I think this is amazing, as most of the people do on this call. And I agree with you. I think it is about providing the tools in order for people to generate a new generation of both governance and technical contributors. It's a minor point, but I think it's long-term important; In terms of the language that we use to describe this, you can see it in this slide, and I know that this is a deck that was being used internally at the Foundation, there is still a distinction, at a linguistic level, between us and them(the Foundation and the community). The metaphor you would rather go with is the glass of sugar water.
The Foundation is syntactic sugar that makes stuff work at the moment, but ultimately the dissolution of the Foundation is precisely that it merges into the community so that this barrier between us and them is something that just falls away. The linguistic barrier between us and them, even though we're big on talking about the community, there still remains a big difference between core contributors and them(the community, which they serve.) So it's interesting in this kind of discussion to be careful about this distinction. It's only when speaking about the community and the Foundation as one thing that that begins to filter into people's experience.
Rune: I totally agree with your points. I can't see right now exactly where you're referring to, but I can imagine that it might have slipped through. That certainly isn't the intention. From my perspective, those of us who work for the Foundation, we have to make this distinction really clear: that's important for a lot of reasons. When you think about how the Foundation does a lot of external interactions with regulators and with media, we have to make this distinction clear. I think everyone in the foundation thinks ''we're just members of the community like everyone else.'' I hope that's clear to everyone. We will definitely be the first ones to try to work things that way. I'm surprised that it came out like this in this slide. I'm looking for somewhere defining ''us and them'' I want to go and edit it right now, but I can't see it.
Rich Brown: I kind of see that point, I know what the underlying question is. We have this fine line in the Foundation where we need to always remain cognizant that we're a community-driven organization. It's the will of the holders and people in the forums that these externalities are what are driving decision making and the vision and long-term success of the organization. We also need to be cognizant about having an outsized impact on the decision-making process and make sure there's a clear delineation between the will of the Foundation and the will of the people. Balancing all these dichotomies can very tricky sometimes, and trying to bring those back together at the end once the Foundation dissolves and once we act as, sort of, spores that go into the community and begin seeding the ecosystem from the community. It's a weird distinction to make. Something will keep in mind. It's a good point.
Rune: I completely agree with the points made. That's important feedback, that in the Foundation we will try to use the language correctly because that matters a lot of what the ultimate outcome is and the behavior that we will see in the community, so I think that's a good point.
Andy: Forgive me for being a grammar Nazi, I really just wanted to mention the concept of sugar water because it's going to be very very sweet when the Foundation dissolves.
Rune: Let's get into the meat of what we've basically already talked about quite a bit. This slide is about the first pillar of self-sustaining long-run Governance.
Technical security and technical maintenance of the Protocol is the number one thing, a real pressing issue. When you think about it in the long-run, it's just so incredibly critical that Maker governance has complete access to all the resources it needs in order to make sure that it can by itself guarantee the security of the Protocol. It would be totally disastrous if Maker governance had to rely on a single entity to keep the technology safe. Like the sword of Damocles. This is a critical reason why we need to get started with EPC and Domain Teams as soon as possible. So we can begin this knowledge share and begin reducing this single point of concentration of technical knowledge within the Foundation. And then there are risk teams. We know that quite well because that is a concept that has existed in the community for years at this point.
The technical side and the collateral onboarding side are the bread and butter of EPC and domain teams; the two basic things that are necessary so that the Protocol remains secure, and so that the community can autonomously scale exponentially without again relying on something like the Foundation.
EPC is a term used to describe the dynamics of the protocol governance electing and then paying individual contributors through the governance process, who then can operate in what would be a completely unique way of working. It will be this radically transparent and horizontal organization that will work in collaboration with the community on the forum and in the chat. I believe near-complete transparency around all kinds of work that they do. We won't be able to have full transparency for everything, for example, if a bug is found, there has to be some kind of response. You can't have literally 100% transparency, but I think it will be possible to achieve 99% transparency, which will be a very big change from right now as the Foundation needs to be really careful with the information that it shares.
Domain teams is a concept of organizing teams of domain specialists: a team or individual that has been recognized by governance as a specialist within a particular field and given special authority over a particular process. A good example is the Risk team having this special authority to propose risk constructs and all the risk parameters for collateral onboarding so that the community and the MKR holders can be certain that when there's a vote for some particular collateral type, it has gone through a sanity check by people who are known to be experts in those questions, and it's not a completely random proposal with no sanity checks whatsoever. There's a lot of overlap between EPCs and Domain teams.
To recap: EPC's are someone paid by the protocol, not necessarily given special access in a process. The community might decide to have an EPC that publishes research into a mechanism design and doesn't directly interact with the Protocol, like with governance on a day-to-day basis. They simply have a job that they do day-to-day. Domain teams, on the other hand, is like giving someone security clearance in a sense. The Risk team, for instance, isn't actually paid by the Protocol. But it has been given this security clearance, providing data and the ability to elect collateral that has been signed off by then. And, of course, you want to have a diversified team in the long run, of EPCs and domain teams, so we can spread the risk across many people.
Finally, the last thing to consider, even though technology, technical security, and the risk management and growth of the Protocol are the bread and butter of what governance absolutely need EPCs and domain teams for. There's also a lot of other really important operations that the Foundation is currently doing that potentially the community needs to consider that needs to be done through these tools. That could be, for example, decentralized marketing. Amazingly there's already a proposal in the community right now related to this, which I think is really cool. But maybe HR, to deal with the EPCs and the domain teams. Or legal teams to deal with things like real-world assets being included as collateral and so on. That's something that the community will need to consider and make decisions on as we start debating the implementation through Maker Improvement Proposals.
MIPs, the big theme of what's happening now. This is the step that we are currently at in the rollout of self-sustaining MakerDao. It's going to be a very important tool for the community to use. As we all know, Maker even today there are so many complex processes happening today, and that will increase significantly in the future when we will have a lot more collateral, domain teams, and EPCs everywhere doing a lot of different things. E.g., when we have synthetic assets, so there's more than one peg to manage. All of these new concepts mean there are a lot of complicated processes and they need to be very clear on how they work. So there's no ambiguity and confusion as this will very quickly become a big risk as the system increases in complexity. It's also important to increase accessibility, so everyone knows how to participate in a process or in creating or changing processes.
MIPs will need clear language. Even as you will see with the MIPs that the Foundation will come out and release on Monday, the goal is to have no jargon, but go in the opposite direction: try to have the processes documented in a way that tries to be as user-friendly as possible so we can be as inclusive as possible.
Maker Improvement Proposals are going to be incredibly important in the short-run because that is how we and the community agree on what will we put in place and how we will implement it so that the Foundation can safely begin dissolving.
This concept of the community having a complete overview of all the processes that it needs fully in place so that all bases are covered and all aspects of the Protocol are running as it should with enough oversight and risk management; That's what the Foundation came to call the ''Governance Paradigm.'' A complete solution to governance.
MIPs are going to be critical in that over time, the Governance Paradigm that the community implements in, let's say, a year from now, it's going to work. It will be good enough to actually run Governance, but it won't be good enough for the next 100 years. It needs to be able to adapt over time and evolve. Based on what we learn, such as the incident of the 12th of March when unexpected things happened and suddenly became clear that lots of things needed to be done by the community. As these events happen the community can use MIPs to, over time, iterate on the Governance Paradigm so it corresponds to the environment and what's needed from MakerDAO to perform optimally.
The MIPs framework is similar to other improvement proposal processes, like Ethereum Improvement Proposals, for example, but is different in an important way. Most other Improvement Frameworks are very technical in nature, they're for technical projects. That element is also apparent for Maker Improvement Proposals. But the core of what MIPs are about is governance. So it's really about defining the social layer, as much as it's about implementing technical changes to the Protocol.
Charles St. Louis: Before anyone asks any questions, I want to briefly give a summary of how all these work together.
In general, I like to think that the framework enables the community to continue to continuously affect changes and maintain the Maker Protocol in a standardized manner.
The MIPs themselves are the process to affect that change.
The EPCs are the people that both facilitate the MIPs process as well as create and propose that change.
The domain teams are a subset of the EPCs that are given special authority through governance to oversee the critical processes, mitigate any risks, and propose new developments to improve the Protocol overall.
Rune: I will give some examples: The collateral onboarding process implemented in MIPs. The MIPs will be how the community decides on what the process should look like. Then the Domain teams are a part of that process, they are being trusted by the community to provide the risk constructs.
The community still has complete control: it decides whether to accept or reject the risk construct. The important thing is that when the community is presented with the risk construct, there is this element of certainty that this comes from the domain team that has been authorized to do this kind of stuff. The process as a whole works to promote that the right collateral onboarding proposals, the right risk parameters, and so on are being set in the first place. So that we don't see a process that can easily be abused, but rather there is intelligence implementation that has checks and balances, considerations about things. Things like bandwidth becoming overwhelmed by noise, etc. all these types of risks that need to be considered in a completely decentralized process by governance.
Andy: For Rune or Charles, if these MIPs are based basically on EIPs, there are a number of teams that have some of the things 0x, Aragon and a number of others have done. I wonder if you have any thoughts about how Maker differs specifically or has improved upon other teams implementations of this. In particular, one of the problems with EIPs is potential politicization. I wonder if you thought about whether these will be political in any fashion, how to distinguish between technical and political contributions, whether you want to, and how this relates to other team's implementation of EIPs.
Rune: I'll let Charles talk. He's the expert.
Charles St. Charles: My general understanding, EIPs are purely based on technical implementation, and most or all of the other protocols, like BIPs or what they were originally based on PEPs (python enhancement proposals). They are all very technical based. The Python one kind of incorporates some process in terms of organization instructions, not necessarily on the political side. There are not many implementations out there that actually include the governance side of things or proposing these standardized processes. The main differentiator that we're mentioning on this slide at the bottom, we do incorporate the technical side of things, but the main focus is based on using these proposals to standardize governance processes for X amount of time until they can get swapped or improved upon over time.
In terms of EPCs or similar concepts of those, most of the DAOs that are currently operating have used the proposal/grant process and they haven't worked on any implementations where your hiring team or individual contributors or groups of contributors, for a time-based period or mandate type thing. That's also a differentiator that Maker will try to implement. Those are the two things that come to mind now. I have to think about it more, to be honest.
Rune: My comment is that anything can turn into politics. If Maker becomes a huge project that ends up being a significant force in global funding or something like that, it's unavoidable that there will be a lot of politics, and there will be a lot of what I call political proxy wars. You will have public characters fighting against each other over some trivial question, yet they still fight each other about it. It's about fighting for influence; it's about the characters trying to win over each other to gain more influence in the future. That's the kind of dynamics that are always going to happen.
The hope is that the processes that we put in place are resilient enough to be able to deal with that non-optimal behavior. Ultimately, the MKR holders are the final back-stop. That's really what ends up deciding everything. But even then there are checks and balances of that as well. I think that if the community is really good at bootstrapping the political climate, and the entire process of the entire environment of decentralized governance, it will naturally push people towards being constructive and seeking consensus and less towards these polarizing characters.
But it's always going to exist. In the EIPs, the governance aspect was not considered from the beginning. It became an issue later in time. With Maker, it's completely different. The Maker community has been about governance, as the defining concept from the very moment that the project began. I do expect that both the processes that we put in place and also the people that we put in place, will be in a much better place to handle the eventual political conflict and issues that will arise.
The third pillar. I have this little meme about the three pillars: I like to say we have EPCs & Domain Teams, the MIPs, and the Vote Delegates; We're covering the people (EPCs), the process (MIPs), and the politics (Vote Delegates).
As we're talking about ''politics,'' it's a part of what's going to happen. There's this decision-making process and this actual process of swaying opinion, making opposing arguments, and ultimately having to decide in one of them; this is where having vote delegates is absolutely crucial. In the Foundation, we believe it's crucial because:
Delegates are individuals that can vote on behalf of other MKR holders. The very basic advantage that this has, is that it allows smaller MKR holders, who actually have a lot of MKR and are the biggest voting block, to pool together their votes. That's what delegation is going to enable. I believe that it will create a way for small holders of MKR to still feel like they're more included in the process and can have an impact empowering the delegates that they agree with. It will also make it easier for people as it becomes more akin to traditional politics. You don't have to have to actually know anything about complicated risk theory or something like that. You just need to be able to decide which delegate you agree with, which people do you believe are the right people to vote on your behalf. And of course, you can still always participate directly, if that's what you want to do. So it's all about giving more options to people.
Beyond being great for small MKR holders to be able to pool their votes and have a bigger impact on governance, it's also going to generally increase voter turnout even for large MRK holders, even institutional MKR holders. This is something that we have learned at the Foundation over the years: for those who have very large amounts of MKR, one doesn't really want to be using those private keys that often. It feels quite risky using private keys of MKR that's worth millions of dollars. If you can change that process, that experience, (instead of doing it again and again) you only will have to do it once. Then you don't do anything else unless you see the delegate behaving against what you wanted. But if things are going normal, the fact that you only need to set the delegation once, and then sit back and just watch, it's going to make a lot of people that right now don't vote, even with significant amounts of MKR, to begin participating using delegation. So that's really going to have a great impact, I think.
Also a point I want to make that's not on the slide: the way delegation can be used is if you're a big holder with a lot MKR, that doesn't necessarily mean that then that's going to create super-delegates, with tons of MKR that they can vote with, so something even more concentrated than the whales in the current system. It's for everyone's benefit to have a diverse political ecosystem with a lot of different voices and a lot of different decision-makers. So you can diversify your vote across multiple delegates, for instance, and that's going to be a way to create a very vibrant ecosystem of delegates.
The other really big advantage and the big change that vote delegates entering the space will achieve: it will create this connection between the voting behavior and the public discussion that's happening. Governance will get to a healthier point where decisions that are made on-chain for voting represent the arguments and the consensus that's happening in the forum and the chat, for instance. Anyone can be a delegate. It's possible today to do delegation. It's inherently permission-less. It doesn't require something like a governance decision to actually enable it. But it will be very important that the governance community still defines some sort of standardized guidelines around vote delegation through MIPs because that is what will encourage people to start participating in this ecosystem. It's also a critical piece of the three pillars. It will be a check and balance on the EPCs and the key to fully harness the potential of MIPs, by creating new processes and amending current processes, and basically reacting to how it all plays out.
I was talking about this concept of ''Governance Paradigm'' earlier. It's a technical term that refers to a complete group of MIPs that cover every single risk, opportunity, and operational concept that the community needs to have fully formalized processes for; as well as a complete team of EPCs that can fully interact with these processes; and a fully healthy politically ecosystem of delegates, voters, of voter participation, whereas many people as possible feel included in the process. Ultimately, this can facilitate that the Protocol remains secure and can respond to emergent threats. With best practices when it comes to technical security and to handle scalable growth over time without the need for the Foundation or any third party. The Foundation is, right now, at the place where there's the most knowledge around what are all these risks and opportunities and all these different bases that need to be covered. The Foundation will draft and propose initial MIPs for all aspects of what in the Foundation we consider to be needed to achieve the first complete Governance Paradigm.
Ultimately it will be up to the community to decide. With input and will need the community to vote on them, and there will be even processes for the community to propose their own MIPs and alternative MIPs to what the Foundation is proposing. That is going to be critical. It needs to be a completely open process. Ultimately the Foundation plans to be able to draft a proposal by itself with everything necessary to put a complete Governance Paradigm in place. Everything needs to be covered. This is important for the Foundation because then the Foundation can ensure that is safe to follow the timeline and road map for the dissolution without impacting the safety of the project. And then the Foundation hopes it will be the core community members, the people on this call, for instance, and those who decide to become delegates, who spearhead actually using and understanding and controlling the power of the MIPs. Ultimately, the experience will start accumulating and can be then spread further and governance can, over time, be open more and more for greater levels of participation.
This slide is talking about the timing of all of this. I feel there's a lot of content, and those watching may feel it's moving really fast. So much complexity, so many moving parts. Basically, from the Foundation's perspective, it's about safety, about risk management. Right now, objectively, there are no formalized processes in place and no contributors paid by the Protocol that would make it safe for the Foundation to dissolve right? What if everyone from the Foundation got on the same bus and there was an accident or something? The so-called ''bus factor.''
There's a lot of risk in the Foundation being critical for the ecosystem. It's not just that processes or tools aren't in place. The community needs a lot of experience using these tools before it will be safe for them to be the final line of defense for everyone else. It's important to not let ''perfect be the enemy of the good'' while we put these tools in place. While what the Foundation is proposing won't be perfect, it will be possible to use it, initially, as a first attempt at putting a complete Governance Paradigm in place and trying it out in practice.
And then, from this initial Governance Paradigm, the good-enough one, the community can then, with full independence, with no constraints or deadlines or time issues, rewrite these tools with a practical sense of knowing what it is to work with them, based on practical experience.
The Foundation is pushing ahead already now with rolling out the first MIPs and moving forward and trying to get some initial steps taken towards this as soon as possible so we can start building this practical experience, taking it step-by-step. By the time the dissolution happens, the tools and processes will be so built out that no one will care because it will be irrelevant.
So that's it. Apologies for going 20 minutes overtime. I see we lost some people on the way but that's not unexpected, as we went overtime. Any last questions or comments?
Charles St. Louis: If there are people that would like to ask question later I will put the MIPs chat for rocketChat here.
Rich: Thanks, Rune! A tremendous amount of information to absorb. Is that deck going to be posted?
Rune: Good point. I think we will release these slides. We do also have a blog post and a forum post. The Foundation will release that tomorrow that will basically rehash this presentation. But there's no reason not to make them public.
Rich: Sounds great. Thanks, everyone for joining. As always, these calls are for the dissemination of information, to initiate debates, to further signals, but the actual work of governance happens in the Forums. Give this some thought and then join us at forum.makerdao.com to join in the actual process, these things that Rune gave us a tour of. Thanks a lot that was amazing.
Lucas Vogelsang: I'm curious if you have some MIPs that you're going to be prototyping this process with, or is the Foundation going to be pushing them?
Rune: Yes. Sorry for not making this more clear. First of all, this is something that has been underway for a long time. It's really well-timed, given the recent crash and the new surge of activity in governance. It's now very applicable. The core problem that the Foundation wanted to tackle, ultimately creating the MIPs concept, was collateral onboarding. This is a process that needs to be in place sooner rather than later so that the Community can use MCD as intended.
Rune: The foundation will release 13 MIPs divided into two MIPs sets; two sets that cover two distinct problems. The first will be the core Governance framework, the process to submit MIPs, and the monthly Governance cycles. A process for running Governance that has a greater level of throughput but also a greater level of checks and balances. More time to make sure that you're voting the right way. The second set is the collateral onboarding set. Some of you may be aware of a community created onboarding document. It's great especially since it was established by the community. We've taken that and turned it into a MIP. In order to simplify the ratification by the community for their own process they established. This is a process that needs to be in place sooner rather than later so that the community can benefit from MCD the way it was intended. Both of those things will be released on Monday.
Lucas Vogelsang: I was going to ask about that collateral onboarding that got published and got so little attention because of everything else that happened. Glad to hear that will happen and look forward to it.
Charles St. Louis: Tomorrow we'll post in the forum as a follow up for this call detailing the Foundation's vision. On Monday we're going to post the MIPs we've created to the forum and GitHub so people can look at them.
Rune: The ratification process and the timeline (for the decision-making process around the MIPs frameworks and feedback) everything that will be critical, will also be detailed tomorrow.
Rich: It seems like the questions may be trailing off. A reminder that this is the very first step in the long and complex road to implementation. Decentralization is not a simple thing, so we're once again at the forefront of this brave new world of DeFi, open-source governance, emergent process, and all the rest of it. Please contribute in the forums, help refine and get engaged with the process. As much as you possibly can. At this point, we have 4 minutes left of our regular schedule, I don't know if you, Cyrus, have something to say about Risk.
Cyrus; Not on my end, just state of the pegs(Vishesh's analysis.)
Dai is above peg. Kind of expected due to extreme illiquidity, and ETH<>DAi supply taking a huge hit.
The amount of Dai from ETH has not really recovered. It's come up $8 or 9 Million. They're aware they can get a passive yield supplying elsewhere. In the event something wonky happens with ETH again one can probably make an arbitrage profit.
For those reasons, and potential uncertainty in how quickly this would come back to a dollar. A lot of people are hesitant to sell Dai right now.
I think that's pretty natural due to shell shock around Dai that just happened. It would be foolish to expect it to immediately return to a dollar. Naturally, the air needs to be let out of this a bit and people need to feel comfortable with ETH so they can mint more Dai. When that confidence returns in the market you'll see the price of Dai come back down. As I mentioned during all this craziness, this graph snaps into a negative correlation when ETH is doing poorly and hasn't snapped out of that yet.
There was a slight bump on the 28th when ETH was doing better. The scale is smaller than the y-axis ranges we looked at two weeks ago. That small hump led into a small bump in what was going on with Dai.
It's still locked into that inverse pattern. Which tells me the peg is not yet ready to let go of its correlation to ETH. When that decoupling happens, which I'm reasonably confident it will at some point, that's when you'll see it return to a Dollar. We're not quite there yet and you can't rush that return to peg. It would be difficult.
ETH Dai positions more dramatically centered back into that 300% CR bucket. A lot of folks see this as a sweet spot.
Maybe there was a ''memeization'' of that $60-70 ETH price point for liquidations. People may have gravitated towards that price point.
As far as USDC after March 12th, USDC-Dai saw a huge increase and then dropped in utilization over the last few days. We'll see how that bucket evolves over time, given that it was an emergency measure.
Sai supply went down to approximately $14 Million.
CR: Collateralization Ratio
DSR: Dai Savings Rate
EPC: Elected Paid Contributor
ES: Emergency Shutdown
MCD: The Multi-Collateral Dai system
MIP: Maker Improvement Proposal
SCD: The Single-Collateral Dai system
Tim Black produced this summary.
David Utrobin produced this summary.
Igor Teslya produced this summary.
Juan Guillén produced this summary.
Everyone who spoke and presented on the call (listed in the headers.)