[Agenda/Discussion] Scientific Governance and Risk #141 - Thursday, May 13 17:00 UTC


The zoom waiting room will be on, and a password is set to: 748478, please ping us in chat if you aren’t let in from the waiting room. This Agenda will be updated over the following week leading up to the call as people make me aware they want segments.



Weekly Updates

I’d encourage those listed to try keep this to 5 minutes!



None so far.

Discussions and General Q&A

  • An anonymous Question Box is now available! Leave your question here and we’ll try to address it.

6 may? i do not understand :sweat_smile:


Episode 141: May 13, 2021


  • 00:00: Introduction
  • 01:02: Governance Update
  • 02:46: GovAlpha Core Unit update
  • 04:20: Forum at a Glance
  • 08:16: Protocol Engineering Team Update
  • 14:06: Oracles Team Update
  • 20:59: Risk Team Update
  • 23:40: Real World Finance Update
  • 25:14: Growth Core Unit Update
  • 29:45: Content Production Core Unit update
  • 35:54: Operational Support Team Update
  • 38:18: MIPs Update
  • 44:40: Submission Review
  • 46:32: Open Discussion




Agenda and Preamble



  • Hello everyone, and welcome to the MakerDAO Scientific Governance and Risk meeting number 141 taking place on Thursday, May 13th at 17:00 UTC. My name is LongForWisdom. I’m the Governance Facilitator at MakerDAO.
  • If you want to ask questions or have comments, please do speak up. Everyone here enjoys answering questions.

Weekly Updates




  • Last week’s executive passed. That will bring the Core Unit distributions for May to the ratified Core Units. It moves a bunch of ERC-20 assets to Liq 2.0 as well.


GovAlpha Core Unit Update


  • I’ve been working on our budget for the next quarter, which’s now in the forum.
  • @prose11 posted his facilitator proposal. I’m looking forward to him joining me as a facilitator of GovAlpha. It’ll be great if that passes. He’s been working with SourceCred and a couple of other groups around budgeting stuff and general coordination.
  • @elihu is working on forum modifications. He also moderates in the post of his calls us to a good faith engagement from all participants.
  • @blimpa is working on MIPs and the MIPs portal, doing MIPs’ fixes. Making some good changes and cleaning some things up. Finally, @charlesstlouis has been doing usual MIP-Editor responsibilities. They’ve been working on onboarding @blimpa as well. That’s an early stage of him taking the role of MIP-Editor.

Forum at a Glance

Payton Rose


Forum at a Glance - Forum Thread

Three-Point Summary

  • Lots of MIPs in the RFC, you can take a look and see everything that’s asking for comments before it moves on.
  • We have five core units receiving their monthly budgets on Monday. We’ll be distributing a little over 390,000 DAI.
  • There’s been plenty of MKR burning going. The lerp module makes it intermittent, having it on for some time and then off. At the same time, we raise it back to the expected line of burning about 25% of our incoming revenue. There are about 83 MKR tokens burned in the last 24h.



Signal Requests

  • There’s just one signal request still going on from @mrabino1. It concerns increasing the DSR. Interestingly, there are more options to choose from than just yes/no when voting.

Questions and comments

  • Christopher Mooney: I got one minor correction. The UI is live for Liquidations 2.0 and I don’t think it’s flash loan enabled. I believe you need to show up with the DAI, but that’s still great. Any Web3 user can come and bid on an auction.
    • LongForWisdom: Awesome, good to have that correction.

Protocol Engineering Team Update

