Episode 177: February 3rd, 2022

--- tags: G&R --- # Episode 177: February 3rd, 2022 ## Agenda - [00:00](https://youtu.be/BZesImg9oUw): Introduction - [01:22](https://youtu.be/BZesImg9oUw?t=82): Votes and Polls - [3:28](https://youtu.be/BZesImg9oUw?t=208): MIPs Update - [07:19](https://youtu.be/BZesImg9oUw?t=439): Forum at a Glance - [14:40](https://youtu.be/BZesImg9oUw?t=880): Initiative Updates - [21:53](https://youtu.be/BZesImg9oUw?t=1313): Team Lead Discussions - [1:05:28](https://youtu.be/BZesImg9oUw?t=1313): Open Discussion - [1:11:34](https://youtu.be/BZesImg9oUw?t=1313): Conclusion ## Video <https://youtu.be/BZesImg9oUw> ## Introduction ### Agenda and Preamble #### Payton Rose [00:00](https://youtu.be/BZesImg9oUw) - Hello to everyone. Welcome to episode #177 of the Scientific Governance & Risk meeting for MakerDAO. We are joined by a bunch of awesome Maker people who are interested in the protocol. Many of us are working forward. We are here to talk about the current issues at hand, do some reporting on governance, and discuss risks. This has been recorded for YouTube. Let us try not to talk over one another; it is rude and annoying for the recording. We have a chat. You are free to unmute to share questions and opinions. If you are unable or otherwise unwilling to do so, please drop your comment in the chat. I am happy to read. Using the raise hand function is super helpful. That way, I can call on you if you have something to say, and you do not have to worry about jumping over anyone. ## General Updates ### Votes #### Payton Rose *Polls:* - 1 Weekly Poll - PASSED - PPG - Open Market Committee Proposal - 2 ongoing Greenlight Polls, ending on Monday, Feb 7th. - STABLE-TBILL - STABLE-NOTE *Executive:* - Last Friday’s Executive - Passed and Executed - Core Unit Budget Transfers and Streams - Tomorrow’s Executive Contents: - January Recognized Delegate Compensation Distributions - Emergency Shutdown Module (ESM) Threshold Increase - MOMC Parameter Changes ### MIPs #### Pablo [Weekly MIPs Update #72](https://forum.makerdao.com/t/weekly-mips-update-72/12945) ![Calender](https://i.imgur.com/VmG1zT0.png) ![MIPs General Updates](https://i.imgur.com/aBWX3YX.png) ![Formal Submission Window](https://i.imgur.com/yFH9dhG.png) ![MIPs](https://i.imgur.com/4d4E1zS.png) ![Core Unit Onboardings](https://i.imgur.com/uoFZipV.png) ![Facilitator On-And Offboardings](https://i.imgur.com/EgzlIvy.png) ![Core Unit Budgets](https://i.imgur.com/AAK5r8k.png) ![Amendments](https://i.imgur.com/EDqKtKS.png) ![Others](https://i.imgur.com/iZOtX1x.png) ![Proposals in RFC](https://i.imgur.com/XoYOiCe.png) ![Onboarding Keeper Networks](https://i.imgur.com/EEmUkz9.png) ![Amendments](https://i.imgur.com/DKnGQV4.png) ![That's all for MIPs.](https://i.imgur.com/3APBWIG.png) ### Forum at a Glance #### Artem Gordon Post: [Forum at a Glance: January 27th - February 3rd, 2022](https://forum.makerdao.com/t/forum-at-a-glance-jan-27-feb-3-2022/13019) Video: [Forum at a Glance](https://youtu.be/BZesImg9oUw?t=440) ## Initiative Updates ### David Utrobin #### Stakeholders [15:10](https://youtu.be/BZesImg9oUw?t=910) ![](https://i.imgur.com/vnJagr3.png) - Today, we will cover the Security Initiative and talk about our Q1 to Q2 2022 milestones. Here is the list of the stakeholders involved. Our team and Immunefi Security mainly lead the coordination. The initiative itself covers several different things, such as emergency preparedness, identification of critical infrastructure, and bug bounty programs. It is an umbrella security initiative. We have identified four main milestones, which I will go over individually. #### Milestones [16:06](https://youtu.be/BZesImg9oUw?t=966) ![](https://i.imgur.com/4Xy5yBo.png) - The first milestone is to sync pagerduty across all the relevant CUs. Pagerduty is an application emergency to call upon devs and other key people in an incident. We currently have several different engineering and infrastructure teams that use pagerduty in their silos. Over the next few quarters, we want to get to where pagerduty is all synced. Components of this milestone are to document all the assigned primary and secondary coordinators and the subject matter experts associated with various emergency types. This is in progress. Immunefi Security is in the process of doing this as well. The second component is identifying the ticketing and incident tracking systems that exist. Immunefi Security is also handling this. After all the people are documented, there will be a migration/sinking plan around pagerduty. ![](https://i.imgur.com/gOdZoc7.png) - We have the completed first version of the emergency playbook and associated resource documents for milestone two. This emergency playbook lists out the basics of how MakerDAO handles and defines emergencies. What are the major buckets of emergencies? What roles have Maker outlined? Who are the subject matter experts? What types of threat monitoring are occurring? There are also buckets of resources for individual emergency types that complement the playbook. This provides collective resources, documents, and templates on things like a missing person or critical person, emergency shutdowns, or critical bug scenarios. - The third milestone is the Defcon spell library renewal. Defcon is a list of spells that are pre-written in response to emergency scenarios. These can be quickly deployed. There is no intended time for an engineering team to craft the spell. There is currently an existing Defcon spell library, but we need to review them. The three components, all in the To-do Phase, are listed below. ![](https://i.imgur.com/N0infHP.png) ![](https://i.imgur.com/uMYcQsJ.png) - The fourth milestone is the complete launch of the Immunefi Security Bounty Program. The first component was implementing the MIP64 Bug Bounty Program for MakerDAO critical infrastructure; this MIP passed and is in existence. There are some amendments in progress to improve the smaller bug bounties. We want to pay and payout bounties without the need for an executive. Immunefi Security can pay out of their operational wallet. These slides are linked to the agenda. Additionally, there is the completion of the draft documentation for the programs. MIP64 outlines the framework of the program. The documentation for the program goes a lot deeper. It identifies the basic infrastructure and outlines the bounty amounts. It is one level deeper of granularity around the program. Lastly, onboarding the stakeholders to the bounty dashboard is the component. There is a bounty dashboard that Immunefi Security is working on that will be a collaborative effort between them and all the CUs that manage critical infrastructure. They need to be able to list manage those bounties. ## Team-Led Discussion ### David Utrobin #### ETHDenver [22:03](https://youtu.be/BZesImg9oUw?t=1323) - There are two things I want to cover here. Number one is a call out to everybody on this call, whether internal or external stakeholders. Please reach out to me in Discord. I would love to invite you to our channel room for ETH Denver. Second, we have a shared Google spreadsheet that lists the events on MakerDAO’s radar, the speeches, and an attendee list of people. The spreadsheet is publicly viewable. I am happy to share editing access with any stakeholders attending, as this is a collaborative effort. Please feel free to add any exciting events you find. Some people will be there earlier and some later. If anyone wants to bring anything up, please do. If not, we can move on to the following discussion. #### Goverance Compensation Improvements [23:54](https://youtu.be/BZesImg9oUw?t=1434) ![Goverance Compensation Improvements](https://i.imgur.com/Vh9DaeX.png) - Prose11: Next, we have governance compensation improvements. This topic came up regarding the discourse on Sourcecred. I believe it was Josh who put up the signal asking if we should remove paid contributors from the DAO and the Sourcecred payment list. Maybe someone can drop the link, or I will in a moment. This comes at an interesting time because GovAlpha is working on our next budget. We are looking at our funded programs, one of which is Sourcecred, and considering alternative incentive mechanisms we should be utilizing. Should we even use any at all? [24:55](https://youtu.be/BZesImg9oUw?t=1495) - David Utrobin: Why do people think the Sourcecred should be discontinued for people like delegates? It is additional dynamic compensation that can incentivize more participation. There is a bare minimum that delegates must fulfill to be compensated through the program. I feel that Sourcecred is a good system that we do not market properly. It should be kept but not for facilitators and employees. I am curious what people's thoughts are on the subject. [25:36](https://youtu.be/BZesImg9oUw?t=1536) - Andrew Burban: How much has Sourcecred payed out? I am curious as to what sums it is paying out. I have received some payment but nothing too much since I am not active on the forums. Are people making tens of thousands of dollars doing this? - Prose11: We distribute 5,000 every week. It has been that way for a little bit. You can pull up the site here if you do want to explore. - David Utrobin: I think the largest payout is 2,000 a month for an individual. Correct me if I am wrong. - Andrew Burban: 2,000 a month to someone already getting full salary may be unnecessary. I am all for taking it down for people already getting compensation. However, this does keep an incentive for people being paid to continue participating more in forums. I favor keeping the money reserved for people who are not already on our payroll. [26:57](https://youtu.be/BZesImg9oUw?t=1617) - David Utrobin: This is a flexible and configurable algorithm. Is there a way to assign specific forum users labels? For example, a delegate here. You still want to give them compensation, but maybe downgrading their compensation multiple? - Joshua: Since posting that signal request and reading all the comments, I think a better approach would be to have two Sourcecred instances. We should leave the current and working Sourcecred instance and add another one that compensates contributors who the DAO does not already pay. If so, we do not need to rejigger things with the old one; only add a new one for contributors not already receiving compensation. - LongForWisdom: One of the big selling points on Sourcecred was that it did not require a lot of micromanagement. Adding another instance and additional rules (i.e., Some people are eligible and others are not); might contradict this nice selling point. - Prose11: That is a good point, Long. To add to your point, David, they constantly ship new features for the main Sourcecred instance. But it takes work to update ours properly. There are a couple of features that could be interesting to your point. There is mainly one that allows you to assign a salary to users. They will only get paid if their distribution exceeds that sale amount. In theory, you would be paid extra. However, as Long pointed out, that would mean a lot of management to keep track of the DAO's payroll and salary increases. [29:24](https://youtu.be/BZesImg9oUw?t=1764) - David Utrobin: I want to bring up Mark's point in the chat. We need to focus on the outcome and not the solution first. With Sourcecred, the original creation was to increase high-quality forum participation. Sourcecred allows you to assign higher cred scores to specific categories of posts. For example, let us say we wanted more participation in signals or in RFC. Is that the case? Feel free to correct me if I am wrong. - LongForWisdom: That is not the case. We wanted to do that, but it was impossible or not easily possible. [30:09](https://youtu.be/BZesImg9oUw?t=1809) - Joshua: One goal important to keep in mind is bringing new people into the Maker ecosystem. That is why I posted a signal thread in the first place. I felt like the main beneficiaries of Sourcecred were people who already knew about and participated actively in Maker. We want to try and bring in new people. - Unknown Speaker: Sourcecred is a tool to bring in new people while retaining people in the ecosystem. We need to do marketing about Sourcecred, the DAO, and DAO participation to bring in new people. - LongForWisdom: I would agree it is more about retention. The idea is that someone arrives on the forum and is excited about Maker. Sourcecred justifies the time they spent to get up to speed with and absorb the vast information and context. The hope is that this person then becomes a delegate, joins a CU, or further engages in the community. [31:22](https://youtu.be/BZesImg9oUw?t=1882) - David Utrobin: I wanted to make sure that people understand what Sourcecred is because we did not define it in this discussion. Sourcecred is a module tool on the Maker forum that rewards people for participating. You can opt-in by DMing the Sourcecred admin. If you search up Sourcecred in the Maker forum, it will give you instructions for how to opt-in. Many parameters define your cred score, such as the number of post likes, post quality, and post length. The cred score is mapped to a Dai payout. You sign up with an ETH address and get paid Dai for participating in the forum. - Prose11: That is a good rundown, David. It is based on PageRank. We have a forthcoming report from GovAlpha that will detail Sourcecred. TL did it. However, it is difficult to empirically determine if TLDR effectively incentivizes people to participate more on the forum. A lot of the reasons why we do it are a bit anecdotal. We are struggling with incorporating Sourcecred and incentives into next year's budget. Long pitched the idea of an alternative rewards proposal. Instead of rewarding all the involvements in general, it would go through governance directly. There are some trade-offs there but is an alternative we can consider. Governance participation is an interesting problem because it is a collective action problem. Doing the proposals yourself takes a lot of legwork and months of attention to a particular topic. In addition to other downsides, this makes it a bit disadvantageous to become a MIPs author, for instance. I want to see this combated. [34:38](https://youtu.be/BZesImg9oUw?t=2078) - Mark: There are two big components here. Firstly, there is marketing the DAO and Sourcecred. Marketing can provide a solution to attract and build community aspects. This is challenging given that we currently have no marketing team. The second component is retention. There is a broad consensus on not paying facilitators and paying part-time contributors. I assume that most facilitators want part-timers converted to full-timers because full-timers are fully engaged and drive more value than the equivalent number of FTEs. For delegates, there should be a cap for Sourcecred. For example, if you get 12,000, you should not be eligible for Sourcecred. However, if you are starting out and not getting paid much, you would greatly benefit from the Sourcecred you generate. At this stage, the first part is more important because we want to bring in more people. The community is already highly engaged; we need more people to join this ecosystem and community. - Joshua: Regarding overhead, would drawing the line between part-time and full-time be more work to keep updated than drawing the line between those receiving MakerDAO compensation and those new to the forum? - LongForWisdom: Figuring out which people work part-time enough to qualify for Sourcecred is not going to be fun. We do not want to do this because it is difficult and requires us to know how many part-timers who want Sourcecred are being paid. This is not feasible. [37:01](https://youtu.be/BZesImg9oUw?t=2221) - David Utrobin: I am curious about the second part of the compensation for successful MIPs and sub-proposals that go from forum posts, through the RFC, into formal submissions and then ratification. We would love to hear more about that idea. - Prose11: Long, feel free to jump in. As you mentioned earlier, we tried a governance's boost to incentivize hosting more MIPs and signal request with sourcecred. Due to the Patric algorithm, you get peculiar results when you mess with some of the weights. The algorithm builds a graph based on everyone's likes. It ends up flowing weird if you ratchet up the like weight on one category. When trying to get that to work, we could not find a data set that suggested it was compensating participation on MIPs and in signal requests or separate puzzles. This was what we wanted to do. The counter would take a pool instead and divide it among all the successful proposals for that month. There are many ways to implement it. The idea is that if a proposal goes through governance, in theory, it was a quality signal that the community wanted. Perhaps, we can incentivize that directly rather than incentivizing participation more vaguely. - LongForWisedom: There is a slight downside to doing that. I have not previously alluded that the point of sourcecred is to track miscellaneous inputs. If someone gives a lot of feedback and gathers a lot of activity, the sourcecred size indicates its usefulness. If we pay for proposals, we lose sight of this almost entirely. For example, we would most likely pay authors and contributors marked down in MIPs. However, there is nothing forcing authors to put contributors in. Then, we must make weird decisions on adding contributors and determining the contribution amount. Joshua mentioned splitting MIPs into smaller MIPs to get more credit payouts. That is an argument in favor of having a pool of bounty money that is split across all successful MIPs in the month. It is pointless to create more. [40:07](https://youtu.be/BZesImg9oUw?t=2407) - David Utrobin: The MIPs framework guards against making too many MIPs. Why would you create three MIPs when you can make one? - LongForWisdom: If someone is trying to abuse it, we would tell them to combine them. Spam is a potential issue, but it is a potential issue with any system we use for incentivizing activity. [40:35](https://youtu.be/BZesImg9oUw?t=2435) - David Utrobin: As Paper asked in the chat, are we trying to pay people to do governance or pay people to show up? In my opinion, it is paying people to be proactive with putting things through governance. Tim Schuppi is an excellent example because he is highly proactive in getting much-needed signal requests and governance polls up. We want to incentive that type of behavior. - LongForWisdom: There are a few things we potentially would want to incentivize. As Mark mentioned, it is challenging to use sourcecred to bring people to the forum because you risk people trying to abuse it. People are coming in for money and not because of an interest in the protocol. A retention tool could be managing the bridge of engaged community members that do not have the experience or desire to join a CU, become a delegate, or work for a salary. As Paper said, we want people to do MIPs, signal requests, etc. [42:09](https://youtu.be/BZesImg9oUw?t=2529) - Prose11: Cool, I am getting signals to move on here. I want to give a shot to anybody who has not weighed in yet. If you have any thoughts or general ideas about this, please feel free to drop me a DM. #### Dai Liquid Solution Design [43:00](https://youtu.be/BZesImg9oUw?t=2580) ![](https://i.imgur.com/KYi3aWV.png) - David Utrobin: I could introduce the topic, but we have many heavy hitters’ participants with great opinions. But to generally set us up, Maker has been wrestling with the ideal model for creating Dai and MKR liquidity in the markets. This includes L1 and L2 to bootstrap those markets. We are questioning if we should outsource it to trusted third parties. Do we do a protocol-owned liquidity model where the protocol diverts surplus to funding liquidity position? The conversation I want to set up here is what is the ideal model? What are the high-level requirements? I want to open up the discussion to the main people with the strongest opinions. - Prose11: There are different elements worth noting here. I saw Wintermute come up with a few things. There are also L2 considerations, and we could focus on liquidity in many other places. I see Makerman raising his hand here. [44:29](https://youtu.be/BZesImg9oUw?t=2669) - Makerman: Alright, I will give this a shot. I have not published my work on this. Based on my research, something like the uniswap v2 liquidity has ideal characteristics for DAO-owned liquidity. My work assumes this. Once a third of the overall liquidity is paired with a stablecoin, you get some nice properties from AMM model. Firstly, 30% is a big number. It becomes the market and defines the market every arbitrager will use as a liquidity source. In terms of price support, with a third of the liquidity, you are paired with Dai at 2000. Even if you eat all the additional liquidity, the maximum downfall with that third is about a factor of nine. - That AMM with fees will also basically be the DCA fee and the LP pool. You would set up the LP pool to 30%. We picked a high number but an achievable target. If you earn 10% in that pool, you will soak up 3% of the available liquidity in Dai or Maker. It would take about 20 years to eat all the liquidity should you get an estimated 10% per year. The liquidity is rolled through the liquidity contract. You may do the math at 0.3%; it is ideal. The beauty of the v2 liquidity is that it sinks Dai. There is no price range to pull Maker out of that contract. There will always be Maker stuck in that contract at some price, and the same with Dai. - You can debate Dai being a liquidity source, but it essentially syncs it all. If the DAO owns the liquidity, the DAO earns fees on that liquidity. We do not even need an auction system if we make that liquidity. We can buy Maker from that contract, pair it with Dai, and stick it back in. If we are smart, we will use an MEV bot that does not get front run on. In the end, I have about 20 different reasons: this was part of a proposition scheme for growth. The concept here is that Maker Dai should also participate in governance; it is an ideal way to vest. The v2 liquidity contract for the DAO is conceptually a great play for long-term investors. - When you stick it in governance, you can do exactly what Rune wanted, borrowing Dai against that LP. It may be a permanent loss if you look at it as just an investment vehicle. However, I consider it a misnomer. When you pair a token with a stablecoin, there is no correlation in price. Whereas if you do ETH and Maker, ETH can drop a factor of 2, and Maker will go rate with it. Also, you hardly get any action in terms of fees. But in my work with an uncorrelated stablecoin pairing, you get at least double the fee return and price support. There are many great features about the AMM model, particularly the V25050. You can do other things with other models I studied, such as balancer. However, this one is so compelling. It is democratic to anybody who owns that LP. Only the people are in V3LP and V2 are in front of you, but they share those fees equally. The idea is that they will hoover up liquidity over long periods to where you get 60-80% of the total liquidity and great price support. Then the DAO would have start selling the LP. [48:40](https://youtu.be/BZesImg9oUw?t=2920) - Andrew Burban: Rune wanted to create a Maker Dai LP that could somehow participate in governance. He did much complex math and should be hearing talking about it. He has been telling me about it, and I like the idea. This is just one of my thoughts; we can somehow bond the Maker token or absorb the LP ourselves just for people who provide it. They would then get a governance share by having been in this LP. - Our liquidity is dire. People want to panic sell while not realizing that we are a liquid market selling several thousand Maker. That is one liquidity solution, and Wintermute is another. Regardless, one of our most pressing issues is getting a liquid market for MKR. I got a couple of friends to buy a small amount of MKR, 8,000 to 10,000. They were getting margin calls on equities. There was a market dump as the bond market sold about 1,000 Maker. Now they realize what that might do to the price. People are familiar with how liquid we know to spread the investment over a given period. - David Utrobin: I understand that liquidity is important for the fundamental security of the protocol. Imagine a situation where there are flop auctions, and MKR is being minted and auctioned off. We would still benefit from the situation if there was a huge pool of protocol liquidity to make those trades against. The more liquidity, the less price impact. Is that the right way of understanding? - Andrew Burban: Yes. That would be a worst-case scenario where we have to bail out bad debt right now and mint Maker into liquid markets. [52:38](https://youtu.be/BZesImg9oUw?t=3158) - Niklas: There are many valid reasons for LPing and creating liquidity. However, trying to make liquidity to flop into is not one of them, especially at our current scale and liquidity state. Even if you get the liquidity to “good shape” compared to other Defi tokens, you will still not be able to flop 50 or 100 million of bad debt. This is regardless of MKR’s liquidity state. This moves the needle so little that it is practically meaningless from a flop perspective. The real mechanism you have for backstopping is an insurance buffer in the surplus buffer. This is not to say that liquidity provisioning is a bad idea. However, justifying it to make flops more effective is not practical. Flops is a meme. [54:08](https://youtu.be/BZesImg9oUw?t=3248) - Prose11: Does anyone have thoughts on MKR liquidity versus Dai liquidity? Both are going to affect us quite a bit. We had a few discussions with mandated actors about L2 liquidity being soft on Dai in particular. - David Utrobin: My understanding is that Dai liquidity is a lot more about business development. If you can ensure Dai liquidity, then you can ensure that you are the leading stablecoin in a given network of markets. The MKR liquidity piece is more about the protocol's health, industrial options' health, and to some extent building up a capital battery. - LongForWisdom: If we are talking about on-chain liquidity in general, the goal should be to make Dai the routing token for all AMM transactions. USDC does this by default. That is the goal because you would get all trading fees. You also get lots of liquidity for collateral. [55:38](https://youtu.be/BZesImg9oUw?t=3338) - David Utrobin: How does the DAO arrive at the ideal solution? Does somebody have to spearhead a proposal that goes into RFC? There is a time sensitivity around this topic. If we do not move quickly enough, we lose an edge. Who should ideally spearhead this kind of initiative? How do we get a wise ideal model? - Prose11: Part of the problem is that you could take many different solutions or routes to provide liquidity. Even arriving at the best ones is not a trivial task. [56:42](https://youtu.be/BZesImg9oUw?t=3402) - David Utrobin: That is also part of the attraction to using somebody like Wintermute. This gives us a more efficient method because it does not have to go through all governance. It also does not need to go around all the stuff we build if a protocol is owned and managed. - PaperImperium asked what the exact problem we are trying to solve is? Mediocre attempts end up tying up a lot more resources. Like software solution design, you do not want to do five things simultaneously. Instead, you want to identify the wisest approach and put all your resources into that. That is why I am against trying several intermediate solutions. I am interested in maybe two, for example, a limited engagement with a third-party market Maker while also building out the protocol's side. - Prose11: There is some question of Dai versus MKR. There are several differences in reasoning. Liquidity comes up because you can provide a giant Maker Dai pair, as Makerman was suggesting. - David Utrobin: Lunaman pointed out another approach, partnering with projects on Layer2 and incentivizing them to use Dai as their LP pair. This could be an effective way to boost Dai's liquidity and develop some business. - LongForWisdom: There is only a handful of ways we can do this. We can pay someone to provide liquidity. We can mint Dai, expect it not to be 100% backed, and use that to get liquidity. We can use a surplus buffer, but that limits our capabilities because it is small. Or, we can make Maker and sell that to get the funds we need to order liquidity. Another option is to borrow against MKR on something like Aave to get Dai’s liquidity. This seems a bit sketchy. Another possibility is to use some other protocols. Where we send the money is also important but we need to have the money it spend on liquidity. [1:00:01](https://youtu.be/BZesImg9oUw?t=3601) - Prose11: From a technical standpoint, how different is minting Dai to provide an LP pair from the D3M implementation? We mint the Dai, we deposit it (in this case with Maker) and then we receive collateral back in the LP token. - Niklas: One can become severely under collateralized. While is possible for the other, it is much less likely. The volatility is reduced with an LP token, but it is not gone. With the right market drop, and depending on the size, you could make the system go insolvent if you start minting Dai against another token to make an LP. It is also different from a D3M when the market moves down on Aave. Okay, fine. People get liquidated. There is a self-sustaining mechanism with this feedback loop to keep Aave solvent. In return, this keeps our D3M solid. We do not have that guaranteed with the LP stuff. What do we do when the market dumps? Do we start unwinding that position? We end up becoming speculators trying to guess the market direction. That sounds like a terrible place to be from a protocol level. You can speculate on the treasury management side, but not on the protocol level. - LongForWisedom: One of the problems is all the options are unpalatable. It is also impossible to buy MKR and sell it to buy Dai for liquidity. So, it is not doing much because the service buffer limits us. We must make some trade-offs to deploy significant amounts of liquidity. [1:02:47](https://youtu.be/BZesImg9oUw?t=3767) - Prose11: Have we heard anything from the Wintermute’s side? Maybe Nadia or Burban, have you been in touch? - Andrew Burban: I have not reached out to them for a little while. Nadia’s bandwidth might be stretched thin, but I hope we can organize at least a community call. He had COVID that last time we were on call, so he was all over the place. We should have a dedicated call for this topic if Nadia or someone can coordinate it. We are also getting a quote from LedgerPrime to see our other offers. I am more partial to Ethereum, having met and liked the team. However, the more offers on the table, the better. [1:04:16](https://youtu.be/BZesImg9oUw?t=3856) - Prose11: Lunaman asked a good question: is the goal incentivizing Dai liquidity in LP pairs or on L2 lending platforms. I do not speak for everyone, but yes. L2s are very important now, but Dai is generally the go-to pair rather than ETH. - LongForWisedom: The plan is to eventually launch Maker on L2. That would provide Dai liquidity for borrowing. ## Open Discussion [1:06:12](https://youtu.be/BZesImg9oUw?t=3972) - Andrew Burban: I am trying to see how they promote our main product and wonder how we can work together. Few projects are showcasing Dai as the token of choice. They have seemed to have developed some well-designed tokenomics for their token; we can borrow some of their ideas. He is posting some on the chat right now. We might use it as a tool for auctioning or hedging positions. [1:08:06](https://youtu.be/BZesImg9oUw?t=4086) - Kirk: I will use the opportunity for a short rant. The whole point of tokenomics is to incentivize good governance. That is what Maker needs. I see it as a secondary issue to the more fundamental problem. The fundamental problem is scaling and integrating with the legacy economy. Lately, there has been a hot buzz in DeFi about the vote escrowed model, and many projects are switching to it. That is not necessarily a bad thing; I think it is interesting. - However, I would caution people not to get too caught up in navel-gazing over-designing the sexiest tokenomics mechanism. All that matters is, how do we get Dai used by a billion people? Using the protocol, how can we support a meaningful chunk of the global economy? If we 10x the Dai supply and the systems' revenue, the tokenomics does not matter. The tokenomics is not blocking us from doing that. While designing a better tokenomics system is good, I caution people not to get too caught up in it. The MKR token has the right to all future system revenues. I prefer to focus on creating the value first and the more specific tokenomics mechanisms later. I am not saying we should not redesign the tokenomics mechanisms to be better. However, tokenomics has become this totalizing thing. People may focus on it and drop the ball on scaling or other important things. So that is my rant. Thank you for coming. ## Conclusion ### Payton Rose [1:10:13](https://youtu.be/BZesImg9oUw?t=4213) - Shout out to whoever utilized the anonymous suggestion box for the G&R. We do not get much traffic here, but there was a call out to ask about Devconnect in Amsterdam in April. If anyone is going, drop a link. In case you are unfamiliar with the event I mentioned in our Discord earlier today. That is my plug. Any other plugs from anyone else? - David Utrobin: If anybody with excellent written English skills and not a technical person is interested in contributing, please reach out to me or anyone in the GovComms team. We are looking for contributors to help us put together some stakeholder publications like The Maker Relay, Maker Governance Review, and others. It is a compensated job for anyone trying to get their foot in the door. - Hassu will be joining us to talk about their platform in next week's meeting on Wednesday. [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 - Artem Gordon produced this summary. - Larry Wu produced this summary. - Kunfu-po produced this summary. - Everyone who spoke and presented on the call, listed in the headers.