---
tags: G&R
---

# Episode #191: May 19th, 2022

## Agenda

- [00:00](https://youtu.be/sSKWsFlNBz4): Introduction
- [03:01](https://youtu.be/sSKWsFlNBz4?t=181): Votes and Polls
- [05:21](https://youtu.be/sSKWsFlNBz4?t=321): MIPs Update
- [10:07](https://youtu.be/sSKWsFlNBz4?t=607): Forum at a Glance
- [16:50](https://youtu.be/sSKWsFlNBz4?t=1010): Discussion: Revisiting D3M: Risk & Meta
- [01:06:23](https://youtu.be/sSKWsFlNBz4?t=3983): Open Discussion
- [1:12:15](https://youtu.be/sSKWsFlNBz4?t=4335): Conclusion

## Video

[Link](https://youtu.be/sSKWsFlNBz4)

## Introduction

### Agenda and Preamble

#### Payton Rose

[00:00](https://youtu.be/sSKWsFlNBz4)

- Hi, everyone. Welcome to episode #191 of the Governance & Risk Core Unit. My name is Payton, and I go by Prose11 online. I am one of the governance facilitators at MakerDAO. I am joined by a bunch of awesome people who both work for and are generally interested in the Maker protocol. This is our weekly call where we discuss the governance and risk states of the protocol.
- This meeting is being recorded. Let us try not to speak over one another. There are some great tools on Zoom you can use. If there is something you would like to add, to speak next to the conversation, you can consider raising your hand. That should be under the reactions section of your zoom dashboard at the bottom. Feel free to drop something in the chat. I am more than happy to read out loud for you. This is an open meeting. We encourage your questions, your comments, and your feedback. Please do not be shy and consider getting involved in our conversations.
- Before we move on to things, we are trying out a new meeting time next week for the last meeting of the month. The meetings will be a bit later. Next week, this call will be at 2100 UTC, rather than its regular time at 1700 UTC. More on that later in the forum.
- Our Agenda Today:
- We will start with our governance roundup that includes the votes, what is going on with our Maker improvement proposals, and the latest from the forum.
- There are no initiative updates today.
- We have a cool discussion topic centering around D3Ms, their risks, and what they mean for the protocol. For those that are unfamiliar, D3M stands for Dai Direct Deposit Module. That is our way of injecting Dai to different lending protocols or similar protocols or other teams using something where we can have Dai and inject it directly for lending.

## General Updates

### Votes

#### Payton Rose

[3:01](https://youtu.be/sSKWsFlNBz4?t=181)

*Polls:*
- 2 Concluded Weekly Polls - **PASSED**
- Raise the ESM Minimum Threshold
- Adjust the lid Parameter on the Rate Limited Flapper
- 2 Concluded Greenlight Polls
- ATDC (ATD Combustors)
- Passed - 47,231 MKR to MKR 40,663
- IPCL (India Power Green Bonds)
- Failed - 49,104 to 38,970 MKR
- 1 Active Greenlight (Voting ends May 30th)
- FEI (FeiUSD)
- 5 Ongoing Ratification Polls - To be covered in MIPs segment

*Executive:*
- Yesterday's Executive: Foundational L2 Work, Authorize New Flash Mint Module, MKR Vesting - **PASSED, Pending Execution**
- Next Wednesday's Executive
- Raise ESM Threshold - 150,000 MKR
- Adjust "lid" Parameter - 30,000 DAI
- MKR Transfer - DUX, SAS

### MIPs

#### Pablo

[05:21](https://youtu.be/sSKWsFlNBz4?t=321)















### Forum at a Glance

#### Artem Gordon

[10:07](https://youtu.be/sSKWsFlNBz4?t=607)

Post: [Forum at a Glance: May 12th - 18th, 2022](https://forum.makerdao.com/t/forum-at-a-glance-may-12-18-2022/15280)

Video: [Forum at a Glance](https://youtu.be/sSKWsFlNBz4?t=598)

- _Announcements_:

- [MakerDAO.com performance overview](https://youtu.be/sSKWsFlNBz4?t=607)
- [Governance House Delegate Platform/Blockchain@Columbia Delegate Platform/London Business School Delegate Platform](https://youtu.be/sSKWsFlNBz4?t=660)

- _Discussions_:

- [MakerDeFi DAO Governance Report: A review of major DeFi DAO governance systems in the Ethereum ecosystem](https://youtu.be/sSKWsFlNBz4?t=698)
- [The MKR holder Confessional](https://youtu.be/sSKWsFlNBz4?t=738)

- _Active Signal Requests_:

- [Request Return of MKR Tokens Inadvertantly Sent to Governance Address](https://youtu.be/sSKWsFlNBz4?t=766)
- [[Signal Request]Offboard UNI, UNIV2DAIETH, UNIV2WBTCETH, UNIV2UNIETH, and UNIV2WBTCDAI](https://youtu.be/sSKWsFlNBz4?t=792)
- [[Signal Request]Increase the ESM Minimum Threshold](https://youtu.be/sSKWsFlNBz4?t=842)
- [[Signal Request]Deploy the balance sheet in ETH](https://youtu.be/sSKWsFlNBz4?t=892)
- [[Signal Request]Launch Maker Teleport with 1 basis point fee](https://youtu.be/sSKWsFlNBz4?t=917)
- [[Signal Request]Maker Accessing Mortgage Loans Through Bacon Protocol](https://youtu.be/sSKWsFlNBz4?t=930)
- [[Signal Request]Antalpha Institutional Vault](https://youtu.be/sSKWsFlNBz4?t=949)

## Discussion

### Revisiting D3M Risk & Meta

#### Thomas Flitter

[16:50](https://youtu.be/sSKWsFlNBz4?t=1010)



- I am Thomas Flitter, engagement lead for the GovComms CU. Today, we have a great topic, revisiting D3M.
- The Direct Deposit Module interfaces with third-party lending protocols to enforce a maximum variable borrow rate for selected assets. Maker governance can pick a target variable borrow rate, and the module will automatically deposit or remove liquidity to ensure that the target rate is hit.
- We have got many questions that we are putting out there for Risk and PE to talk about. I want to hand that off to them to go through these and have a great open discussion with the folks on the call.
- First question, what is D3M? The second question is, what use cases apply?
- Primoz Kordez: The D3M is cool because it is easy to scale by supply. If you imagine now that you want to scale DAI supply through vaults, you first need to identify collateral. The collateral needs to be liquid. You need to identify if there is any demand behind borrowing. There are oracle costs. It would be best if you determined the interest rate. It is not a simple task, to be honest. We failed at many points. But with D3M, that is straightforward. You select the lending market or whatever market has pulled Dai, and you set some parameters. In Aave’s D3M or Compound, you select the target rate. It is straightforward and faster. To some degree, it is also more controllable.
- And that is the second advantage; you can control the supply, which becomes important when you need to contract it. If PSM unwinds and we need to contract the supply to defend the peg, the D3Ms are probably the best tool to do that fast. You pull Dai out. That is useful.
- Also, when you do D3Ms with landing markets, you start offering something that Maker does not offer, which is cross-collateralization. We get benefits from that. Some people are not sticking to Maker because they cannot pull collateral and do cross-collateralization. They are regular users of Aave and Compound, therefore. You can have benefits through D3M to that. There is also the competitive angle that you can somehow control. Because you can control the rates to some degree, currently, of Dai Aave, you can even address this.
- Christopher Mooney: From the technical perspective, I will add maybe an analogy, which is that the vaults that we have in the system, which are like pseudo vaults under the hood. But effectively, the D3M is its sort of Vault engine. The vault engine is our way of generating DAI. You have got to entice vault users to put stuff in, and we have carefully scoped the risks around our existing Vault engine and its direct to consumer. That is the existing mechanism for generating Dai. We have shimmed in a PSM that it is another generation mechanism. And under the hood, it uses the same vault mechanism. This is yet another vault mechanism. I hope that gives you a good mental place to hang on to this to understand what the D3M is. If we had removed all of our permissionless direct-to-consumer vaults, you could almost imagine that the D3M would still generate Dai supply the same way the PSM would still function to generate Dai supply. I do not know if that helps give any additional concepts or gives everybody a good mental model.
- What are its use cases? I nailed a bunch. Right now, it is primarily a Dai generation tool to satiate insane amounts of Dai demand. Maker was looking for ways to try and add a lot more Dai onto the market. The PSM helped us with that over-peg pressure to generate Dai, but it did it at the expense of ingesting a bunch of centralized stablecoins. The D3M was an answer to generating Dai supply when there was a ton of Dai demand outside the normal vaults engine. I am being very pedantic about precisely what the D3M is and the problems that it is solving.
- Brian McMichael: What is a D3M? I would think of it more like a push model for Dai than a pull model. We currently have our traditional vaults. We require someone to come to us and affirmatively generate Dai. The D3M is where we reach out to other protocols and generate Dai to satisfy demand. There is demand, and the most obvious use case is Aave. We know there is demand there because there is a high-interest rate. What we do with the existing D3M is we will set a target interest rate, which has been lower than the actual interest rate since we have been using it. When the D3M sees that the interest at Aave is higher than our target, it can generate Dai to drive down that rate at Aave, which throws Dai supply on the market and earns us a little bit of yield. This is risky at an SC and community level because we expose ourselves to these external protocols, SC issues, and multisig issues. For example, Aave is exposed to Chainlink, but we now have external Oracle risk. We do not know all the time what the composition or ability to control these protocols of multisigs is. It is a bit riskier.
- Additionally, the PE team building these things does not have expertise in these external protocols. So there will be some gotchas in the way we implement these. We are trying to mitigate those by having external protocol developers from these other protocols look at this. But for example, we did not even notice the Chainlink exposure in Aave until recently. The Surplus Buffer theoretically can limit us. For example, if one of these tokens, like UST, is involved in a protocol and takes down that protocol, the Surplus Buffer should limit our losses to that amount. To answer how Maker voters should think about this? It would help if you thought that it was a highly effective tool, but it is a bit riskier from a technical and social perspective. And I have mentioned some of the risk scenarios. If there are any questions or additions from the team, that would be helpful.

[26:43](https://youtu.be/sSKWsFlNBz4?t=1603)

- David Utrobin: How did Aave D3M behave when UST blew up?
- Niklas Kunkel: They do not allow using UST as collateral. They only let people borrow UST.

[27:12](https://youtu.be/sSKWsFlNBz4?t=1632)

- Robert: I appreciate the discussion on the features of the D3M. I am struggling with being the recipient of collateral applications, where what tends to happen is that we want to onboard X as a D3M. Unfortunately, that does not mean a lot. I need to go back and understand the business case for this particular application as an example. I have heard one example as it relates to rate stabilization. Great. That sounds like it is one very specific use. This is generating Dai. I get that. But when I look at Aave or Compound, that is one utilization of the D3M or the one currently being developed.
- On the other side, we have other projects proposed, for example, with TruFi or Maple Finance, which are slightly different. The objective of utilizing the technology is that it provides some similar benefits, but the use is different or not. It would be great if we could talk, from that level versus the features, about what this does for the protocol. If you are telling me that it generates Dai, that is great. But I do not hear that. I am hearing rate stabilization or potentially working with things that are hybrid RWA.

[28:59](https://youtu.be/sSKWsFlNBz4?t=1739)

- Brian McMichael: Under the hood, the way the Aave D3M works is we are collateralizing the Dai that we generate with a Dai. Instead of being over-collateralized, like your traditional vaults, these are fully collateralized by the equivalent amount of a Dai under the hood. It is going to be a bit different from some other protocols. Ideally, we will have a token to put into the system and retain this full collateralization. But that might not always be the case. We might have to do receipts or something like that to make some of these situations work.

[29:44](https://youtu.be/sSKWsFlNBz4?t=1784)

- Christopher Mooney: I will add to Robert’s point because I have an excellent idea of where he is coming from. The collateral engineering services group has taken over this sort of collateral prioritization spreadsheets with normal collateral engineering. In those sheets, there is a number of these scored weighted attributes and risks of each collateral that we would add. We need to enumerate all particular benefits that a D3M could give us, whether Dai supply or rate stabilization. Maybe it gives us access to collateral that we cannot on board because it does not have a high enough DC, or it would be too expensive for oracles to add it. If we enumerate D3M positives in its collateral onboarding sheet, we could enumerate all of the risks of those D3Ms to get an idea of their rankings. Ultimately, to help review and steer governance towards whether or not we would want a D3M. I do not know if that is sort of the answer you were looking for, Robert, but I feel like that is something that CES can sink their teeth into.
- Robert: Yes, because whatever way the collateral application might come through, it specifies things on a level that we do not even understand the business opportunity. What are we trying to accomplish? Or what is the actual collateral in question? The utilization of D3M might be applicable in some of those cases, and it might not be. What I am suggesting is that for applicants that are coming into the system to help us educate them. One of the key tools would be to work with PE to get a summary of the D3M; here are the use cases, some potential areas where you will utilize this, where you would not, and some risks. We are still in the development of the D3M or at least the refactor of the D3M. That would be helpful.
- Primoz Kordez: One other proposal that I have coming from the risk angle is that D3Ms have a different risk profile than vaults. We have a financial risk with vaults, or you might call it collateralization risk, but then you have a ton of integration risk. You rely on external protocol, on all that Brian mentioned: Oracle risk, SC risk, and even their risk management. This part is hard to quantify. It is hard to calculate the risk premium of depositing Dai to Aave. We can do that for ETH a vault, but it is hard for Aave because we need to evaluate the risk premium of Chainlink failure at Aave for the Dai market. That is hard. We have all these unquantifiable failure risks that are also very devastating.
- Regarding the surplus buffer debate, how high should the exposure be versus the surplus buffer? Normally it should not be higher than the surplus buffer because you still have this low probability high severity event of losing everything if there is an exploit. At Aave right now, before the V3 is official, the Ethereum market is in V3. One token can rug pull the entire market, Dai markets, if they want. What I would propose to do is to have as many D3Ms as possible with some limited capacity. Because it is very unlikely that all of the protocols that D3Ms would be integrated into would fail at once. It could be correlated events. It could be something with stkETH and everything fails, or Chainlink. You could have this happening. But even with Chainlink, if you go to Compound, they have some fallback mechanisms. Oracle is probably safer than Compound. You get some isolated risks. That is why I prefer more D3Ms with some limited exposure. It would probably be more hatched with this than one large exposure to the protocol. Even if it sounds the safest, it is not necessarily the case because you have these huge tail risks.
- Brian McMichael: We probably also need people monitoring every external protocol that we integrate to keep track of their governance to see that something will not come down the line that will rug us. There are a lot of considerations around.
- Primoz Kordez: Yes, I agree with this. We have an internal dashboard for Aave right now. We are looking at every single market and what is happening. I tweeted last week about stkETH because I was afraid many Dai were being borrowed from stkETH. It appears that is much more than it was in the past, but we are still okay from that perspective. You need to know every single decision they make. One other bad part of this module is that even if you monitor well and know you should react, you cannot react fast. If you want to wind down the whole thing, it takes time. It would help if you had Maker votes for it. It is all public, gets discussed, and you might be lost out of the market. That is another reason for not being too exposed to a particular market share of the pool and the DC.

[36:16](https://youtu.be/sSKWsFlNBz4?t=2176)

- Christopher Mooney: It occurred to me that whatever we integrate with a D3M, you also need an incentive alignment between their token holders and MKR token holders. There is a huge incentive for another protocol to want us to be injecting Dai into their market if it means that MKR holders are footing the bill for any losses in their implementation. They need to feel the same pain and suffering from a loss, or their token holders do that MKR holders would. Only then are we separate but working in the same direction as far as risks go. I am wondering if it would be instructive to get into specific risks. We have been beating around the bush with some of the Aave risks that have come up in the last week. Does everybody feel like maybe we are at a point where we can talk about that? Or do we still want to talk about things in the abstract?

[37:28](https://youtu.be/sSKWsFlNBz4?t=2248)

- Someone: There was a question about the ES support we have in the chat. Currently, there are two kinds of things. We try to code specific scenarios that would allow permissionless shutdown. For example, if Aave or Compound changes some parameters, like the rate model contract or stuff like that, we support immediately unwinding Maker’s position. That is one thing. And the other thing is having support for a shutdown without the governance delay that Maker usually has.
- Christopher Mooney: There is a bit of a diagram that can give you an idea of the model. In the new version, there is a hub that manages all of the D3Ms. Each D3M has its plan and pool. On the plan and the pool, there is a function that we can call from the hub that gives us the ability to reach into these other protocols and look if certain conditions have been hit to prevent them from winding up or unwinding. It may make sense for us to have a call that does an emergency unwind. It is like an instant access module that minimally either circuit breaks its function or could unwind it. That is one risk mitigation tool that we may have across these D3Ms. However, it requires us to identify the technical need in these other protocols, which is phenomenal work. PE, CES, or Oracle needs to be digging deep into these entirely different protocols and then understand all of their technical risks. It is a big ask.
- Niklas Kunkel: That is one of the reasons why I am not very bullish on this thesis that Primoz gave earlier when he was saying we should have a bunch of D3Ms, and that way, if one of them blows up, at least we have been making enough returns from the other ones, and you get a good sampling. But yes, the overhead for monitoring many D3Ms is so high. And if it is not something where you are diligent and put resources behind it, you are almost guaranteed to miss something. I am more of a fan of a very small number of D3Ms that are just a concentrated bet on a specific partner with a specific market stature. Having a D3M there serves us strategically, rather than every DeFi protocol coming at us and saying, “yes, we would like some Dai liquidity, thank you very much.”
- Christopher Mooney: Maybe if they wrote their own D3M module in a sandboxed way, there might be a middle ground there. To get any traction out of Dai supply or solve those critical business problems Robert talked about. It will require an enormous amount of effort and ongoing monitoring; for us to have a D3M that is sizeable enough and justifies all that expense. Even then, there are risks that we cannot mitigate that we have to accept in that model. That is unnerving to think about, especially last week when the markets were really tearing down because of Terra Luna, and then USDT looked like it was de-pegging. Suddenly, multiple assumptions you make across the ecosystem start to fall apart. All I can think is, will Aave be okay here? It gets very difficult when we have risk factors that we need to mitigate slash accept.
- Niklas Kunkel: A lot of these things will fail in unison. Say there is some Chainlink hack, or they go rogue and malicious. All of DeFi starts falling apart because they all use Chainlink oracle. If you have a D3M to many protocols, you will hit all of them. It is not like you have one blow-up, and you are okay. Depending on how these things grow, we can say, “Maker, we have our oracles. We are not susceptible to Chainlink yet”, but you are through the D3M. So what is the inflection point where we think it is not worth the resources we are sinking into making this D3M for a little bit of Dai? We are not making enough money. We might think that the risk-reward is good for a medium amount of Dai, and we are making a good chunk of money. But we are also not over-exposed if it blows up. Versus, we are making a ton of money off this, but now we are adding this existential risk. There is this inflection point. I am not necessarily sure where it is, but it does exist, and we have to be conscientious.
- Christopher Mooney: With Aave in this case, first, let us think about the vault engine. In our typical vault engine, we put enormous effort into ensuring that we have very safe oracles for the vault engine and a significant expense for publishing those prices. We have put a lot of work and thinking and a lot of risk modeling into that. We could have easily switched over to using Chainlink oracles years ago. However, during a bear market, we decided that this is the safer, more prudent approach to control our oracles when we were trying to be safe and secure. When we accept a D3M with its own Dai generation mechanics, like in Aave, it has Chainlink oracles. Over the last couple of weeks, two major oracle risks have presented themselves from the Aave perspective. Chris Belick published the first one. The Chainlink oracles themselves have a contract with their aggregator, protected by a three of 20 multisig.
- For three of 20 multisig, you can propose a new aggregator and then promote the aggregator and then do a price update. There is no timelock in that process. In theory, you could do that entire update in one transaction and instantly change the prices across these different DeFi protocols. That means that three people out of a group of 20 people across the world can turn DeFi to ash over one transaction. Prior to the D3M and Aave, we would be the king of the ash pile. But with our current DC exposure, we are now part of the ash pile. At least MKR holders have to back hundreds of millions of Dai in this case. That is the first risk.
- I went out to their community, and I am trying to get one of the devs to talk to me about possibly adding a timelock or a way to signal that this is happening so that we can mitigate it in our new modules. We can see that this aggregator or something has been changed and that the entire price aggregator is about to flip over, and we can say, stop these modules or unwind them immediately. I have not spoken to anybody there yet. The second one emerged from the Terra Luna problem, which I forget on which chain it was. Effectively, Chainlink, at some point, paused the oracle feed for Luna. It was probably a reasonable response for something hyperinflating like Luna was. Or maybe a technical reason you have to do it is that you do not have enough precision to cover the hyperinflation in your pricing. They paused it, but many protocol integrators continue to use that paused price. They did not detect that it was paused. They used the price. This allowed people to mint a ton of unbacked assets against Luna.
- In some cases, it allowed them to drain the protocol. When we dug into Aave to see if they were exposed to the same risk, it did appear that Aave has this fallback; their fallback is in the case where the price is zero. Then they can do a fallback. Other than that, they are exposed to the same risk. The only mitigation factor to have is a smaller multisig that could take action to freeze lending against it. That is a different risk. We do not know how fast they could act or whether they have ever acted in the past, whether they are paying attention if those people are pageable. These are two major oracle risks that now the D3M exposes us to when we put so much effort in. We need to be careful about what we set the DC too. Those are concrete examples, but there are many other examples like the protocols we integrate; their contracts may be upgradeable and change. A lot of this may not even be malicious. They may do weird migrations that break our stuff. There is an enormous technical complexity, at least when dealing with D3Ms and thinking about the risks. I will pause there. It was a blizzard on avalanche.
- Kirk: There were two, probably Compound forks. Both were using Chainlink, and both got blown up when the Luna price froze.
- Robert: We have three to four D3Mish. Aave, Compound, TruFi, and Maple Finance are moving through the system. And others get proposed here and there too. Please keep in mind that this is something that if the community feels as if we do not want to go toward, we must hear in the signal requests and the on-chain polls that this is something that you do not want because there is a systemic risk here. We are trying to identify that for the community.

[51:40](https://youtu.be/sSKWsFlNBz4?t=3100)

- Thomas Flitter: A question out there on the chat. Is there any exploration of insurance mechanisms?
- Primoz Kordez: Protocols ensure things such as Nexus Mutual, but I do not have a high degree of certainty for ensuring something like that. If there is a blow-up at DAO, I do not think there is a protocol that can ensure you. Nexus Mutual was ensuring USD. I am not sure what happened then. I do not have a high degree of certainty of insuring against something like this.
- Kirk: But is it also making the technical complexity even higher? Now you have a third protocol that you also need to integrate with and understand: a DAO and a payout mechanism. It would only make the complexity even higher.
- Christopher Mooney: Minimally, these protocols have some backing pool or insurance mechanism. That is going to the comment I was saying earlier: MKR holders should not be more risk exposed than Aave or the Aave holders that back Aave. dYdX had a backing pool at some point. There is some risk exposure that each of these protocols can eat. We should never really expose ourselves to these protocols more than they have exposed themselves to their protocols. Those other ones like Nexus Mutual, all those things, I think those polls are far too small to make a difference.
- Primoz Kordez: I was rather thinking in the direction of having a vault-like mechanism where they stake some collateral, and in return, they get some profit share. Then the collateral significantly reduces the risk that Maker carries. I do not know to what extent that could even be made permissionless.

[54:36](https://youtu.be/sSKWsFlNBz4?t=3276)

- Payton Rose: We have said that for standard vaults, due to the amount of work and the risk and many other factors, we need to generate somewhere in the neighborhood of 30 million Dai from them to consider standard collateral. I am curious if we have done any calculations with the D3Ms. It sounds like they require more technical labor and have higher risks, which would suggest that the threshold might be higher for D3Ms to come on board as collateral. I am wondering if we thought about that. Is someone willing to throw out a number? I find it unlikely, but I will ask.
- Christopher Mooney: Minimally, the number is the amount of technical effort, and time it takes us to implement one. I would argue that it needs ongoing maintenance. Your number should probably be like a full-time person on the risk team looking at stuff. I am worried that that is a full-time person on the risk team and a full-time SC engineer. And maybe even per protocol. At least on the bright side, you do not have to update oracle prices. You are not subject to gas markets, but you will be subject to labor markets. Then those humans are also fallible. They may not function as well as you want them to.
- Primoz Kordez: One good thing about the D3M is that we have a much better indication of how much Dai will make because Maker is, as was said earlier, more like a push model. When we do a D3M, we should know that there will be a market for deploying X amount of Dai. The rates can drop, and I am still worried about what happens, like yield farming on the Compound and Aave. Saying that there is this market opportunity, we can at least deploy the Dai where sometimes we have onboarded equilateral type, and we have only relied on organic demand. Then we have seen very little demand. The good thing is that we can probably better estimate the investment opportunity, how much Dai can degenerate from this, and the size of income we can expect. On the flip side, the offering cost is much higher. At least currently, there is a refactor going on that should hopefully make it easier and simpler. However, every time you create a new integration with an external protocol that we are not experts in, it will probably need to be audited to ensure that we deploy the right amount of funds and those external protocols. The upfront cost is probably higher. We would probably want a higher return than that 30 million. It is much work
- Payton Rose: Thank you for branching that. Wouter, in the chat, is mentioning the idea of self-insurance via staked collateral, which is an interesting counter idea. Maybe we do not need to require as big of a generation if we can undercut the risks by requiring others to stake something to activate the D3M. That is cool.
- Matt: We can extract some wisdom from how this exists in the real world. I will not say Maker is a bank or central bank. Just humor the notion that you have a central bank that provides credit to a bank or an investment bank that then deploys it into the real world to get credit, to go tap into that. In the similar way that Chris was outlining, when you integrate a D3M into a digital aspect, you have the downstream integration risks of who knows what will happen and how you track that in the world. It is similar to deploying capital into a credit market of an originated loan and whether or not that issuer, tenant, or counterparty, what their risk will look like, and how that world view changes. There is an entire derivatives market for credit default swaps on a macro level. That is that you are not allowed to call it insurance. It is a default swap. It is insurance to protect exactly for that. In many ways, we are synthetically replicating the existing credit bank infrastructure. It is worth taking some wisdom from it and acknowledging that what we are doing is nothing that has not been done before. We need to be very cautious in doing it because it is costly to deploy. And it does bear downstream risks.

[1:01:09](https://youtu.be/sSKWsFlNBz4?t=3669)

- Payton Rose: What does the ideal D3M collateral look like? I saw Nikolai on the chat mentioning something that is permissionless or immutable.
- Christopher Mooney: An integration would be a protocol or an entirely permissionless pool. So that we can thoroughly tackle its scope and understand all the risks around it, that domain of risk is finite. We think a bit about markets and how things might change, and we think a bit about SC risk. But then we are done. In theory, if you had a D3M around some pool generating yield, or something like that, you needed to inject Dai into, the risks may be reasonably well-scoped. It is more of the complicated markets where you get into the explosive exponential risk. I do not know if anyone else wants to answer that. I think D3M works well for something technically scoped to do its own thing. It may be a technical solution to this concept of an arranger for real-world assets. There may be an angle there that it makes sense for.
- Brian McMichael: To answer Payton’s question, I would say that, like Uniswap, pools would probably be an ideal protocol specimen because they are effectively immutable. There are some changes in V3 that allow token holders to change fee parameters and things like that. But it is a lot easier to reason about what can go wrong in these places. After deploying our end, we do not have to worry about the logic changing from under us.
- Christopher Mooney: I have a closing thought on it. Given the explicit risks of the Aave D3M and the current DC, I feel that Primoz and the risk group will probably recommend a lowering of the DC. I do not want to be the single person to say that we should scope it down to the surplus buffer. I understand the risks that we know now and the additional unknown risks. I would say we should not expose ourselves beyond the surplus buffer at this moment.
- Primoz Kordez: We have great meetings next week, which I wanted to bring up. It is also the fact that the community agreed not to be exposed more than 30% to the supply side of the pool, and the pool shrank quite a lot because recursive farming dropped. The pool size is 500 million, and our DB is 300 million. The exposure is lower, but this was already a factor why we would want to propose lower DC for the growing financial risk with Aave. There is the situation with stkETH that users cannot unwind. There is not enough liquidity. I am not panicking as it is manageable. But overall, the risk at Aave is a bit higher than it was months ago. We are proposing to decrease the DC. That is the reason why I said we should continue with multiple D3M. We will not cover five or more of them in the near time, but we should be more aggressive on Compound and try to diversify these 100, 200, and 300 million investments into a few safe ones as soon as possible.
- Payton Rose: Awesome. I appreciate those closing thoughts. We look forward to seeing what the committee recommends.

## Open Discussion

### Payton Rose

[01:06:23](https://youtu.be/sSKWsFlNBz4?t=3983)

- We have had much good discussion today. It has been many calls for some of us here. A lot of the comments have stayed pretty on the topic regarding D3M. But given that we have about 15 minutes more, I wanted to open the floor to open discussion. We saw some comments about self-insurance funds and other tangentially related things, but they might be good stand-alone topics. If you have a topic or anything you want to discuss today, please either raise your hand or drop it in in the chat.
- For some context, if we recalled last week, Rune was asking people to participate and then know, like, hey, what is the composition of this call? We will have many CU members and recognized delegates. Like there are many stakeholder groups, but if you would like to participate, you can select all that apply, which will give us some interesting information here on the composition of our weekly meetings. We should probably do this a few calls to see if what we get is representative or not. It seemed it was quick to throw up there.
- That is pretty much everyone, like 38 of 42. I will do a small screencap so we do not lose it. Unsurprisingly, about three-fourths of our Core Unit members. Next top option, about 40% saying they hold some MKR.
- I like the idea of running that poll to conclude things. Oddly enough, next week, we will have our specials starting time. It will be interesting to see if those numbers vary significantly from our regular starting time. That was a neat question. We will make sure Rune gets to see that since he was wondering the other week.

## Conclusion

### Payton Rose

[1:12:15](https://youtu.be/sSKWsFlNBz4?t=4335)

- Thank you again to everyone for coming out in person and if you are watching the recording. We value your input and the discussions we have every week.
- We will do another reminder. We will post on the forums and in the chat. Next week, we are trying out our especially later meeting time. The G&R call will be starting at 2100 UTC, rather than 1700. We hope that most of you can still join us at that time. We are trying to be a little more friendly to our time zones around the globe. We will be trying some stuff out in the next couple of months to see if we can get better representation depending on our time zones.
- Thank you, everyone. We will cut off the recording there. I appreciate. We will see you next week at our new time.

[Suggestion Box](https://app.suggestionox.com/r/GovCallQs)

## Common Abbreviated Terms

`CR`: Collateralization Ratio

`DC`: Debt Ceiling

`ES`: Emergency Shutdown

`SF`: Stability Fee

`DSR`: Dai Savings Rate

`MIP`: Maker Improvement Proposal

`OSM`: Oracle Security Module

`LR`: Liquidation Ratio

`RWA`: Real-World Asset

`RWF`: Real-World Finance

`SC`: Smart Contracts

`Liq`: Liquidations

`CU`: Core Unit

## Credits

- Kunfu-po produced this summary.
- Larry Wu produced this summary.
- Everyone who spoke and presented on the call.​