Governance and Risk #173 - Thursday, January 06 17:00 UTC


This communication is provided for information purposes only. The views and opinions expressed in this meeting are those of people involved, and do not reflect the official policy or position of MakerDAO or any of its contributors, Core Units, or affiliates. This communication makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, financial or tax advice. You should consult your own advisers as to those matters. References to any digital assets and the use of finance-related terminology are for illustrative purposes only, and do not constitute any recommendation for any action or an offer to provide investment, financial or other advisory services.

Call Information

The zoom waiting room will be on, and a password is set to: 748478, please ping us in the Maker Discord’s #governance channel if you aren’t let in from the waiting room.


Slides - updated before the call


Governance Round-Up

Selected Presentations

2021 Governance Review
Where did we start?
What has been accomplished?
Where are we going?
What are the focuses for 2022?

Deco DSSGate
How’s Deco doing?
What is DSSGate?
What governance parameters will governance need to manage in the future?

Other Discussions and General Q&A

General Q&A
Ask us stuff.

Open Discussion
List of interests:
D3M spread management
Market making
Altering Community Greenlight Polls process.
Institutional Vault Deals,
Delegate Compensation
Ways we can improve governance
Call attendees to decide. Help us by using the anon question box below :point_down:

Leave your questions in our anonymous question box and we’ll do our best to bring them up during the call.


G&R #173 Snippet

This snippet includes Governance, MIPs, forum updates, and Core Unit team discussions from the MakerDAO Governance and Risk Call #173.

General Updates



  • No Executive Proposal this week.
  • Executive’s will resume on the 14th Jan.


  • 5 Greenlight polls are scheduled for Monday 10th January.
  • 9 MIPs Ratification polls are scheduled for Monday 10th January.
  • 2 Signal Request polls are scheduled for Monday 10th January.
    • Prioritizing Compound D3M.
    • Raise the Emergency Shutdown Threshold.


Weekly MIPs Update #68

  • The Formal Submission Window is now open and will remain so until and including Wednesday. Proposals that have fulfilled their 28-day Feedback Period and 7-day Frozen Period can be formally submitted into January’s Governance Cycle.

Forum at a Glance

Forum at a Glance: Dec 16, 2021 - Jan 6, 2022

Presentation: 2021 Recap, Metrics, and Looking Ahead

Check out the slides here.

Slide images will be provided in the semi-transcription summary (coming soon!)

Team-led Discussions


Updates, DssGate, and Future Parameter Management


Episode 173: January 6th, 2022


  • 00:00: Introduction, Votes, and Polls
  • 02:28: MIPs Update
  • 05:49: Forum at a Glance
  • 11:39: Presentation - 2021 Recap
  • 37:56: Discussion - Deco-001
  • 1:17:43: Conclusion



Agenda and Preamble



  • Hello, everyone, and welcome to the MakerDAO Governance and Risk meeting #173. This is our first meeting of the New Year. I hope everyone enjoyed their time off. Hopefully, everyone’s excited and back and ready to get back into Maker. I will do the usual preamble. We like to hear from people in this meeting, so feel free to comment or ask questions. We are recording, so try not to talk over each other too much. As always, be polite and respectful of other participants. This week, we have our governance roundup and a couple of presentations. We will look back at 2021 then take a brief look ahead to 2022. We also have a presentation from Deco on what their core unit has been doing; I believe talking about the DSS gate, which is one of the important smart contracts related to the fixed rate.

General Updates




  • 5 Greenlight polls are scheduled for Monday, January 10th
  • 9 MIPs Ratification polls are scheduled for Monday, January 10th
  • 2 Signal Request polls are scheduled for Monday, January 10th
    • Prioritizing Compound D3M
    • Raise the Emergency Shutdown Threshold


  • No Executive Proposal this week
  • Executive’s will resume on the January 14th