Christopher Mooney


  • We posted the postmortem of the end bug in the forum, so if you guys haven’t read that yet, you can check it out. Some action items came out of that, and that’s the practice that we are going to continue to follow anytime we get a bug like that. It’s a good idea to iterate. The entire process is blameless. We’re just hoping that all teams involved can end up with a better outcome in the future.
  • We also posted the DssFest. The backstop keeper is updated for all of the standard collateral types. The keeper did manage to function and took an auction yesterday. It worked on decimals of 18. The demo keeper had a problem with nonstandard decimals like the WBTC auction that happened. I am going to try to debug that and figure that out. There were plenty of other keepers in the ecosystem to take those auctions. It was the most significant single liquidation that the Protocol has ever done: nearly 3 Million. Two keepers showed up. One of them was a capitalized keeper who already had half of the funds and did a take. The other one cycled the remainder on SushiSwap. Maybe it’s the other way around: SushiSwap happened first and then the other keeper. That sounds perfect. It’s a bunch of stuff that we spent a lot of time designing and hoping would happen, and it occurred how we wanted to.
  • We did a vote delegate review today. There’s an old contract from a few years ago that I had thrown together, and Sam recently modernized it for today’s standard. We are currently looking at a very light touch on vote delegation. This is just a vote proxy that does delegation and would allow us to do delegation with the chief. We are currently reviewing that.
  • For the weekly executive cycle, we’ve got the oracle LPs which Nick may talk more about this week. We are pushing Liq 2.0 back one week, and then we can push the actual LP tokens to liquidations 2.0. That bought us enough time to update the clipper and the demo auction keeper so that it can unwind those LP tokens. It also allows us to point at the new oracles when we do that spell. It’s the perfect place to interject the oracle update. It’s Oracles update this week, LPs next week, and we will do all the stable coins the week after that. We are probably going to do the Sushi joint adapter the week after that.

Oracles Team Update

Nik Kunkel


  • As Chris mentioned, we’re doing the redeploy of the LP oracle with the newly updated version that’s the post-audit, along with some gas optimizations that Kurt made. We are looking forward to that so it can save a little bit more money. That will be going out tomorrow. It’s going to cost a couple of thousands of dollars in ETH, around ten thousand dollars.
  • On the Core Unit side, I posted two of the three MIP sub proposals yesterday, and the last one will be posted right after this call. Happy to see that some of you have already been looking that over. We are looking forward to hearing your feedback for the remainder.
  • The other thing that we have to start looking at is that the Foundation is shutting down. Committed to that by recently sending over the remainder of the MKR in the developer’s multi-sig. The foundation is on a timer here. It has some money left. That money is to pay people salaries that need to continue until the shutdown and for the token rewards that people are still owned. However, variable costs, such as the Oracle costs, have currently been absorbed exclusively by the Foundation. If the cost for the gas doubles, then the cost for the Foundation to Oracles doubles as well. It is probably time, with the Backend Services team splitting out of the Foundation and the Foundation shutting down, that the DAO starts taking over that responsibility.
  • In two weeks, I will start posting on the forum about what that all looks like. What are we running here? Why is it built this way? What are the different costs, and how will we fund this and structure funding this in the DAO?. Are we going to look at the cost for the last 30 days, and that is the amount you get for the following month? What kind of guarantees does the Protocol want to have? Maybe we can have a multi-sig where the Protocol can claw back that funding at any time. How do we want to handle the case when some of those crazy days and the gas spikes to 2000 or something? It is Black Thursday levels. I’m sure that we spent like 200K in a day for Oracles on Black Thursday. Can we have some kind of emergency fund to which the Core Unit may not have access on its own? Still, it doesn’t need a ridiculous amount of facilitators to approve being able to pull any funding from that? How do we want to handle the accountability auditing of this? You want to make sure that no one is pulling out money on the side from this stuff, so we probably need a token flow kind of analysis where you can see the flow of funds. If you ever see funds that are not going to the Oracle transaction, you need to have an alert that signals a potential fraud. These are all questions that I have some ideas about. Still, I really want to get feedback to see how the Community feels more comfortable handling this. This will be the final step in fully decentralizing the Oracles, which will be completely controlled and funded by the Protocol.


  • Lucas: The main cost is gas, right? A good thing is it’s very easy to audit that team is spending this money on gas because it’s probably a known number of wallets. So I believe we should find a solution where monitoring gas costs is easy, and if it’s running low, then more ETH could be made available.
    • Nick: I’m not worried about the auditing being too complex. I really want there to be an auditing component from the Gecko because I don’t want to set this precedent where the DAO is handing big buckets of money and trusting people without the corresponding kind of transparency. We are doing a giant social experiment with our DAO here, and we want to do things right.

Risk Team Update

