Operational Support Update
Operational Support Weekly Update: March 22- 24, 2021
- We want to provide more visibility to different core units. We’re launching tomorrow with real-world finance. This is a space where existing core units can detail information and take questions from the community on what they are doing. We’re happy to make one with you.
- We had a declaration of intent on EURO-DAI. The KYM number 6 last Friday with Seb and ultraschuppi went well.
- We had a call yesterday with a SolidBlock. 2 weeks from now, we will have MCO2, which neutralizes carbon emissions.
- Monday, we will have a call with David on the Governance Communications Core Unit. On Wednesday, we will have Sustainable Ecosystem Scaling by Wouter and me.
- Amy posted the representative of working groups. This will help those less connected regarding the Maker compensation working group LongForWisdom had posted.
- LongForWisdom: We are waiting to fill in the third-party slots, and then we will begin.
Community Development Team Update
- For the last couple of months, our focus has been wrapping upon many projects, including navigating the transition from community development as a department bootstrapped by the foundation to people and projects transferring over to the DAO.
- I will spotlight a few projects today.
- One of the contributors in community development, Shea, has been working on the community development portal. Many illustrations have created a project called brand assets which takes inspiration from foundations branding. However, we made our own to use for the community. Shea created a document where anybody can create graphics. There’s also a PowerPoint presentation, including instructions.
- The community development portal launched a Maker Community Blog where anyone from the community can contribute to.
David Utrobin / Charles St. Louis
April MIPs Inclusion Review
- Last week’s MIP inclusion polls have all passed and will continue through next week’s monthly Governance bundle poll.
Emergency Shutdown Module
- LongForWisdom: We want to discuss the emergency shutdown module MKR threshold in more detail. For those who don’t know, this is the amount of MKR required to trigger an emergency shutdown in the protocol. It’s currently set to 50,000 MKR. It’s useful if, in the event of a Governance attack for MKR holders gracefully shut down the protocol. It’s useful in minority threats encouraging Governance to reach a consensus on some things rather than leave a significant part of MKR holders unhappy. In the past, it has been a backup in case there’s any critical bug that we weren’t able to safely fix. Smart Contracts team can discuss this more, especially around Liquidations 2.0.
- Chris Mooney: I’ll take that invitation. Tomorrow we are planning on releasing a forum post that discusses the ESM. We have to update the ESM as part of the Liquidations 2.0 update. For the end to function properly, it needs to be able to yank existing auctions. We will update the ESM, and since there are no administrative functions on the ESM, this seems like a good time to update the amount of MKR in the threshold. We could do it at a different time, but we are already making these changes. Therefore, we may do it tomorrow. That’s the general point of the discussion. Does anybody want to weigh in on that?
- LongForWisdom: When you stated that it has no administrative functions, do you mean to change the MKR value? Would we need to redeploy and replace the contracts?
- Chris Mooney: Yes, that’s right. The module itself is extremely pure because there is no Governance ability for us to change anything in it. Because it is partly intended to be used in a Governance attack, we have to pre-deploy it with the values we want. If we were to do that, we have to update it for Liquidations 2.0. We would then also update it if Governance has decided they want to change the MKR value.
- Brian MacMichael: This is something that came out of the mandated actors’ call and maybe a little bit of risk, as well. Due to the spell being tomorrow, there’s no chance to go through a full Governance cycle. I don’t think anybody has any opposition to raising the MKR threshold. It’s very expensive, but the number of assets under management is greater than when we had deployed the system. We would like to know if anyone has strong objections against raising the threshold, in which case it would have to go through a full Governance cycle.
- Kurt: Just to add a little color on how to think about this threshold. This is one of the most complex and hotly debated areas of Maker protocol Governance game theory. You don’t want the threshold set too low because then it’s too cheap for somebody who doesn’t like the system or has a big MKR short to come and cause chaos and shut the thing down. On the other hand, if you set it too high, you might have trouble rallying that amount of MKR in an emergency scenario where it needs to be used. One of the purposes is as an honesty minority can shut down the protocol and protect it from a Governance attack. It doesn’t make sense to set it to an amount of MKR that’s more than half of the circulating supply. That module would be pointless, then. It’ll be weird to raise the threshold as the MKR price increases. Usually, you would think that it would go in the opposite direction. One way to go about trying to set it is to target a certain amount for security. There are other considerations such as MKR distribution and considering how many large individuals it would theoretically take, etc. It’s something that requires careful game-theoretic consideration, and that’s why it tends to be hotly debated.
- Primoz Kordez: @Monet-supply from our side recommended this threshold to be raised to 75,000 MKR. I think it’s a good value because we see that the amount of MKR bought on borrowed is currently 50,000. There are, of course, downsides to increasing very high. As Kurt said, it’s mostly related to how quickly we can trigger an emergency shutdown. I believe that we have recently shown that we can get some MKR activated very quickly through a bit of campaigning. I think that the 75,000 MKR threshold is good. I even think a 100,000 could work, but it will be more difficult if we need to react, for instance, within an hour or so. This issue concerns knowing who the biggest MKR holders are, how quickly they can react, and how we can reach out to them. Monet-supply also suggested preparing a continuity plan to give us a better idea of the appropriate amount.
- Monet-supply: My post was fairly long-winded. The idea is we need to find the correct balance based on evidence of MKR threshold vs. safety. The obvious threshold for that is the amount of MKR you can short. Suppose an emergency shutdown happens out of the blue. In that case, the token might be worth hardly anything at that moment, so we need to find the balance between making sure that it’s more than you can borrow on AAVE and other places but also low enough where we can actually reach the threshold. Figuring out what’s too high involves testing a regime for some of these emergency situations and implementing those who have significant holdings who want to participate. We need to be professional with emergency shutdown testing. That is something I’ll be working on in the next couple of weeks.
- Brian McMichael: For those that are not familiar with the ESM, it irrevocably burns the MKR that’s depositing to it. Even if someone borrows the MKR, they are committing to burning that MKR forever. In the case of a shutdown, if we were to redeploy the system and the burner or if multiple burners were honest participants, we would be able to mint back to those people.
- LongForWisdom: It’s worth noting the potential shorting situation. Anyone making a short attack would need enough MKR to sell before triggering a shutdown. They need to have enough MKR to lock in the contract and more MKR to sell to profit. I don’t know how much that would be, but they would need an excess of the ESM amount, probably by at least 10 or 20%.
- Monet-supply: You need to have enough MKR tokens to trigger the ESM, but you could short pretty much everything in DeFi based if Dai blows up. You need enough MKR to trigger it, but there are innumerable ways to profit from Maker blowing up.
- LongForWisdom: I agree. You need the capital to trigger the shutdown and also to spend on the shorts. However, there is an absence of heavy opposition. We are going to conclude that the increase to 75,000 is in the Liquidations 2.0 update. As Brian said, it does skip the regular Governance Cycle, but it saves us a little bit of time. We had the off-chain Governance poll that supported the increase. We also had the report that @monet-supply produced, which suggested 75000 to be a good amount.
- Kurt: There is a strong argument that you should aim to be higher than what someone could borrow on the market. With the MKR supply up to a million, being at 7.5% of total supply, seems like a reasonable threshold.
- LongForWisdom: I agree. I don’t see a problem with it being 75,000. We could rally up that MKR if we needed to in an emergency.
- Christopher Mooney: Yes, we technically just did.
- Kurt: We want to think about having some sort of voluntary opt-in like a pager system for big MKR holders who want to be on call. Their availability is the hardest part of getting the ESM triggered in time. Hopefully, you have a Governance delay of two days as for most cases. For extreme cases, if it’s an oracle attack, you may only have an hour. In which case, it might be better to use the oracle freeze module, but you still need to rally enough MKR holders to overtake the
hat, which could lead to even more MKR. The DAO should think about having an organized system to send out an emergency alarm and be able to get sufficient MKR liquidity online ready to act in a short time frame.
- Wouter: That is something that may be in scope for a new Core Unit proposal.
- LongForWisdom: This is something that we are going to start looking at in Gov Alpha. We will try to put together emergency contact details for some of the larger MKR holders. As you said, this will be important going forward.
- Kurt: Ideally, you would have a broadcast system that people could subscribe to. Privacy would be respected, of course.
- LongForWisdom: Yes. that would be ideal. It would just be a matter of contacting large MKR holders and getting them to sign up.
- Wouter: One of the challenges is not the only situation we might want to set the alarm for. For example, Liquidation events happening on-chain to do with other signals that indicate suspicious behavior. That might need different responses from different people. Looking a little bit further ahead, it will be good to have a service that allows different profiles of responders to subscribe to different alarms. One that I think will come up soon concerns minor expectable value alarms where you can compare the distribution of blocks that are being mined by different miners to the distribution of MKR transactions that are being mined. These are all examples of various alarms that may require different responses. It would be nice to have a service where you can see these scenarios and subscribe to the ones you would like to help with.
- LongForWisdom: That’s a fantastic idea.
Liquidations 2.0 Module
- Payton: I have a question regarding the Liquidations 2.0 Module. Looking into many newer auction-based methods for making token sales or trying to avoid the MEV problem, many of them are similar to the Liquidations 2.0 parameters. I’m curious about how simple it would be to decide to mint and sell MKR or do an open market operation? Could we use the Liquidations 2.0 framework to achieve the fundraise? In this case, could we reverse the tokens if we take Dai for collateral while trying to get MKR?
- Brian McMichael: There are a lot of patterns out there for the Dutch auction-style. We would not be able to use Liquidations 2.0 because it’s so tight to the existing Vaults. However, there is plenty of precedent torque for Dutch auctions if you want to perform a capital raise.
- Christopher Mooney: Are you speaking about collateral liquidations or about surplus and debt auctions?
- Payton: That is interesting. I haven’t thought about surplus and debt auctions. We were having the minting vs. not minting argument. Having a way to buy in an open market would be important if you try to avoid minting.
- Christopher Mooney: Yes. A further off-plan is to shift these
flap auctions to something similar to the Dutch auction mechanism. We could do the same with
Flop auctions start out a little high. Therefore, we pick a different starting price for the
flop auction, which is wildly low at this point—that may be a parameter that we should consider updating. The downside is that both of these auction types kick off from the Vow, a hardcore contract to change in our system. we are much better off doing collateral liquidation and seeing how this stuff performs. There is a yearly horizon plan where we hope to replace the Vow and get features like having
ilk specific sin cues, which are the delays between
flop auctions. We also want to add the Dutch auctions into
flop auctions for the surplus and debt auctions.
- Payton: That’s awesome! I had no idea. Cool!
- Christopher Mooney: The whole team needs to do something not auction-related for a few months at least!
- Payton: I wonder why! Hint: CropJoin.
- Nik Kunkel: We’ve got the audit now.
- Christopher Mooney: Yes, that was in my update. We are looking at CropJoin right now.
- Nik Kunkel: There were no major issues found in the audit. We saw a couple of rounding errors, and everything else is cleaned up.
- Brian McMichael: We have these little things that shouldn’t take very long to get out the door, such as the
keg, the flash mint, and things like that which we pushed off for Liquidations 2.0. We will still be working on Liquidations 2.0 for the next couple of months. We will be getting these piecemeal out of the door every week. The spells involved are quite large. We’re not going to be able to do them all at once unless we can figure out a pattern for multi-part spells, but we might be rolling these out two or three at a time until we get up to speed.
CropJoin, LPs, and v3
- Payton: Concerning CropJoin, are we looking for the Sushi implementation, or does the audit work for something like Compound?
- SamM: Compound is more complex than Sushi because it relies on recursive leverage. We want to go with Sushi first, but it could pave the way for implementing Compound.
- Christopher Mooney: It’s an extensible base class. Therefore, it should be easy for us to take advantage of other types of Crops; we just need to write the code on top.
- Brian McMichael: We found a good market fit with these Uniswap LP tokens. However, v3 brings some concerns with loss of liquidity. Sushi doesn’t plan to upgrade, which will give us plenty of liquidity.
- Nkunkel: Balancer, Bancor, and other similar tokens will probably follow their own unique growth instead of copying each other or copying Uniswap. The Uniswap v3 did screw us over, but I am optimistic with LP tokens over the long term.
- Brian McMichael: This doesn’t mean Uni v3 won’t work. We need the community or Uniswap team to standardize a token version of their new model if we cannot use their official model.
- Nkunkel: It’s also about liquidity being actively managed in v3. Suppose somebody submits a huge order that absorbs all the liquidity in a person’s position. In that case, that can cause people to end up all in one token. A lot of LPs are removing their liquidity or temporarily performing infinite bound liquidity. However, tokenizing a particular LP range will require knowing the most efficient range width. Too small of a range will cause a loss of uniformity. Too large will risk more capital efficiency.
- Kurt: As the market figures it out, passive strategies will naturally come out and become implemented by the community.
Links from Chat
Common Abbreviated Terms
CR: Collateralization Ratio
DC: Debt Ceiling
ES: Emergency Shutdown
GF: Governance Facilitator
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
- David Utrobin produced this summary.
- Artem Gordon produced this summary.
- Sai Teja produced this summary.
- Gala Guillén produced this summary.
- Everyone who spoke and presented on the call, listed in the headers.