Weekly MIPs Update #68

  • The formal submission window for January’s Governance cycle closed on Wednesday, the 5th. We had 12 formal submissions. Let us do a quick review of them.

  • For these proposals that we have just reviewed, we will have the ratification polls going live on Monday, the 10th. If you think of having a yet unposted proposal entering this Governance cycle, you still have six days until January 12th. Before I close, I mentioned several recommendations in RFC MIP 16-61. Please give them a rate if you have not yet and leave some feedback. Thank you.

Forum at a Glance

Artem Gordon


Post: Forum at a Glance: December 16th, 2021 - January 6th, 2022

Video: Forum at a Glance

Team-led Discussions

David Utrobin

2021 Recap, Metrics, and Looking Ahead to 2022


  • Before I get us kicked off, I wanted to highlight the importance of looking back and recognizing just where the protocols started in 2021, where they ended in 2021, and the massive occurrences in-between. As Artem mentioned in Ace’s post, we have increased our revenues by 20 fold since 2020. But really, we progressed so much more than that. And this is an attempt to capture most of it. I missed in the recap all the core units that we have onboarded. So before I start on the first official slide after this, I wanted to say we have onboarded 18 different core units this year, which is Herculean.

  • Q1 2021 was pivotal. We had news of the Maker foundation dissolving. Likewise, as an ex-foundation member myself, internally, many of the people from the Foundation broke off. Some left, some started their own CUs, others became contributors. It was an extremely pivotal moment. For the life of Maker, we had the Foundation bootstrapping us. The real goal was to step back once the protocol was self-sufficient. I think that is what we will achieve in 2021. As a result, the Maker foundation dissolved, actually ahead of schedule, which is incredible.

  • With the dissolution of the Foundation, we also had the sunset of the development grants program. In its place this year, we have seen several different tools for doing grants through Maker, not through the Foundation. We have seen the special purpose fund MIP come about. We have witnessed SES, the core unit that does incubations and various grants, come about. We have also seen different core units doing their micro-grants and granting programs. Thankfully, Maker is still really healthy on the grants side.

  • Continuing their dissolution process, the Maker Foundation returned a huge portion of the debt fund holdings to the DAO, leaving themselves just a bit for operating expenses and whatever else. That was also a cool pivotal moment to see that good faith from the Foundation. And they were seeding Maker with what it currently has in its treasury, around 84,000 MKR.

  • In Q3, we had another awesome product innovation, the Aave direct deposit module, the D3M. The D3M is not exclusive to Aave. We consider other ways to implement the D3M mechanism to spread Dai’s prevalence in DeFi.

  • This has greatly improved our throughput in governance. Since the launch of this program, we have seen an incredible increase in efficiency for passing executive votes and discussing topics for bringing up issues. The spawning of this type of DAO member has been very pivotal to 2021 as well.

  • As a result of a lot of Governance action and a concern about the over-concentration of USDC-backed Dai, governance took many steps to reduce that. Including onboarding new PSMs. Factoring in the group that sets rates or proposes rates through monetary policy, trying to make generating Dai from non-stables a bit more attractive, etc. And as a result, USDC’s collateralization fell below 26% from its high of 55%. That was a great success story for diversifying backing collateral. But of course, it is back up to 45%. Thanks to this looming market crash. :hand:

  • Another pivotal thing we saw in Q4 is an infusion of vision by one of the cofounders of MakerDAO, originally Rune Christiansen. He published the case for clean money, advocating for a whole different class of collateral that should be prioritized, mainly ESG collateral positive for environmental impact worldwide. It is also a subset of real-world assets. And likewise, part of his vision includes a redesign of MKR tokenomics. And really, he proposed many exciting ideas that I believe many of us are still chewing on and thinking on and eventually hopefully will implement in an ideal sort of way. And I believe Rune is gearing up to post a refined version of this vision sometime this year.

  • Monkey Irish, the collateral engineering services core unit facilitator, is an ex-Foundation employee presented beyond the Maker Foundation, the past, present, and future at ETH Portland. And the reason I put this on here because I feel like his talk resonates with a lot of the people who went from being at the Foundation, centralized sort of company bootstrapping Maker to being an independently funded core unit, amongst many at a DAO. This transition from a centralized company to a decentralized organization is interesting. It resonates with me, and I think it resonates with many other core unit facilitators. We are really on the bleeding edge here. We give a huge pat on the back to people engaging and making a career out of their involvement here at Maker.

  • 2021 also saw the first few offboarding of collaterals. Business is business. Gas costs, particularly on layer 1, have gotten more expensive, leading to the offboarding of specific collaterals. This is important for the maintenance of the protocol, and it is important as a process to solidify and nail down.

  • We also had another amazing product innovation: the Maker wormhole official release. This breakthrough was designed to get around layer two and bridge deposit delays. It spawned this new way of thinking about getting Dai minted and efficiently transferred to other layer twos.

  • If I missed anything major, please DM me. We did try to cover most of everything. Let us move on to the next part of the segment. Here are some interesting Governance metrics that we pulled. If you are interested in where we pulled them from, you could go into the presentation linked in the forum agenda for this call. And you can go to the slide and click on those links below. They are great.

  • Another interesting thing is that the first poll in 2021 passed with around 67,000 Maker and 25 unique voters. The final one passed with approximately 80,000 MKR but with about half as many unique voters, 17. This outcome resulted from increased gas costs, which deterred many smaller voters from voting in every single vote. It was also affected by the introduction of the delegates. We have a more consistent cohort of people, albeit a smaller cohort voting. Many of these smaller voters who might have been voting themselves have delegated and entrusted various recognized delegates to vote on their behalf. And nevertheless, we are seeing a steady but healthy amount of MKR voting in the governance contract. But of course, one of our goals for the series is to increase that.

  • Looking ahead towards 2022, I wanted to ask what the focuses are for this year. Since 2017, we have evolved a lot as a protocol, as Maker. So we put these slides together because we took all of the various core unit updates and roadmaps. Then, we parsed them out and organized everything into the various higher-level initiatives at Maker, which GovComms is working pretty hard to map out.

  • The first big-ticket item is layer twos. MakerDAO has three different L2s focused on; Arbitrum, Optimism, and Starknet. In reality, it can get a lot more. We can get a lot wider coverage with layer twos with Wormhole, so I am very excited about the Wormhole.

  • We have operational security audits planned. This will help safeguard core units from hacks and exploits and ensure everybody is mindful about their OpSec.

  • If you have not checked out the risk dashboard by our risk core unit here at Maker, I highly recommend checking it out.

  • We also have special-purpose funds, which have not been ratified yet. There are a number of them in RFC leftover from last year. One of them is a legal fund, which provides legal funding for the protection of DAO members to fund the legal opinions and various other legal initiatives. We have a Singaporean jurisdiction study to source real-world asset deals from Singapore. And we also have RealDAO, which focuses on decentralized SPV infrastructure in the works. And I think one thing I might have forgotten about for growth is more videos, from content production on tutorials, how to interact with us, how to vote, basically how do we educate our would-be stakeholders to come into MakerDAO and participate.