Primoz Kordez


  • We’re publishing the final UNI LP Liq 2.0 parameters. Our proposal is in the final internal review. It should be posted tomorrow morning. We are also finalizing SUSHI LP collateral evaluations. As Chris said, they could be onboarded right after the final Liq 2.0 collaterals are implemented in about two weeks.
  • We also updated our quarterly budget because the thing got changed a bit in our proposal. You can also get some information on the tools we’ve been working on in the last couple of weeks. I’m going to share two links here in the chat. First, we made a web dashboard that tracks risk metrics for each collateral type in Maker real-time. I’ll try to make another forum post on this topic soon, explaining the roadmap behind this product. Second, we started calling the Maker Risk web app.
  • Finally, as Chris mentioned, we had 3.2 million worth of BTC liquidated yesterday under the new Liquidation system. It was the biggest Liquidation so far. The outcome was promising. All of the debt got cleared as expected. The settlement time of auctions was between 40 and 45 minutes. This means that slippage, which is also partially a function of keepers profits that they made, was small, between 1% to 5%. That was good to see. The amounts that were bought, the so-called takes, were also very high nominal numbers. Keepers even used flash loan collateral type of auction buying, and I think SushiSwap was involved in an instant transaction.

Real-World Finance Team Update

Sébastien Derivaux


  • We have pushed two risk assessments in the forum. The first one is about trade finance by @williamr and the second one is revenue-based financing published by @Philinje. In addition, we want to publish the people company risk assessment as well, but that might be pushed to next week. This means you will have 3 or 4 credible asset criteria to evaluate in the following weeks. Currently, the expected date to be pushed on Mainnet is the second week of June.
  • We’re also working on the trust structure. Matthew published all the documents for the trust research. We are also working on the trust side with SolarX and Reino and making some progress there.
  • I published a new budget for RWF.

Growth Core Unit Update

Nadia Alvarez


  • As I mentioned last week, we have started to reach out to other networks because we see a big opportunity here to have DAI in other networks. For example, we are thinking about how to do a campaign with BitPay, which integrated DAI last week but without worrying about the gas fees. That is usually a problem when you are reaching out to retail. So we think that we should do something with these sidechains, L2 networks, or other blockchains. We are starting conversations with all of them and see what we can do with them.
  • We are also working on identifying different use cases for DAI. I posted a list of the use cases we are working on. We want to identify the value proposition of DAI or the Maker Protocol or the vaults in each case. But if you have any ideas or want to help us create this, let us know, and we will be happy to work with you.
  • I have an announcement to make: We have a new member of our team, and I’m super excited about this. You may be asking yourself why Mariano Conti is back on the call. He is joining us as a DeFi advisor. We thought we wanted to do more things with the DeFi projects, we want to work closer to all the other protocols, we want more ideas, and we think Mariano is the best for that.
    • Mariano Conti: I never left DeFi, and the past few months, I’ve been working with a lot of projects, a lot of protocols, extending the network. Seeing how the Smart Contracts team is really well managed with so many amazing people doesn’t make sense for me to go back to programming. Still, here I get to help out Maker differently, but I think in a very important way. I want to help out the BD team get DAI to as many places as possible, incorporating it from day one into so many of the new protocols and projects that have been coming out and will come out. I’m really excited about this!

Content Production Core Unit Update

Seth Goldfarb


  • If we haven’t met, I am Seth. I’m facilitating the Content Production Core Unit.
  • In the past weeks, we’ve contributed to the production of Maker relay episodes 43 and 44 in collaboration with Gov- Comms. In addition, we’ve met with the CPA and started the incorporation process and onboarding with Opolis.
  • We reached out to a couple of CPAs, and I wasn’t thrilled with the responses that we got from them, so if anybody knows any CPA based in the US, please help us out.
  • We’ve worked on creating a transparency dashboard on our notion page. We’re working on getting that synced up with the domain to soon be on content.makerdao.network. Along with that, we worked on outlining content strategies and OKRs. The summary of that is that in the short-term, we want to focus on understanding the different journeys stakeholders take when they first learn about MakerDao and then become more involved. We want to optimize our digital properties to move that traffic along and educate people and get them the answers they need to make decisions that help us. Part of that strategy would be hosting some webinars. They’re going to be bi-weekly. One of them will focus on giving integration partners a platform so that we can highlight what they are doing and give people who are interested in building with DAI a chance to learn more about what the process looks like. The long-term goal is to create a MakerDao brand. If you have a strong brand, people trust you, and you have customer loyalty. Branding is tricky because it can be difficult to measure the strength of your brand, but we are going to do what we can to find some ways to bring transparency about that. Please go read that and give us feedback.
  • We also met SES to start coordinating about managing and updating the community portal. We want to figure out how to organize the content of the community portal. It is on a good site, and it does better SEO-wise than the content in the domain itself.


  • Seth: Brand is ultimately an expression to say why you do what you do. When you are talking to potential partners, it’s easier for them to relate to the intentions behind what you’re doing. Our thoughts on how to approach that is to focus on giving people opportunities to express the why. Having organic conversations instead of forcing people to say one thing.
    • Wouter: We have a lot of documentation lying around different places. Much of the technical documentation and also some in the content and community portal. At one point, we’d love to sit with you guys and get all the documents into the right places so that onboarding members to the ecosystem can easily find the information.

Operational Support Update

Juan Guillén


  • It was an intense week on several fronts for Core Units. We will have several calls coming up to present the Core Units. One of them is Marcomms from Kathleen Chu, the other one is Oracles with Nick Kunkel. In addition, we will have Collateral Onboarding with Monkey Irish, and I’ll be happy to have Prose as the new facilitator for Governance Alpha. Stay tuned for that.
  • Regarding the Core Unit informal submission, I’m not sure if the one in the strategic Marcomms goes to RFC automatically or stays until the end of the cycle. Still, there are new Core Units in RFC. We have Oracles, as Nick mentioned. We have the Collateral Onboarding Core Unit. And we have the Strategic Happiness Core Unit by Mr. Bourbon and Prose as the Gov Alpha facilitator.
  • There are new budgets for Risk, Alpha, and SES that are quite interesting to read. Regarding interesting posts, we have the Help Identifying Risks and Opportunities published by SES. If you see any risks or opportunities that MakerDAO should be pursuing, please help us identify them to do something about them. There are two posts regarding the Maker Compensation Guidelines. One is the Pre-MIP discussion and MIP 53 by PlanetX and the other one is an alternative for the Maker compensation plan by SES

MIPs Update

David Utrobin


Submission Review



  • I covered this already in the Governance update section.
  • We saw four of the six inclusion polls passed. The ones that passed were MIP50, the Direct Deposit Module, the SES Core Unit MIP set including budget, mandate, facilitator, the MIP0 clarity amendments, and MIP51. To clarify, the MIP51 on the Governance cycle will only come into effect, assuming the rest of this cycle is successful. It hopefully will be, and I don’t have many reasons to expect it won’t be, but technically it’s not locked in until that date. Same for the other proposals. The two polls that failed were the Strategic Marcomms Core Unit and the MIP49 Stacking Reward. As I mentioned before, those will either go back to RFC or be dropped, depending on what the authors decide.

Open Discussion


  • SamM: I’d like to talk about MIP49, which didn’t pass. Here’s an exit poll that Payton set up. We’re trying to figure out why people were unsatisfied with the MIP. I heard some concerns around PAX efficiency, US security laws, and locking periods. If you are a “NO” voter, please explain yourself to address those concerns. However, I would still like to proceed with the MIP as we have a prisoner’s dilemma. MKR holders are not personally and financially incentivized to lock their MKR into Governance. Delegation may mitigate this, but in the long-term, it still requires solving.
    • Nik Kunkel: As someone who has their MKR on AAVE, the only reason it is rational to do that is that there’s a spread between what it costs to borrow money and the yield you can get with that money. The only reason that spread exists is that people really like governance shitcoins; they place a lot of value on them. That is not sustainable. Governance shitcoins are still shitcoins. Right now, we are in a market cycle where it is very popular to value Governance shitcoins, but it’s not sustainable. As soon as the yield disappears, there won’t be a reason to keep your MKR on AAVE, and the problem disappears. That makes it a short-term problem. I never understood with your proposal that it doesn’t get anyone to vote more; it doesn’t secure the hat; it just tries to get MKR off AAVE. With delegation, you actually secure the hat. People won’t delegate to those who don’t end up voting. So, with delegation, you do get more MKR on the hat; you do increase the system’s security rather than worry about how you decrease the pointiness of the stick that is coming from AAVE.
    • LongForWisdom: Nik, your first statement is that it’s a short-term problem. You’re correct in that the yield from AAVE is short-term. The issue is there’s always going to be an opportunity cost for capital, e.g., when you lock up capital in governance in Maker, you can’t use it for something else. It stops you from borrowing against it, taking credit for it, or potentially investing in other things. In this way, it’s not just the yield, there’s also the opportunity cost, and I don’t think that problem goes away in the future.
    • SamM: That’s basically my view as well.
  • Nik Kunkel: I wonder how many people who have their MKR on AAVE are using it to pocket the spread off of the difference to borrowing dollars and farming versus doing what you’re suggesting: borrowing and using it for leverage.
    • LongForWisdom: I suspect it’s mostly towards yield at the moment, but it’s not always going to be true. The other thing to consider is that Governance is an opportunity cost in time and attention for those who want to do things actively. So they are paying a cost to doing that.
    • SamM: People who are loaning their MKR on AAVE for whatever reason are effectively socializing the cost of security to the rest of the holders. The idea behind MIP49 is to correct that sort of imbalance. You can loan out your MKR on AAVE, and if the opportunities dry up, we turn it off. But I suspect they’ll continue in some form, and then I’d like to have a tool to combat that.
  • Nik Kunkel: Can we convince AAVE to stop the borrowing of MKR?
    • SamM: If we do have this antagonistic approach, I think another competitor will pop up.
    • Nik Kunkel: I’ve heard you bring that argument before, but I doubt there will be another AAVE that just pops up out of nowhere. Compound hates us; they’re not listing MKR.
    • Brian McMichael: I’m not sure what the difference is between MKR on AAVE and MKR just sitting idle in a wallet.
    • Kurt Barry: MKR on AAVE can be borrowed and used to attack the system, whereas MKR in a wallet can’t. I think that’s the root of the concern.
    • Nik Kunkel: It’s like saying that flat flash loans are bad because they let everyone do this one thing. There are already people who have enough MKR to make a Governance attack right now to Brian’s point. Whether the attack is broadly possible by many people versus some people, still the attack is possible because we can’t secure the hat.
    • SamM: There’s a big difference between you owning the MKR and you borrowing the MKR. You have exposure to MKR, the asset if you own it, and you don’t have exposure to it if you borrow it.
    • Nik Kunkel: There are other ways to do that without having to sell into liquidity, e.g., you can open up a short to hedge.
    • SamM: I don’t think it’s the same thing as you have to maintain the MKR for the entire duration of the vote.
    • LongForWisdom: That’s kind of a separate problem which we should address at some point, with time locks or some other method.
    • Kurt Barry: You have to remember here that it’s always possible to build permissionless derivatives for stake tokens. It’s what happened to ETH 2.0, which was supposed to be proof of stake and not delegated proof of stake. Now they’re staking derivatives that give instant liquidity on something that was supposed to be locked. There is some discount for that, but it’s not huge. The question is, do we really solve the problem long-term, or are we just solving it for a couple of years until people decide to build locked MKR derivatives that are liquid and get you 90% of what it would be if we didn’t have the rewards and locking?
    • SamM: I addressed that in the post. The amount of effort required to make a liquid derivative and adopted by AAVE is a much higher effort than what it would take for us to blacklist that token from the rewards.
  • Kurt Barry: How does that blacklisting process work exactly? I would need to think through the game theory a bit more before I totally buy that that solves the problem. What if people start building Tornado Cash mixers-type things. Obviously, if people would have to go that far, it would reduce those really willing to do it. It might still be valuable, but I need to think more about it.
    • LongForWisdom: It’s definitely not trivial to map out the impact. Personally, I don’t think it’s beneficial.
    • Nik Kunkel: Greg mentioned that it seemed there were large MKR holders who might be interested in delegating their MKR.
    • Greg DiPrisco: When talking to the large voters, I found they will delegate to people who participate when given the option. This will account for a significant portion of the MKR.
    • SamM: It’s a great solution for getting voting up and getting more MKR on the hat, but I think it’s a separate issue.
    • Nik Kunkel: So what’s the issue you’re trying to solve here? If you can secure the Protocol, nothing else matters.
    • SamM: Fundamentally, it’s the prisoner’s dilemma. Individuals are encouraged to defect from securing the Protocol by moving MKR somewhere else.
    • Nik Kunkel: But if you delegate, the Protocol is secure.
    • SamM: Yes, this could work in the short-term for a while. I’m concerned about the long-term.
    • LongForWisdom: As I said before, people are not always rational. Delegation may work forever, and that would be fine…
    • Nik Kunkel: Are we dealing with imaginary problems? Let’s deal with the problems in front of us. There won’t be a problem magically showing up from one week to the next that we can’t see.
    • SamM: I agree with that. I think we should give the delegation a shot. I wanted to get ahead of this, but I’m ok with seeing how things go.
    • LongForWisdom: As you say, maybe not now, but I would expect those who are actively governing the Protocol to implement this at some point. They are paying this cost on behalf of everyone now. So it’s in their best interest to implement something, and they have all the voting power as well.
    • Brian McMichael: In the future, we can implement a solution with retroactive airdrops that would scan the chain for voting participants and build a Merkle distributor. That way, it’s cheap for us, and everyone can just claim rewards. It’s a bit manual, but there are alternative solutions available too.
    • Payton Rose: What scares me about those solutions is they’re not tied to how well the Protocol is doing. One of the things I liked about this was that staking rewards only got when we were otherwise burning MKR. So from a Governance perspective, I thought it was important to establish that rewarding was directly tied to how well the Protocol is doing and not to people deciding to vote to give themselves more capital.
    • Brian McMichael: Within a retroactive airdrop, you would have a history to know if they voted well or not.
    • Payton Rose: But then you could get up it more and more because it’s not tied to performance.
    • David Utrobin: Can’t you tie the value of the airdrop to the performance?
    • LongForWisdom: The difficult part is judging which votes are positive.
    • Brian McMichael: You don’t want to pick winners. You don’t want to punish people for voting the wrong way.
    • Christopher Mooney: They punish themselves because they’re not getting a big airdrop if they voted the wrong way.
    • Brian McMichael: That’s a whole new game. Trying to predict what the majority is going to choose is a horrible way to do democracy. So anyway, I’m not filling out a MIP for retroactive airdrops.
    • LongForWisdom: That’s clear. Let’s move to some other topics.
Core Unit Onboarding Process
  • Frank Cruz: Since I was one pushing for the MarComms Core Unit, my campaign didn’t go so well but if you get to see this video, stay positive, come back, bounce, listen to the Community and make a presentation with Juan’s “TV show” to explain what exactly you are going to do. We’ll run another campaign and hopefully get it passed next time.
    • Juan Guillén: We are already in talks to organize the “TV show.” We want to make sure that everyone can provide feedback and ask the questions they want to.
    • Christopher Mooney: We need to come up with a better process for this because many people were concerned with elements of their proposal, and that’s fine, but it’s nearly impossible for a group like that to negotiate with the DAO without everyone’s emotions getting enraged. When we - Protocol Engineering - went through this with our proposal, it was a distraction and bordering on the edge of a counterproductive process, not to mention what would’ve happened if it hadn’t passed. If a proposal doesn’t pass, we need a method that doesn’t burn a potential team to the ground. Maybe a more in-person or video-oriented approach would be better. I’m concerned that this will happen with other teams, teams that we need or want. We should negotiate on better terms with them, including Protocol Engineering or any other teams.
    • David Utrobin: One idea that I had for a better methodology before a Core Unit goes through the whole MIP ratification process was to use the weekly cycle to run some polls to get some sentiment and feedback from MKR holders earlier on. This would be very powerful.
  • LongForWisdom: Wouter, can you talk about how the incubator can make this process better?
    • Wouter: The Governance process takes a lot of time and requires much commitment to go through. You essentially need three months to get through the process: one month crafting the proposal, one month of RFC, and one month of Formal Submission. Only then do you learn whether you are out of the job or your proposal has passed, and you can start working on the thing that you’ve been committed to for three months. It works at the moment but is very intense. It works because we have many people involved in the DAO through the Foundation, and they have built some confidence. For external teams trying to participate in the Maker economy, it’s just not reasonable. Hopefully, the incubator pattern applied by many Core Units is important because people can start getting paid, get to know the team, get better guidance so that their proposal is in line with the culture and the expectations of the Community. Because it’s typically the people who haven’t been directly engaging with the Community that has trouble bringing the proposal in a way that makes for a strong argument to the audience. It also means that the business model would make sense because the incubator would support those teams to build a business model that makes sense in the DAO in an environment known by the supporting crew. Finally, the reputation of the incubator will mean that projects are unlikely to pass-fail fast. The incubator’s reputation can really help create more certainty that a team is set up for success and that the vote will pass. There can be enough signals throughout the process so that the vote becomes almost a formality. This is why incubators are absolutely critical for the growth and the success of the Maker ecosystem.
Diversification of Core Unit holdings
  • David Utrobin: There was a question on Core Units diversifying their treasuries. If the Protocol gives them DAI upfront, Protocol Engineering mentioned turning some of it into USDC or potentially holding ETH. I was curious about people’s thoughts on that.
    • LongForWisdom: That’s not something I’d want to manage for GovAlpha in addition to everything else we do.
    • SamM: To clarify, the Protocol Engineering team wants to turn the Emergency Fund partially into USDC in the event of a protocol failure. I don’t want to give a wrong idea to the Community.
    • David Utrobin: My bad for the misunderstanding!
    • Brian McMichael: In an Emergency Shutdown, DAI essentially becomes ETH in USDC based on relative proportions.
    • Kurt Barry: My suggestion was that maybe the DAO as a whole would hold and stake ETH, or should have some financial planning around that, so we get income denominated in ETH. This is great because gas costs are very variable. So the DAO would get resources to fund on-chain activities of various Core Units. Right now, we let everything sit in the Surplus Buffer. Still, it’s worth considering different capital structures to ensure smooth operating ability through various market conditions.
    • Brian McMichael: The other reason why we might want to diversify is that we spent the last year fighting DAI above peg, so instead of having it sit on balance sheets, we might want to release it into the world.
    • David Utrobin: So it makes sense from a Protocol security perspective so that we are not too reliant on DAI. On the other side, for Core Units to hold their budget in alternative assets, it’s a whole different story, and nobody is considering that too seriously, right?
    • Christopher Mooney: Yes, that’s correct. The whole point of the emergency funds is for teams to keep operating after a black swan effect. If DAI goes to zero, or fails in some way, or becomes highly volatile, we can’t guarantee any kind of cleanup or handling. It’s probably supercritical for Operations, Protocol Engineering, Oracles. I’ll probably need to think about this.
    • Brian McMichael: We can consider a situation where an emergency shutdown is triggered, DAI effectively becomes ETH, and then market FUD drops the ETH price, making us unable to fund anyone.
    • Kurt Barry: Although I’ll say that given one of our other common black swan concerns is regulatory action. If all of a sudden the order comes down, all Maker Protocol teams are blacklisted, and USDC shuts off those emergency funds. It would be nice if there were another decentralized stablecoin in that scenario. Someone was suggesting RAI.
    • Christopher Mooney: RAI doesn’t cut it because it would probably suffer from the same black swan bug in the Marker Protocol.
    • Nik Kunkel: It’s also pegged to ETH.
    • Kurt Barry: Maybe something like Curve LP tokens would be a better hedge. You’re still partially exposed to DAI, but that’s fine if it doesn’t fail completely.
  • Christopher Mooney: For anyone listening to this, we have a lot of confidence in the teams, in the Protocol, and its safety. This is just making sure the airplane stays in the air by having treasury backup systems.
    • Brian McMichael: Yes. We spend a lot of time thinking about all of the things that can go wrong. You don’t have to, but sometimes they make it into public discourse.
    • LongForWisdom: I don’t think it’s about confidence. If everything explodes, then at least you will have people who are going to try to clean up and make sure you get some of what you are ordering. Without that guarantee, everything explodes, and then everyone is on the road.
      Kurt Barry: We currently have the luxury of worrying about these crazy black swan events rather than dealing with immediate emergencies. Things are going well enough that we can spend our time thinking about the worst-case scenarios.
    • Nadia: I understand what you’re saying, but how would we look if someone saw our smart contracts team using USDC as an emergency fund just if DAI fails? It’s complicated from a business point of view when trying to convince someone to integrate the Maker Protocol.
    • Derek: We’ve been looking at it from a risk perspective, so we wouldn’t put all the funds in one particular collateral type. There would be a balance, but we’re yet to assess what that balance would look like. Is it LP tokens, a basket of stablecoins, an index? I’m almost certain that DAI will play a role in that. We’re talking about a fund here that doesn’t get used for monthly payments; it’s something that will hopefully never be touched. If there is, we have that stability there through having some index of funds or a broad distribution of collateral types. I don’t think anyone would look at this as not having confidence in the product that we’re building. It’s a long-term perspective for stability in just-in-case scenarios to cover off that risk.
    • Juan: It’s also a very small percentage.
      Wouter: The bigger issue here is that people are seeing things they’re not used to seeing with traditional companies because all of this is in the open. If a bank hedges against its own stock, you won’t read about it. We discuss it in these calls because we are an open community. It can suddenly become a headline in Coindesk. It’s a tricky thing in marketing and PR, but I think that the right way to deal with it is to explain it. Maybe separate the emergency discussions from the more accessible discussions and clarify that this is standard operations. You should be worried if we weren’t be doing that. It would be a bad reflex to stop building fire exits because it reminds people that it could be a fire. It’s definitely a challenge. We’ve seen this in the past, where a purely procedural safety thing was completely taken out of context and seen as a weakness instead of proper and responsible risk management.
  • Frank Cruz: Shoutout to Greg for his move and all of the assets he’ll bring into the Protocol.
    • Greg DiPrisco: I started a company that intends to bring institutional borrowers to the Protocol. It’s been exciting to see the first crop of borrowers get in, but this gives us a path to expand. I’ll do to differentiate myself by focusing on the safety of the Protocol and making sure the structures and counterparties are top-tier to make it easy for MKR holders to approve these assets. I’ll also be asking for some big DC, so keep your eyes open.

Common Abbreviated Terms

DC: Debt Ceiling

ES: Emergency Shutdown

SF: Stability Fee

DSR: Dai Savings Rate

MIP: Maker Improvement Proposal

OSM: Oracle Security Module

RWA: Real-World Asset

RWF: Real-World Finance

SC: Smart Contracts

Liq: Liquidations


  • Artem Gordon produced this summary.
  • Gala Guillén produced this summary.
  • Sai Teja produced this summary.
  • Sonya Olechnowicz produced this summary.
  • Everyone who spoke and presented on the call, listed in the headers.

G&R #141 Snippet

Domain team updates, Collateral Onboarding, active discussions and more. All the updates from MakerDAO Governance and Risk Call #141 in this snippet

Team Updates


Protocol Engineering

  • Posted the postmortem for the End.cage bug in the forum
  • Posted DssVest
  • Updated Backstop Keeper for all the standard collateral types
  • Vote Delegate Review today to bring up to date and enable Vote Delegation
  • Pushing Liquidations 2.0 for Uni-LP back a week
    • Will have new Oracle updates to go with it for Uni-LPs


  • Redeploy of Uni-LP Oracles to the post-audit update with gas optimization
  • Posted (most of) the MIP Subproposals for Oracles Core Unit
  • Foundation is currently paying for the Oracle Costs, DAO should be paying for this expense so look for cost breakdown coming to the forum in the next couple weeks
  • Will be seeking feedback about monitoring of DAO Oracle expenses

Real World Finance


Growth Core Unit

  • Weekly Update
  • Welcome back Mariano!!!:tada::tada::tada:
    • Joining Growth Core Unit as a DeFi advisor

Content Production

Operational Support


  • Governance Cicle before MIP51: New Governance Cycle
  • New Governance Cycle with proposed changes with MIP51:
  • New Governance Cycle details:

Other Presentations and Updates


Staking Rewards

  • MIP49: Staking Rewards didn’t pass, please check out and vote in an Exit Poll to gather community feedback on this MIP.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.