Episode 152: Thursday, July 29, 2021
03:25: Governance and GovAlpha Update
06:22: Forum at a Glance
08:15: Protocol Engineering Team Update
21:16: Risk Team Update
25:31: Real World Finance Update
26:24: Growth Core Unit Update
33:42: Oracles Team Update
38:32: Sustainable Ecosystem Scaling Update
46:54: MIPs Update
58:53: Open Discussion
Agenda and Preamble
- Hello everyone, and welcome to the MakerDAO Scientific Governance and Risk meeting number 152, taking place on Thursday, July 29th at 17:00 UTC. My name is Payton Rose; I go by @Prose11 on the Maker Forum. I’m joined here by a bunch of awesome people interested in MakerDAO and how it’s running.
- We like people to get involved and ask questions or comments, so please, do not be shy if you have something to say.
- The executive vote passed last Friday. That was a day after last week’s meeting. The executive lowered the
flap auction bid duration and increased the DC on NS-Drop RWAs facility. There is a current executive vote currently up. Please, go vote. If you support adding the four RWA Vault types within it, then you should vote on that.
- There are also two ongoing polls. They are both community greenlight polls. One is for the Gelato-UNI-V2-DAI-USDC LP pair, and the other one is the Untangled Finance Drop token. Both of those close on Monday, August 2nd. These polls will help us prioritize the domain work that needs to get done for those tokens. The other polls which concluded on Monday were the monthly MIPs ratification polls. We will be going over those during our MIPs update with David.
- The only other Governance update I have is that this week will not contain an executive. We had a post in the Forum last week discussing the consideration towards switching to bi-weekly executive schedules. We have not decided on that. However, when speaking to the other mandated actors, we did decide that when we don’t need to put up an executive, it would probably be best not to force one up every week. An executive this week would have included some minor housekeeping changes from Protocol Engineering if there were to be an executive. We’re just going to go ahead and batch that in with the following weeks.
GovAlpha Core Unit Update
GovAlpha Weekly Update
- Our main update is the vote delegation. We’re essentially set to soft launch the UI for vote delegation on august 2nd. This means the UI will work. You’ll be able to delegate, but we’re not going to make a huge deal about it just yet because we still need to fix up some other things and improve the UI for the next version. Looking forward to that. The dUX and UX team have done a great job getting that setup and helping the first few delegates get themselves sorted. Huge thanks to them.
- We also had the first Meet Your Delegate meeting this week. It was on Wednesday at 18:00 UTC. That went super well and had a good turnout. We had @PaperImperium and @ElProgresso on there talking about the delegate platforms and answering questions. We will have the next Meet Your Delegate call next week at the same time on Wednesday, August 4th at 18:00 UTC. On that one, we’ll have @timblack and @Planet_X talk about their delegate platforms. We are all looking forward to that.
- The only other highlight I have is that I’ve assigned @Sebix the task of trying to sort out tags on the Maker forum. We use tags fairly often. In some cases, they’re good, but in others, it’s a little bit messy, and there’s quite a lot of them. Without some housekeeping, they tend to get a bit unruly. We will try and organize them a little bit and figure out what goals we are trying to solve with tags. More information on this as it comes out.
Forum at a Glance
Forum at a Glance: July 23 - 29
- Total DAI supply keeps hitting new highs, now at 5,4B
- At the same time, USDC is backing almost 61% of DAI
- System Surplus is now 49,2MM DAI and steadily rising
- The next Meet Your Delegate call is scheduled for August 4th. Make sure to join and find out more about future delegates’ platforms. This week, it’s Tim Black’s and PlanetX’s turn.
- The Risk Core Unit has published an extensive analysis on Maker Vault Activity Metrics with useful insights for risk analysis, business development, and growth.
Protocol Engineering Team Update
- The DssVest audit from ABDK returned. We had some stylistic changes, which we discussed and implemented. Formal verification is continuing to happen on that contract. It should be completed by next week. Just a reminder that the DssVest is not only how we may end up vesting MKR allocations to people but is actually the primary mechanism by which we’re hoping to compensate teams. Rather than passing an executive every month, we can do it once and modify it in this contract.
- Now, for a bit of disappointing news, the Sushi LP tokens, which I’m sure some people paid attention to FCC’s announcements around Sushi, are deploying a new AMM in one or two months. This introduces a bunch of custom changes for their LP tokens. It’s no longer the standard Uniswap V2 style token. As a result, there’s a lot of unknowns there. It’s not a complete loss; we were able to audit CropJoin, which is the basis of adding these types of tokens. This allows us to potentially move into the onboarding Compound without having to audit the entire thing. Also, we began working on the integrations for keepers to service these LP tokens, and part of that, by transitivity, adds Sushi collateral into the keeper code. We’re going to keep that development path open so that at least the demo keepers that serviced our options will have the ability to also do Sushi auctions. Aside from that, we’re going to need to wait until after their upgrade and reassess this. Many of our team are a little bit disappointed and are thinking about the correct path for integrations. In general, it’s much better if we can get integration partners to come to us, read our documentation, and write their integrations. We’ve had a lot of success with that. This was us attempting to do the integration for a partner, and in a way, we kind of got rugged by it. Obviously, there’s a better path for us to follow in the future.
- There’s a further development on the managed GemJoin adapter. These are the permission and permissionless Vaults, but more like conditional Vaults. We’re doing some updates and reviews on that.
- For the next week’s executive, we’ve got a bunch of house cleaning tasks. We need to update some of the RWA descriptors in the ILK registry because they’re not conformant with our other tokens. We also want to test a relay message that sends authorization and denial over to Optimism by command and control structure for Governance to send a message over to Optimism and make changes there. That’ll actually be cool to do. We may want to add this vote delegate factory for delegation into the changelog, so we’ll have to do that in that spell as well.
- We began playing with the Goerli testnet. A bunch of the team has local nodes running. We’re hoping to get the TechOps group to operate an archive node for Goerli, which will probably help FTX since it is a tool that we use in development. We’re hoping to have that available to us if we’re going to move over to Goerli. We also began deploying to Goerli; There have been a couple of hiccups, but we have at least one test deployment that made it all the way through. Finally, we are currently waiting for some general changelog updates.
- We’ve got a cool thing that one of the team members worked on for EDM bytecode programming, which is like writing an ERC20 implementation in the bytecode directly. It really helps us in some ways, such as if we need a particular extremely fast path set of code that will be cheap on gas to save us money. This will be a pretty cool skill set to have.
- We have a pending forum post for the spell postmortem. We had a session before this to discuss it. Also, I’m sure some of you guys have seen a forum post for the L2 risk framework.
- We’re accelerating the Optimism Fast Withdrawal Bridge design and discussion. We’ve had a couple of sessions this week and converging on exactly how we manage it. We’ll be discussing this with Oracle soon regarding the plan, but we have a pretty good architecture there.
- There’s also some ongoing work with the Arbitrum bridge. There’s work happening with Starkware to see whether we can get them to create a new independent Core Unit to try and bootstrap a Core Unit that will do all of this but on Starkware.
Meetings and Discussions:
- Nexo and Institutional Vaults are just finalizing parameters. There’ll be a post this week.
- Regarding Lido and stETH, we sat down with their team and discussed the Oracle design and other integration problems. I’ll give the high-level details of onboarding stETH. Between Oracles and Protocol Engineering, there were several sticking points where the design looked pretty risky and wasn’t great. It turns out they’re actively addressing some of the issues we had, and their team also alleviated some of our concerns about other aspects. Right now, the plan is to go forward with integrating them but with lower DCs and then to set a higher debt ceiling when this particular problem is resolved or when this particular risk is resolved. I think that’s at a high level where we ended up with them.
Questions and Comments
- Derek: Chris, I’ll just jump in with regards to the Starkwear idea here. That’s kind of been around for the last couple of weeks, and we really solidified it last week when we met the team. We met most of the team in Paris and had a really good sit down and a discussion. We walked through our L2 framework, we referenced the risk framework that we published late last week, we spoke about the multi-chain strategy and discussed this idea of how can we have parallel teams, how to build quicker and not only work on Optimism and Arbitrum with the optimistic roll-ups but also the ZK roll-ups that Starkware: hand and Cairo are operating on. We had a really good meeting with them. I will work with them to help them be familiar with the Maker ecosystem a little more. They will be a completely independent team. Therefore my role is to help them get up and running and understand how we work as a community. Then from that point onwards, as a team, we’ll help them with questions and things, but the idea is to have an independent team doing that work. Hopefully, we can present to you guys soon what their proposal will be. The focus of that will be the L2 Starkware opportunity. They also mentioned this at EthCC; they’re really keen to start doing this and kind of taking ownership and building with Maker. I’m looking forward to seeing that evolve. Hopefully, more news will come on that soon, but I will probably be leaving it to those guys as the face of that work, but I’ll help them get rolling in the background.
- Chris: Note the style of this arrangement is the opposite of how we made the Sushi arrangement. They’ll integrate with us rather than us trying to integrate with them.
- LongForWisdom: I have a question regarding Optimism and Arbitrum. I know they use the same technology, so I’m kind of curious how sort of plug and play is; for example, the DAI Fast Withdrawal Bridge is between Optimism and Arbitrum. Is it that once it’s ready to go on one, it’s ready to go on the other, or is it more complicated than that?
- Chris: There are lots of elements that will be the same. For example, our special kind of vault would produce this DAI for fast withdrawals, but there will be some L2 or domain-specific bits. Obviously, we want you to know structure the code in a way where we can reuse as many things as possible. However, the APIs for different draw-ups are different. They’re kind of similar in the sense that all of them allow you for generic message passing, but they’re different.
- Chris: Fast Withdraw Optimism is going to be the focus first. It’s already complete.
Risk Team Update
- We’re currently mostly focusing on the research and analysis of vault user behavior. @josolnik posted the Maker Vault Activity Metrics, which are more growth-based statistics. It can show the retention for users and how many users interact with Maker Vaults every month and etc. the next step is to produce a more risk-focused analysis which means we’ll try to combine these statistics with the type of operations of vault users. We’ll look at each user and analyze how well they’re protecting their vault and if they use any protection services such as DeFiSaver and so on. This should help us better understand the risk of Maker’s debt exposure for each collateral asset. It should also give us better insight into how users react to certain rate changes. This might require a bit more advanced statistical analyzers, but we try to address that as well.
- We have also finalized some simulations for lower LRs for Maker Vaults. The results currently suggest that we might lower LRs on good quality, lower-tier collaterals that currently have a 175% liquidation ratio. A bit of caution is advised here because at this compensation, due to the low rate, this spread between risk premium and various compensation from fees will only increase if we lower the LR. Luckily, we now have a much higher ratio of surplus buffer to volatile assets, and they should partially help offset these risks. We’ll publish this analysis and write about these concerns in more detail.
- Other than that, there’s a lot of ongoing work to automize all of these Vault user insights that we found, which we plan to address and put on our risk dashboard. We are also preparing a special kind of dashboard that will monitor dynamics and risks related to the Aave DAI market because we’ll need that once we integrate D3M.
- Finally, on the collateral evaluation side, @monet-supply will publish the G-UNIv3-DAIUSDC risk assessment. We’re currently going through the list of all the greenlight collaterals to suggest to other teams, along with which collateral could be evaluated next based on their DAI supply potential.
Real-World Finance Team Update
@SebVentures was unable to make the call today. He had a couple of things he asked me to highlight; The Centrifuge vaults are up on the current executive. Also, they put up a pre-MIP discussion on the RWA Foundations regarding the Cayman Islands structure that using for future onboarding.
Growth Core Unit Update
Growth CU weekly update
- We are talking with Paxos. Next week, they will be posting in the Forum the agreement we are arranging with them. Of course, they are excited about being included in the PSM. As I mentioned the other day, part of this agreement will not just add them to the PSM. Still, also, they will be adding DAI into their platform, which means that DAI will have access to all the APIs and the facilities that the Paxos platform provides. DAI will have access to the on/off ramps of Paxos. This is great because if a wallet or any centralized exchange or service wants to connect with our nano prompt solution, they usually have to go to Circle. They are the only platform that provides that service. And that means the platform will be using USDC. However, through this integration with Paxos, they could use DAI. This is great for Maker and the Growth team because we will use this new feature of DAI to initiate a discussion with different platforms to include DAI with these on/off ramps solutions.
- Stars of the week: DAI has been activated in Binance pay. With Binance Pay, you can shop with DAI or send money to friends and family worldwide. Binance will merge Binance pay with Binance P2P in mid-August, adding a flexible on-off ramp to the platform. Binance pay currently has 2 million users.
- Binance P2P is the most used on/off-ramp in different emerging markets within Latin America and Southeast Asia. It will be awesome to also have a solution, not just the on/off ramp, but also to pay for services, merchants and send money to everyone worldwide.
- Dai was part of the first NFT collection by Damien Hirst called “The Currency,” a collection of 10,000 NFTs that correspond to 10,000 unique physical artworks. Launched on the Palm network, a new Ethereum side chain that supports DAI. Jen from our team, who knows the most about art and NFTs, also talks with different artists to promote DAI as a currency between them.
- Also, there’s this project called SuperFluid that I would like to invite the Core Units to check out this project. It’s a way that you can stream real-time payments using DAI. It will be a good tool for us in the Core Units to start streaming payments to our contributors. Maybe we could arrange a call for the community to understand how SuperFluid works with DAI.
Tweet of the week. I invite everyone to follow us on Twitter. There are a lot of very good threads that explain what’s happening inside Maker. Last week, we spoke about the delegates.
Questions and Comments
- PaperImperium: I was wondering how we were involved in that art project. I’ve seen one earlier, but it’s not really important enough to discuss on this call.
- Nadia: Well, those detail will be with Jen. I don’t know if Jen is on the call. If not, I will ask her to include her comments in the Forum.
- Jen: Yes. This collection was launched through a platform called Palm.io, and they’re a newer sidechain. They have an NFT studio. They have this sidechain technology that supports DAI. Then they also have a team that is essentially working with big brands and well-known artists like Damien Hirst to launch the NFT collection. The great thing is DAI is one of the three tokens that are currently supported along with Bitcoin. We are the only stablecoin right now. As long as the artists and campaigns that choose to launch with Palm want to include DAI, we’ll have a lot of exposure to this kind of high-profile upcoming campaign, which is pretty cool.
- Nadia: This happened just a few minutes ago; Derek posted the institutional and long-term vaults in the Forum. We want to see all your comments because we want your feedback. We have been working with the Protocol Engineering and Risk team. Please check it at the Forum and tell us what you think about this type of vault.
Oracles Team Update
- Nik is out on vacation this week.
- We’re working on the Oracle Core Unit formation. The team is still working from the Foundation but will be leaving on August 30th. We will then be officially under the CU umbrella.
- We completed the deployment of our second transport layer called spire, which is based on LibP2P. The feeds can provide signed price messages to relayers using two independent transport layers, which gives us much more security. We will have another transport layer that will relay prices to the Oracles in an attack or bug. This is a huge achievement. Almost all the layers and the majority of the fees are now running on this.
- We deployed the smart contracts mainnet for the MATIC token. We will begin deploying the code to feeds and relayers within the next few days and then organize the onboarding of the MATIC collateral token.
- In addition, we will be making minor adjustments to data models. We are using UniV2 prices for some tokens and will be switching over to UniV3 due to the higher liquidity on v3.
Sustainable Ecosystem Scaling Update
- Juan: We have a new format this week. I asked for feedback from the other Core Units. People said that they found the updates relatively boring. I was a bit bored myself, so we decided to try this new format. Lenka is going to be showcasing a bit of what happened in EthCC. Lenka, give it away!
- Lenka: Apologies for the aesthetics. We agreed with Juan that this is something we need to work on, but I put quick slides for you just to zoom in on why we’re talking about Paris by presenting to you the achievements and significance of that event.
- In terms of the SES Core Unit, we had Juan, myself, and Layer2 presenting. Think of this as a big community reunion or a first-time meeting in real life for the Maker community after a long break due to the pandemic. That is the significance for the Maker community in general. We had our first trial of organizing an event as a DAO. It’s been hectic, but it’s also been really lovely and fun. Equally, one of the greatest achievements was sharing the story of MakerDAO decentralization and updates from the community.
- there has been quite a challenge from the foundation side to communicate everything that’s happening and at the root of Maker. Equally important is to raise awareness of Core Units as a concept in the community and among everyone who attended these events. In particular, for us, it was important to share what SES is about. We also felt that sharing about SES will help indirectly share about other Core Units and how we’re helping more Core Units to join the ecosystem.
- We also had many opportunities to connect with other projects trying to form a DAO. For instance, after Nadia’s talk at EthCC, she gave us a shout out and then I had an operations person from Shapeshift reaching out and discussing different challenges because they’re exactly in that situation as us.
- I’m also the project lead for X-Ray, a research project on talent onboarding and retention. I have been there with a mission to source people to do surveys and interviews for our study. Lastly, I’m also trying to hire someone for our permanent team. We’re looking for a data analyst, and I have a couple of leads with really good context. If anyone is interested, please reach out to us.
- On the last day, on Friday, we joined the DAOist with Juan, and I presented a short talk telling my story on how I joined the Foundation and then how I joined the DAO. It was meant to highlight the decentralization path, point out stories about the DAO, and share some lessons learned and the difficulties.
- We had a big success when it came to being present everywhere. We have pushed the SES and Core Unit narrative into the conversations and took some stages. It’s been really good.
David Utrobin and Payton Rose
MIPs Update #46
Presentations and Other Discussions
RWA prices, Oracles, and Liquidation Events
- Justin: I was just wondering if we could walk through an example of the RWAs dropping in value, what the Oracle process would be there, and then actually kicking off a liquidation event. What needs to happen, and how would that would play out?
- Payton Rose: Using different Oracles and a different setup from our crypto native vaults.
- Christopher Mooney: Yes, does it. We’ll see if that is justified at all. Regarding the price change, the prices on-chain are more reflecting the amount that we have loaned out. They’re not reflecting the amount of the asset. The hope is that the RWA facilitator of that team is somehow introspecting the actual solvency of these projects from time to time. They signaled to Governance that we either need to limit the DC or that we need to trigger a liquidation event. There’s a little bit of hand waving there on my part because I’m not entirely sure; it’s not really in the smart contracts domain regarding how that price update happens. Seth is out today. He can explain how that audit of the external assets happens. If anybody has something to fill in there, I’m happy to let you speak up right now. Otherwise, I can then sort of talk generally about what happens on-chain once we do a liquidation.
- Someone: I can talk a little bit about it. The general idea is that our RWF Core Unit is monitoring these every month. I don’t know if it’s different for different issuers. They are presumably looking through their financials and checking up on certain metrics. I think they’re generally provided to us by the issuer. I don’t know how often we go through the somewhat arduous task of auditing them ourselves. If they see that something’s wrong, presumably, we will talk about it in the Forum. It would require a Governance vote to either change the DC or, in a worst-case scenario, to issue a liquidation order.
- Christopher Mooney: I’m probably going to do a walkthrough of this for the PE team. I may end up publishing the walkthrough so that we could point you right at a video to describe it. The first big distinction is that there are two major RWA types right now. There’s the 6S RWA and the Centrifuge RWA. In 6S’ case, they were originally the reason we developed MIP21, which has several facilities to sort of liquidate or remediate a liquidation and then write off a liquidation. If 6S becomes insolvent or that there was a problem, they couldn’t repay debt. If we didn’t adjust the DC down to prevent them from taking more debt and instead decided that we actually needed to liquidate, we would call this
tau function, which puts them into a liquidation period. During that time, they’re still technically what the contract calls ‘good,’ and there’s a trusted company in the Real World that’s checking the on-chain status of whether or not they’re in good standing.
- Christopher Mooney: The trust company, in a way, behaves like a smart contract in the Real World. It has a certain set of guidelines it’s supposed to follow to the letter of the law. If they see this go into a bad state, 6S would have some time to remediate this and get some DAI back or something to get themselves back into good working order. If that didn’t happen, this function would return false. There’s a Delaware Trust Company that would end up liquidating all of the lending company’s assets and at some point returning those assets through the same facility that they currently have. We then pay down as much of the loan as we could until Maker knew that there was nothing left, at which point Governance would end up calling the
callee function, which is basically a write-off. It means anything that we didn’t get back gets accrued to bad debt. That eats the surplus buffer until we’re out of it and results in the
flop options or debt options to recapitalize the Protocol. That’s the MIP21 case.
- Christopher Mooney: In the Centrifuge case, they have their own on-chain liquidation. They don’t have that trust company that’s doing the liquidation. It’s all the same MIP21 adapter. We do the same exact thing; We figure out that they’re insolvent. We call this
tau function, which then activates the ability for the Centrifuge manager to take over and begin to call in the loan from DROP token holders. If there’s anyone from Centrifuge on the call, feel free to elaborate on that because, beyond that scope, the Protocol Engineering team is treating it the same as MIP21. We basically cross our fingers and hope that they’re going to liquidate appropriately.
- Lucas: I will try to jump in if you want me to.
- Christopher Mooney: Yes, that’d be great. Let’s say we’ve just triggered a
tau, and now we’re redeeming against Centrifuge. What happens in that case?
- Lucas: Our contracts have something in the system contracts that are called redemptions. Basically, an external investor, in this case, its Maker, wants to get their money out of the pool. We trigger this redemption on the smart contract, which then reserves all of the cash flows coming in from loan repayments. Like in NewSilver’s instance, this would be a repayment coming in from a loan that they have given out to a home or a real estate investor who bought a home and takes that payment to give it back to any investor who wants it redemptions.
- Lucas: The other place where money could come from to redeem these Makers’ DROP tokens is other investors who want to join this pool and invest money. At this point, what the pool will do is prioritize Maker to redeem their investments. On the legal side, smart contracts are risky, protected by a legal SPV that has a claim over individual loans.
- Lucas: Centrifuge’s assets work in the way that they’re pools of different assets and loans. In NewSilver’s case, it would be, right now, around 40 different properties in the U.S. those will be repaid, and Maker would see DAI coming in from that. That’s the high-level discussion. I can also point to the MIP22 that describes the legal and technical aspects of how this liquidation works in more detail.
- Christopher Mooney: For that MIP22 discussion, we decided to start auditing it. It was a lot of code, so they already had a 120 person hour audit on it. The DappHub guys, who are the team that originally wrote the Maker Protocol, at least the early versions of it, are completing the second audit.
- Christopher Mooney: People are looking at that codebase beyond our Protocol Engineering team to ensure it’s up to par and free of bugs and exploits. That liquidation mechanism, we didn’t plug directly into the Protocol right away because we couldn’t do that ourselves. In this case, let’s say we were able to sort of recapitalize enough of one of the Centrifuge assets or loans. We would simply call the I think the cure function, which is a way to say this has been remediated. If we can’t, then it’s the same thing in the adapters; We end up calling
callee, which accrues to bad debt. Bad debt goes to the surplus buffer. The surplus buffer goes down below zero. Then we have to hold debt auctions to recapitalize the system. It’s the same flow from that point forward. I know that was a lot.
- Someone: I’m just curious how a debt auction in Maker works with a Real World Asset if these loans become delinquent. We have to write it off, and we then have to recapitalize the Protocol.
- Christopher Mooney: Yes. It’s Maker holders that recapitalize the Protocol, which means Maker holders get diluted in that case. This is a natural incentive that MKR holders have because they don’t want to get diluted. They want to ensure they do their due diligence whenever setting up these RWAs and ensuring that they’re less likely to experience that. Aside from that, we’ve written the debt-off mechanism that is the same for any collateral in the system. It follows the same liquidation flow that the debt auctions occur, and it’s exactly what happened a week after Black Thursday. That exact flow is exactly what’s going to happen.
- LongForWisdom: It’s worth noting that one mechanism, whether that mechanism is triggered, is a system-wide thing rather than a collateral-specific thing. If the system as a whole isn’t open, then it triggers the auctions, right?
- Christopher Mooney: That’s right. We resolve whether or not the individual vaults are insolvent first. That’s what either in the MIP21 case for 6S, that’s what the trust company is doing for us. In the MIP22 case with Centrifuge, that’s what their codebase does by trying to resolve the specific vaults liquidity first. If that fails, then MKR holders are the backstop of the entire Protocol.
- Payton Rose: Much like regular crypto assets, as we mentioned, would get marked bad, and if it’s within the surplus buffer though, we won’t result in the dilution there, but rather than 40 minutes, the legal procedures might take much longer for us to recapitalize.
- Christopher Mooney: Right, which is why Governance has to call them. There is a sticking design flaw in my head. Keep in mind, this entire adapter is the first version to learn how to do this better. I’m afraid that if we did end up getting there to the point where we needed to write the debt off, that MKR holders are the last party that would be inclined to actually call the write-off function because it’s going to dilute them.
- Christopher Mooney: There may be a way to make that call permissionless or determine if it’s permissionless, but I haven’t found anything completely satisfactory yet that calls that permissionless that Governance couldn’t then just take positive action to stop it from being called. Governance has a lot of power, so they could probably stop themselves from getting diluted. It’d be nice if that train left the station and Governance actually had to intervene to stop the write-off. Whereas it’s designed today, Governance actually has to vote to do the write-off, which I think is not the right incentive structure. We should fix this problem.
- LongForWisdom: For what it’s worth, I agree. It should be automatic and then convince us to take positive action to stop it.
- Christopher Mooney: Right. Kurt brings up a good point; Governance doesn’t call that function to get diluted. They’re basically putting the losses on DAI holders. That will cause a lack of confidence in DAI holders. In a long-term view, Maker holders are still incentivized to call that function correctly. It would just be better if they didn’t actually have to vote for it.
- Lucas: You think that if you have confidence in DAI collapses, then there’s the confidence that MKR token collapses shortly after that. It’s still clearly long-term value destructive for MKR holders to not call that function. I agree it would be better if it didn’t rely on them taking action. I don’t think it’s accurate to say that they don’t have an incentive to keep the protocol solvent.
- Someone: I do want to caution that perhaps being automatic might be overkill just because, ultimately, what matters is the solvency and not the liquidity of Maker to meet its ongoing obligations and ensure that DAI is adequately backed system-wide. We could probably imagine scenarios with a negative surplus buffer but would not necessarily require triggering dilution. Just more complex stuff to think about.
- Christopher Mooney: For historical context, there’s a slight discussion in the sidebar. After Black Thursday, I think the SinQ time was around two days or something, which was going to be, I think, maybe in the middle of the night on the weekend. We didn’t think it was going to be a great time to recapitalize the Protocol. MKR holders did step in, and there was an executive to extend the exact point at which the dilution would happen at East Coast office hours or something like that. There was time to drum up support for purchasing these MKR in a
flop auction. MKR holders have actively intervened to extend the exact moment when the write-off happens, which is the equivalent of leaving this thing for permission for only Governance to call it.
- Lucas: As long as the delay on enacting a Governance action is shorter than whatever the time it would take for that debt to go from being marked as bad debt to actually debt auction starting, orders have various route powers over the system. I won’t get into the exact technical details. Still, they could revoke authorizations or replace contracts and completely change the rules of the system to ensure that whatever debt auctions don’t happen at all, even if they came from normal collateral auctions that were permissionless liquidated and then not properly recapitalized. In other words, they always have the power to stop there, right now, anyway. In the future, you can build out layers of authorization protection on the system to completely prevent that. The flip side of that is then you can’t change it if there’s a bug. That’ll be an evolving discussion throughout the Protocol’s lifetime. at what point do you switch certain things to be unmodifiable versus leaving the modifiable so that you have maybe slightly fewer security guarantees against MKR holders misbehaving, but you can fix bugs?
- LongForWisdom: I agree. In general, it’s what Chris says. It’s silly for Maker holders to not do that. It depends a little bit on magnitudes. I can imagine a situation where the end of capitalization is super small. We just thought, well, you know what, they’ll recapitalize it in like a few weeks, and then we just don’t do it. Likewise, if it was massive, I can see people wanting to press the button. I can see some weird cases where people maybe would not want to, but yeah.
- Lucas: It is far enough that it might be covered by a surplus buffer, or if it’s really that small and maybe you do the math, and it’s like, oh, this is four weeks of stability fees or something.
- Payton Rose: Yeah, pushing the button is a one-way operation. You would need to deploy new collateral if you wanted to recover from them.
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
CU: Core Unit
- Artem Gordon produced this summary.
- David Utrobin produced this summary.
- Jose Ferrari produced this summary.
- Queensphine produced this summary.
- Everyone who spoke and presented on the call, listed in the headers.