Vasmi Alluri


  • Hey, everyone, I am Vamsi from the Deco Fixed Rate CU. I have a quick update on our work since our proposal acceptance in early December, particularly on a module that we have just finished designing and implementing. Later, when we launch, it can interestingly integrate Maker. We have yet to form a legal entity on the operation side, but it is underway. On the technical side, we have taken all the extensive feedback received on a proposal and are almost done with integration redesign. We have finished designing and implementing the DSS gate, which came out of discussions with the SES and PE team. During November/December of last year, priorities lay in teams like Deco getting involved with parallel smart contract development to lower the amount of work added to like teams (unlocking) and get work done faster (parallel development).

  • DSS gate sounds ominous and a little vague. However, a gate here simply means an access gate that opens an access permit. It is a governance tool to limit vats.suck integration risk. You may be asking why we are adding more stuff to governance by forcing governance to deal with vats.suck. We developed a small module that will further affect trade vaults integration. This is my take on Maker protocol control value and how we could use its standard to onboard more integrations. We took the SES project sandbox report recommendations published last November/December to deal with sensitive functions like vats.suck. We then condensed that into this DSS gate design, the design of gate high-level features, how governance could use this as a tool to make a protocol control valuable integration, and a couple of links to the codebase.

  • We classify Maker liquidity into two buckets: the ilk and the suck bucket.

  • One small mistake will lose the surplus buffer and suck, for example, 10 billion or 1 trillion Dai. Getting authorization to VAT to obtain direct access suck is also scary. Last year we talked to SES, and they mentioned that there is no way to get direct access to suck from MCD VAT because of the many risks. They suggested a sandbox that limits the amount of risk Maker is taking on. If the sandbox says the total suck limit is1 million Dai, there is no way DECO can access more than 1 million Dai using that sandbox. If DECO or the integration just gets hacked for like 100 million Dai, the sandbox would block it, saving the entire Maker protocol from that risk. We took that concept, and then we tried to implement it.

  • Any integration that needs access to suck needs additional upfront work into auditing the integration completely to ensure that it does not impose risks. The primary reason is that VAT has almost a binary approval process. When it gives access to a smart contract, it authorizes that smart contract to call all restricted functions and an unlimited amount of Dai out of that. DSS gate acts as an intermediary between that particular sub-call. A gate contract does two things. First, it implements a dollar amount as a type of token approval. Second, it implements a back-off balance.



  • Nikolaj Lollike: This is a potent design pattern, and it is excellent to see it being used now. It can also really help in terms of parallelization of work. As Brian wrote in the chat, the issue with adding new modules to the mega protocol today is the binary authorization system. If we grant authorization on the VAT, it has full authorization on all the functions and has no limitations. The written code limits it, but we need to extensively review and audit that code. If we want a lot of external contributions, the sandbox pattern is very powerful because we can limit the integration surface to the specific functions that integrators would need. We can also impose the certain limits that Vamsi mentioned, for example, a 5 million limit for suck.
  • We discussed this when I presented this exact topic to our team at CES. We will also look into doing some of this for collateral onboarding. When onboarding new collateral types, you are also messing with many parts of the Maker protocol that external teams cannot do. When building a spell, you have root access to all parameters. There are no limits to what harm you can do. When you are building a new adapter, you are getting authorization on the VAT. There are places where we can make a neat integration surface that can improve the overall security of the mega protocol and decrease the time to market. We will not necessarily need to verify every single line of code, and we can minimize the attack vector. If anyone is interested in knowing more about this, please reach out.


  • Vamsi Alluri: To answer Frank’s question in the chat, the right way to do things is one integration per gate. Although nothing stops ten integrations from practicing the same gate, the right way to deal with this is to deploy one for integration and then operate directly on top of the approval limits. This is like a lack of balance. A backup balance may not even be needed. Those decisions are to be based on integration.


  • Brian McMichael: How do the repayments work on this? Or do you envision this as a one-way suck?
    • Vamsi Alluri: The suck itself is one way. If integration has to repay it, they could transfer Dai to pause proxy. For the backup balance, you can essentially implement a withdrawal condition. Governance could load it up with 100,000 Dai and then declare it will only deal with this Dai at the end of the quarter. Before the end of the quarter, the backup balance cannot move. The integration can only access it, and the government cannot take it back. But after the end of the quarter, governance can now withdraw Dai back. When it is a backup balance, you do not use it as a primary one. The suck is one way, and if the integration has to give it back, it will push it out. We tried not to add any requirements on the integration to implement any of these limit checks. We replicated the suck interface so that the gate would look exactly like what we did to them. They would not have any else inside the integration to handle this.


  • David Utrobin: I have a question about how this relates to the DSS vest contracts. The DSS vest draws directly from the surplus buffer through the suck. If we were to upgrade the DSS best to include a DSS gate, it would create an intermediate step. Instead of sucking directly from the surplus buffer, it would suck from the gate contract. Then, the gate contract would hold that balance in the interim and consistently re-up it over time as it gets depleted. Is that the right way of thinking about it?
    • Vamsi Alluri: Maybe not. The goal is not to aid every single suck call. The goal is about things like joint adapters and DSS vests. These contracts can be audited once to ensure that the suck calls coming from these contracts will not do anything shady or high risk. You can create a contract that is already risk-limited. Once you create a website, it is about redeploying the same thing repeatedly to handle different payments. So, there is no need for the gate contract to step in again. A gate would not benefit from being between something like a DSS vest or joint adapter. Small and well-tested contracts can continue to use vat.suck correctly. This is more about, let us say, an integration like Deco that is a large protocol, from the Maker protocol perspective, is completely new and not sufficiently well tested. However, there is an opportunity to go through quick parallel development, fast deployment, and testing.
    • Outsiders can audit this vest contract. The question is how we get these large surface areas, like new smart contracts, from accessing vat.suck faster. The gate would be well tested and audited. Then, the actual protocol Deco could be audited down the road. However, it is almost like a chicken and egg situation. You will not be confident about Deco without testing it and accessing vat.suck. But then you cannot do that because giving untested protocol access is scary.
    • David Utrobin: To reiterate, simple contracts that suck calls like that are low risk. You do not need to do a DSS gate because it is additional gas and simply unnecessary. But the DSS gate enables you to integrate with way more complex external modules without worrying if those modules are 1,000% foolproof. You can limit your risks while also doing the due diligence of auditing mechanisms. At a minimum, you can limit the risk. That makes sense, thank you.


  • Christopher Mooney: Imagine Maker goes to a hackathon and gives everybody a $25,000 balance to implement their project. We can give out ten different projects access to this $25,000 balance. There is also a guarantee that they cannot mess with the systems accounting or break anything. We do not have to do a full audit. The idea is that some will prove themselves, so we then increase their balances. Eventually, we can find a more gas-efficient implementation to find a product-market fit. However, this allows for a lot more experimentation. The paradigm I was thinking of views the Maker protocol as an operating system terminology. It is like kernel space. We add many modules to the kernel, and we need a system call interface that limits the damage that userspace can do to the kernel. So DSS gate is like the beginning of that restricted interface into kernel space.
    • Vamsi Alluri: People have questioned if the plan is to eventually remove gates after a couple of years when the integration is well tested and give direct access to vats.suck. Having a gate will still help due to the backup balance feature. Direct access to suck means Dai can straight disappear. All Maker governance has to do is deny the integration address, and then it will be gone. This can be abrupt for integrations. They thought about that in a way for deco. The deco protocol has many obligations for the next three months if that happens. These obligations would not be new issuances, but they would still be a mess. The gate can still be a long-term piece of that puzzle in this sense. The ability for Maker governance to hit rock bottom at any time can be mitigated by governance locking up a backer balance. They could put a stamp on it and lock up 1 million that cannot be taken out until the end of the quarter. No matter what we do, you have access to a million. In that sense, a gate can still be a long-term piece for integrations that demand that additional trust lessness from the Maker protocol side. It limits investment risks not just like for Deco but Maker integration.


  • David Utrobin: How do we manage the overhead costs of the protocol in the event of something like a Black Thursday, where the surplus buffer goes negative, and we must mint MKR to raise Dai? There were ideas about taking out funds from the surplus buffer and holding them in separate pools to ensure continuity of operations. Like mine, I know some core units have an operational continuity wallet for three or six months of operations. I wonder if the DssGate can be used as a limiter to retain the 20 million or 30 million in overhead liquidity. It is kept in and does not get removed from the surplus buffer. I am thinking about how we can improve our safeguarding operational continuity in the event of massive losses while not relying totally on diluting MKR to fund operations after the fact.
    • Nikolaj Lollike: You could upgrade it not to use the gate contract. That is one of the reasons why the interfaces are kept the same. From a technical point of view, you could. However, I am not sure we would ever want an external protocol directly accessing suck.
    • David Utrobin: D3M is an ilk generator, right, not a suck generator?
    • Vamsi Alluri: Yeah. That entire class of ilk is deposit-like collateral and then your access limit. The debt ceiling acts as a natural risk limiter, but that does not exist for vat.suck.


  • Vamsi Alluri: Someone else commented the other protocol access to Vat seems like a recipe for a bad time. There is something like this in the protocol-controlled value meme in that it has been an under-explored concept here at Maker. If you can manage the risk, try a couple of experiments, and see what happens.


  • Nikolaj: I want to point out the concept of quantifiable risk. We saw that compound had that weird governance bug. The empty contract saved them as they could only siphon comp from a specific smart contract. This was not a mint function. This is an example of a sandbox setup because there was a limit to how badly it could go. It was a high limit, so it was not good. But that is essentially the same concept here. When we implement new modules, DeFi is moving fast. We cannot formally verify everything and audit everything. We could, but we would not be able to innovate fast enough. Here, we can quantifiably risk managing new modules such that even if, in the worst case, we can say we would lose 5 million and not cause an emergency shutdown. It does not mean that security goes out the window. But in general, being able to quantify risk is helpful. If we were to authorize external modules on the Vat today, it would be hard to quantify risk because there is unrestricted access to do many bad things.


  • Christopher Mooney: We could get through an audit, but it would severely underestimate the amount of time it takes to audit something safely. We saw this with Centrifuge. They had a whole liquidation module designed, but when we finally started cracking it open, we learned it would take us many man-hours and times to grok this code fully. So then, it just made more sense to limit it with the RWA sandboxing. It is the same thing. We will get a lot more integrations and set lower debt ceilings if we have these more restricted modules. This is not as easy to do with collaterals that have liquidations turned on because the liquidations can violate the debt ceiling constraint. You may think that you cannot exceed the debt ceiling. But if you have liquidations, you get a chance to remove that debt ceiling. The first-order collateral types of liquidations are not easy to constrain in this way. But there is a range of integrations that do not require liquidations or manage their own. And if they go through this one interface, we can guarantee that the constraints hold. We can then do all kinds of integration safely.
    • Nikolaj: We are looking into the cumulative debt ceiling in CES; I am not sure it will solve the problems. But it could solve the case you are talking about where you keep maxing the debt ceiling and take out more Dai even though it is liquidated.




  • We still got a few minutes left. Are there any final questions or comments anybody wants to as before we wrap up for the day? Any shoutouts anybody wants to do for upcoming meetings or anything like that?

    • David Utrobin: Yeah, I will shout out the calendars that we have. We have votes and an important dates calendar that you could subscribe to. It is a public calendar. It includes all the important MIPS cycle dates and the various votes, both like governance polls and executive votes. We have a second calendar for calls, including public calls like this and semipublic calls, like stakeholder alignment meetings. We have begun listing them in public. They are not public per se, but you can request. If you are a stakeholder and you see an initiative relevant to you, you are welcome to request access. Subscribe to those two calendars. They are very helpful. I will post the links in the chat.
  • Perfect. Thank you, David. I know we have had a bit of a presentation-heavy meeting this week. I am still trying a little more discussion next week. We also wanted to get some lighter topics for these calls from the recognized delegates instead of the court units. If you are interested and have an issue you want to bring up in the next meeting, please reach out to David or me before the end of the day Thursday. Thank you, everyone, for joining us today. I will talk to you all next week. Thanks, guys.

    • David Utrobin: Thanks, everyone. Happy New Year.

Suggestion Box

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


  • Artem Gordon produced this summary.
  • Larry Wu produced this summary.
  • Jose Ferrari produced this summary.
  • Everyone who spoke and presented on the call, listed in the headers.

The full call is now available on the MakerDAO Youtube channel for review: