[Agenda/Discussion] Scientific Governance and Risk #148 - Thursday, July 1 17:00 UTC

Agenda

The zoom waiting room will be on, and a password is set to: 748478, please ping us in chat if you aren’t let in from the waiting room. This Agenda will be updated over the following week leading up to the call as people make me aware they want segments.

2021-07-01T17:00:00Z

Introduction

Weekly Updates

I’d encourage those listed to try keep this to 5 minutes!

Segments

  • Nothing planned

Discussions and General Q&A

  • Delegation
  • An anonymous Question Box is now available! Leave your question here and we’ll try to address it.

Episode 148: July 01, 2021

Agenda

  • 00:00: Introduction
  • 01:03: Governance Update
  • 02:48: GovAlpha Core Unit update
  • 05:16: Forum at a Glance
  • 08:10: Protocol Engineering Team Update
  • 16:15: Oracles Team Update
  • 19:21: Risk Team Update
  • 25:24: Real World Finance Update
  • 32:00: Growth Core Unit Update
  • 43:29: Sustainable Ecosystem Scaling Update
  • 48:24: MIPs Update
  • 52:34: Monthly Governance Cycle
  • 57:46: Delegation

Video

https://www.youtube.com/watch?v=t4wP2_82iMo

Introduction

Agenda and Preamble

LongForWisdom

00:00

  • Hello everyone, and welcome to the MakerDAO Scientific Governance and Risk meeting number 148, taking place on Thursday, July 1st at 17:00 UTC. My name is LongForWisdom. I am one of the Governance Facilitators at MakerDAO. Along with our usual updates, we will spend some time discussing delegation. There was a discussion about that last week which was cut short.
  • Please feel free to interrupt, or ask questions, or make comments. We like to answer lots of questions and things.

Weekly Updates

Governance

LongForWisdom

01:03

  • The executive from two weeks ago has not yet passed. It needs 500 more MKR. With every likelihood, it will pass, either today or tomorrow. Then we’ll be all clear for Friday’s executive. If you haven’t voted already, consider doing so. We also had only one poll this week, a parameter change proposal from the MakerDAO Open Market committee, proposing many rate cuts. That poll passed on-chain and will continue to the executive this week. This week’s executive will have a couple of things; it will have the Core Unit budget payouts for July. It’s going to have the Debt Ceiling Instant Access Module activation for the PSM. We will put in the activation for the Flash Mint Module, DssVest, in there as well. That’s a brief update on where governance is at for the DAO.

GovAlpha Core Unit update

02:48

GovAlpha Weekly Update

  • I have a very brief update on the GovAlpha. Our Core Unit had a fairly productive week. This is nice given that recent weeks weren’t so good. One of the highlights is that we’ve been adjusting the executive and polling processes to make them more decentralized. I am, to some extent taking credit for other people’s work here. Big thanks to dUX and Derek from Protocol Engineering and Dimitri from Tech Ops for helping put this together. We’re moving some of those processes away from the Foundation; they’re mostly separate already. Still, the Foundation managed some lingering bits, but not much longer, which is awesome.
  • We are moving forward towards delegation, which is awesome.- We also put together some initial templates for delegation. Prospective delegates can now have position statements. We’ll make them public altogether so we can generate some discussion. We’ll potentially start a “Meet your Delegate” type meeting, either next week or the week after.
  • The final update from GovAlpha is that a new version of the MIPs portal has been pushed to production. This is mostly thanks to Pablo from GovAlpha and D-spots, working on the front-end on the actual site. The update should bring a more polished UI, layouts upgrades, bug fixes, and improved server infrastructure. Looking forward to seeing that go live.

Forum at a Glance

Elihu

05:16

Forum at a Glance

Three-Point Summary

  • A record 5.4 billion DAI is in circulation.
  • System Surplus Buffer is at 47.3MM DAI.
  • Total Value Locked in Maker is $9.5B.

Announcements

Discussions

Signal Requests

Protocol Engineering Team Update

Christopher Mooney

08:10

  • The Optimism DAI bridge was in the final review. We completed that for test deployments, and we’re waiting for the official launch date from Optimism. However, I believe that sometime today, they are going to take our deployer address and whitelist it so that we could deploy. In any case, we’ve got a loose date to deploy that bridge on Optimism tomorrow. We still don’t know what their launch date is, however.
  • The D3M is complete, but it’s not an immediate priority; it still requires a little bit of review. The SushiJoin adapter is complete as well, but we’re waiting on the Sushi team. Sam had said it might be roughly another three weeks before they pick up to where they thought they were going to be. Tal did a technical evaluation on stETH, and the spell just passed. It looks like we’re going to get Flashmint.
  • For testing, we did the final Echidna and audit testing for the L2 escrow. We’ve started using Cortera; They have a whole toolset for formal verification. We’re starting to use that tool for verification. We have the ESM post mortem for discussions and documentation, which will probably be published later this week. Then there’s also on the tail end that we discussed a MegaPoker post mortem which is not a system-wide post mortem; it’s just that the MegaPoker wasn’t poking a particular collateral type for a while, and we discussed that we may or may not end up publishing that. We’ll have to see.
  • We defined the expected ranges for many system variables—all of the expected magnitude ranges and quantities. Everyone interested in that should review it. Thanks to Kurt for putting that together. We also discussed the Oracle tail risk mitigations, which may involve liquidations 2.1 or exactly how we deal with liquidations 2.1. Again this isn’t necessarily in Oracles; it’s more once we’re past all of the Oracles, what do we do if we ingest a bad price? What do we want the system to do? That’s all I had on my list.

Questions

  • Brianmcmichael: I should mention we’ve looked into this Gelato token. Sam had a forum post trying to expedite it. Once it’s live and audited and everything like that, we can move quickly.
    • Chris: Speaking of Gelato, their team may have also put their hat in the ring to work on the sort of DssCron which we cycle back to that MegaPoker post mortem. There are many little edge keepers that the Foundation used to run. There’s a nice way that the protocol could incentivize the running of those keepers through DssCron or something to that effect. I think Gelato might take a stab at trying to implement it.
  • LongForWisdom: Greg asked in the chat if there’s a place to see the roadmap for what Protocol Engineering is doing?
    • Derek: We’re using Github. We have a kanban board, but there are many things in there that are either working with partners or other third parties that we wouldn’t want to make public just yet. My original plan was to have that board fully public so that everyone could see it day-to-day, but we’re not quite there yet. There was a good question that PlanetX raised today; It was “what’s an innovation pipeline and could that be something that we share, and there are thoughts around that?”. I think that would be something I want to take a stab at and present a broader, longer-term view of the things that are on the table. I want to get the day-to-day stuff to a point where we can do that as well, but I’m not quite there yet, Greg. Is there anything in particular in terms of collateral onboarding, specific items, or anything else that you’d want to see more visibility on?
    • Greg DiPrisco: No, I was just generally curious. Not that I don’t like the surprise bombs in the forum.
    • Derek: That’s a good question, Greg. I’ll try to consider how I can make those week-to-week things that we work on a little more visible. We have planned meetings on a Monday, which gives a good overview of what the team is focusing on for the next couple of days, who will be writing a spell on Thursday/Friday, who’s reviewing it, and some of the processes around the team. Let me give that some thought to what I can make more visible; ideally, I’d like to take the kanban board as it exists and extrapolate that automatically so we don’t have multiple sources of truth. Let me give that some thought, and I’ll see what we can do.
    • BrianMcmichael: We do have a backlog of Governance-approved technical MIPs that we’re working on. I don’t know if we’ve got a good priority list of that. We’ve been working with GovAlpha to publish something like that, but we also need to remain dynamic when things pop up. If spontaneous opportunities occur, we need to be able to pivot to those too.

Oracles Team Update

Nik Kunkel

16:15

  • We have been mostly working on the back-end. We are happy that the Oracle Core Unit polling vote passed; Thank you. But now is crunch time to get all the legal entity stuff set up and the contributor legal mumbo jumbo out of the way. That’s been keeping us pretty busy. Marc-André has been heading up the new pricing tooling called Gopher that I mentioned on last week’s call on the tech front. The way it’s structured is that there’s a phased rollout. Because this is completely new tech, we wanted to be very careful if we saw some errors in production that wouldn’t take the whole Oracle network down with it. We had a minority of stakeholders upgrading, and it’s been running incredibly smoothly. We’ve seen many price updates for the Oracle update; it’s already taking into account these new price updates from the new tooling. We’re in a comfortable spot to do the remainder of the migration now, which is ongoing. We have the Spire upgrade in the pipeline, which is this alternative peer-to-peer networking type of layer. That’s going to be coming out shortly as well within the next couple of weeks. We’ve been testing that internally for quite some time now, and that’s meant to be not an alternative to Scuttlebutt but more of a substitute. The two will be running in parallel. If there are ever any issues with one of them, the Oracle feeds will jump to the other. We should be finishing up both of those migrations within the next month or so. I wouldn’t call it version 3.0, but it’s version 2.5 because it’s much more resilient.

Risk Team Update

Primoz Kordez

19:21

  • Once we have the Vault deployed and Oracles tested, we’ll likely propose to increase DC to a higher value, potentially up to 50 million and more. We just published two collateral evaluations recently, one for stETH and another one for Polygon. For stETH, we proposed a bit lower DC of 5 million Dai because Oracle suggested that we start with a lower exposure because Oracle implementation is not that straightforward. But then again, it depends on community appetite towards this asset, which, of course, has certain counterparty risks. We also proposed a higher liquidation ratio of 160% because we believe this Vault might have high demand. If we increase the DC, we’ll probably have more capacity to increase the ceiling if we have a higher liquidation ratio. There are also still some liquidity concerns around stETH. Most liquidity is incentivized by Curve pools, which was another reason we proposed a bit higher liquidation ratio than ETH-A, which has a similar market risk profile.
  • Another evaluation was posted today for Polygon, previously known as Matic. Our new team member, Sean, helped us make this evaluation. It’s really good to see the team growing, and happy to have Sean on our team. The proposed parameters are pretty standard, similar to what we have for other similar market profile volatile tokens. Hopefully, we see some demand. The token is on-chain liquid, and we can afford to increase DC, which was currently proposed to be 10 million Dai.
  • There’s ongoing work on D3M. We’ll probably have the valuation finished next week. We’re spending a bit more time assessing the credit risk and liquidity risk of the Dai market on Aave V2. An interesting finding so far was that Dai’s credit risk is much smaller than we thought. A few numbers might be interesting for the community to hear from the competitive standpoint; Aave V2 Dai borrow amounts, so the aggregate amount is about 1.2 billion. However, when you look at what kind of positions these are, these borrows are mostly recursive stablecoin leverage positions that people make to maximize liquidity mining rewards. The actual organic Dai borrow amounts are very small. When we say organic stablecoin borrow, that’s stablecoin borrowing collateralized by volatile assets and not by stable coins. This number is much smaller, amounts to only 150 million Dai. That is this only 13% of this Dai debt that we observe for now is actually organic and potentially unsafe in market drop events. That’s positive news from a risk perspective for D3M. Still, it also tells us that competitors are much smaller in organic usage. This was something really interesting.
  • There’s still ongoing discussion on Institutional Vaults. I think we’re now calling them Conditional Vaults. Growth, we and Protocol Engineering are looking at making this offering available fastest by simply using the current Vault parameters we have, not making a whole MIP process, which might take too long. We are also preparing some simulations to test for lower liquidation ratios for all the Vaults because there were some ideas and questions on how potentially lower liquidation ratios would affect the risk profile at Maker if we wanted to boost Dai supply in such away.
  • There’s also continuous work on our dashboards. Once we finish D3M, we’ll focus more on analyzing our users, meaning we’ll try to get more stats about their behavior and see how exactly all this Dai that’s being minted is utilized. Lastly, the Protocol Engineering team asked us to look at DefCon Spells. Some are a bit outdated. These are the spells of advanced prepared spells or parameter adjustments if we hit a major price drop or a system malfunction.

Real-World Finance Team Update

Sébastien Derivaux

25:24

Real-World Finance Core Unit Report - 2021-06

  • For NewSilver, there is a new signal request proposing to increase the DC to 20 million Dai. Currently, it’s set to 5 million Dai using 16 percent of the Vault. They have implemented all the changes that were needed in the last post mortem. They published all the documents on the forum, which are the agreement with the independent director, the new notification system. There was an improvement in the smart contract for NewSilver after the audit from ABDK with a new system with a link with MakerDAO.
  • For the Centrifuge collaterals that were approved by the Governance last month. They were delayed due to the change in the improvement on the smart contract side. They are pushing on Kovan next week. It would mean that it would be deployed on the mainnet for those new pools within the next two weeks.
  • On the SolarX front, it got a bit delayed because there was some discussion/negotiation on the risk profile the Maker community would like to have initially. It’s a construction project, we start to land at the beginning due to tax issues and some other problems that we can discuss, but that means that at the beginning, they wanted to have a release of cash before they even bought the land. Then we would have no collateral, or at least just some research, but research is quite cheap these days, and I don’t know how to sell research. The idea is to restructure the project by adding the land to the project’s equity. From the start, we will have access to the equity of the land if there was any problem in this phase. That would be safer from our side would be more likely to be approved by the community and Governance. That’s why we suggest they take some extra time to find a better solution to propose to the community.
  • We are still making some progress on the Cayman financial and all the tax issues. We have a call on the tax issues in 30 minutes.
  • On the 6S front, Matt is not here, but maybe Greg can brief us if there are some updates.
    • Greg DiPrisco: Things are moving slowly, but they are moving. We’re still waiting for the tax ID from the IRS. It’s this very strange issue where trust cannot get a digital tax ID. We need to do it via the mail, and the IRS is very backed up right now. We’re just waiting on them. The other issue is the transfer instructions from Genesis, which are going back and forth between the lawyers, and it seems like they’ll be done in the next few days. After we get the transfer instructions and the tax ID, we should be able to close, and at that point, RWA will put up any final risk disclosures that it sees with the structure. Hopefully, Matt will petition for an executive vote to raise this DC.
  • On the Real World Finance side, we’ve published two posts. One with LongForWisdom for the new MKR guidelines, and another one that is more on the finance front to model the impact of giving MKR rewards to the Core Units and see the impacts on the profits and losses balance sheet, and so forth. You can play with the spreadsheet to model what you think Maker will become due to the MKR compensation.
  • On the data front, we’ve made some progress there. As you know, we are using Dune Analytics a lot to publish the monthly reports and use some Google spreadsheets for the Real World Asset stuff. It’s quite painful. We have started to work to have a real database where every data on-chain and off-chain is dumped into. We can use some SQL queries to make some more elaborated models and then use any front-end to access the data. That means that, for instance, I don’t have the financial updated today because it will take more than one day for it to be updated. Still, when it is automated, we will have the data every day. There is a Github for that. It’s open-source. It’s not a perfect production. The idea is to have something quite simple that we can improve and iterate on. It’s not going to be a separate product. We are not recreating Dune Analytics or any other system. Just something that should be fast and easy to use.

Growth Core Unit Update

Nadia Alvarez

32:00

Growth CU Weekly Updates

  • Many updates this week. We have been talking with different companies that require Maker to pass through the KYC process for one reason or another. One of these companies is, of course, Circle. Since last week, we talked with them about this idea that someone suggested in the forum about investing in the USDC we have in the Circle yield account. It was a great discussion. I read all your comments and the questions you have, and I asked Circle all these questions. They require an entity as a counterparty to sign the agreement to access these Circle yield accounts. One interesting thing is that it doesn’t matter if it’s an individual, a trust, or a bank. Still, it has to be an accredited investor.
  • The KYC process is not just for the company. We also have to understand who are the controlling partners of this company. It’s also good to know that Circle converses with other DAOs with a foundation or a central entity that controls the treasury. For these other DAOs, it’s easier to decide to sign an agreement with Circle and start using these yield accounts. I think this is also what Compound is offering now. I guess that Compound is using Circle’s yield account. For them, it’s easier than for us because we are in this process of complete decentralization, which is more difficult.
  • We also spoke with Galaxy. Big fan of Maker. They like the idea of using Maker vaults, but then again, they brought up the problem about KYC. They have to KYC us, and we don’t have any entity. Maker protocol is not an entity, so they wouldn’t be able to use Maker Vaults. After seeing all these opportunities that we have right now, we decided to ask our legal advisor to work on this and have his point of view. He will explain the risks and options we have as MakerDao, to understand the next step.
  • Paper Emporium is working on a proposal to start investing the Maker protocol assets into TradeFi. I think we can work together and find out what are the options we have for this.
  • Thanks to everyone for supporting the PSM delay. We are talking with Paxos and Binance. We have to talk with Gemini. It is interesting, and I think we have to know that including the stable coins in the PSM is a negotiation tool for us. It’s something others want. In the case of Binance, they are super excited about being included in the PSM. They want to showcase Dai as one of the top 10 use cases for USD with Dai. They also want to engage their community about using these BUSD-Dai integrations. This is great, and I think my team thinks we can ask them for more things in return for this proposal, including them in the PSM. I think it’s good to know what other projects could give the Maker protocol a return for being added to the PSM.
  • We will also be working with all the projects that we will offboard. We plan to talk with these projects ask them why they are not using the Vault. It’s good to understand why other project’s treasuries, foundations, or DAOs are not using Maker Vaults to get liquidity. As a fun fact, we discovered that the Decentraland is paying salaries in Dai, so we don’t understand why they are not using the Maker Vaults. We want to talk with them, explain to them the situation, and ask them if they want, of course, and try to convince them to open a Vault and use the remaining DC that they have available. We will give them 30 days to do that. I think that that’s also something that we could use as input to decide to offboard them in the future.
  • Star of the Week is BlockFi. People who can open an account in BlockFi will be giving an 8.5% yield in Dai. This is very cool and is also a reminder that it will be great to have the DSR alive. I don’t know if you have seen it. Still, Coinbase is also launching this yield with USDC, of course, powered by Circle. We have seen many fintech and neobanks very interested in USDC because they will have access to these extra yields. This is something to consider when we discuss the future of DSR.
  • Last week, we launched our Twitter account. This is the tweet of the week:

Questions

  • Christopher Mooney: Nadia, the deal with Matic is them monetizing our treasury. I wonder if this effectively the same thing that we did with YFI or that YFI wanted to do? And anyone can answer this, is there any major difference between the two situations because I know MKR holders didn’t vote for YFI to do this. I’m just wondering if that appetite has changed? If Should they resubmit? What the story is.
    • LongForWisdom: It’s maybe worth mentioning that YFI is doing it in YFI. They just kind of want it to be with more favorable rates, I think.
    • Nadia: I think it’s also the DC. I think that the problem was that the DC YFI wanted to have, but I’m totally in favor of YFI’s proposal. I think that we should consider being the bank for DeFi treasuries. I know that has its risks associated, but if they don’t have Maker, they will look for other options. I’m seeing UMA operating to be the bank to these DeFi treasuries. I mean, there’s a clear opportunity. We have to decide if we want to take it or others will take it for us.
  • Nadia: By the way, Jen is also working with Gnosis because Maker Vaults were not integrated into Gnosis, and everyone is using their multi-sig. Every DAO uses its multi-sig, so now it will be easier for DAOs to open up Vaults if they use a multi-sig that everyone uses. That’s also good news to position ourselves as the bank of the DAOs.
  • Christopher Mooney: Who’s working with Gnosis? Did you say?
    • Nadia: Jennifer from my team.
    • Christopher Mooney: Great.
  • Nadia: I want to add that MATIC is different because they were as collateral in the protocol, and they want to be onboarded. They are telling Maker holders that if MATIC is included, they will use the Vault. I think it’s good to know that if we are going to pass through all the effort of including new collateral in the protocol, it’s good to know that someone will use it.

Sustainable Ecosystem Scaling

Juan Guillén

43:29

Questions

  • LongForWisdom: Could you remind us briefly what’s project X-Ray and the other one?
    • Juan: Yeah, the names are not ideal. Project DogFood is to set up your Core Unit. Any documentation that will help any stranger to set up their Core Unit. Sandbox is to design and improve architecture for the Maker protocol that enables mainly parallel smart contract development. X-Ray is about the talent onboarding funnel, recruiting, and anything that will improve this as a DAO.

MIPs Update

David Utrobin

48:24

Weekly MIPs Update #42

Monthly Governance Cycle

LongforWisdom

52:34

  • We have seen the new Governance cycle in operation for the first time. We were able to observe differences between the previous and new cycles. We didn’t have anything fail, which is great. The 10k MKR minimum default vote amount was a ballpark number, which we were able to meet. However, we did witness some proposals hang below that 10k threshold until much later in their voting period. This makes some sense because many people vote toward the end. We don’t believe this is a problem yet. Still, as we continue, we will analyze if we can get any issues concerning the new Governance cycle. Overall, it has made things easier; we had healthy participation along with other things.
    • Christopher Mooney: I love that we don’t have to make a whole spell on a Monday and jeopardize the hat.
    • LongForWisdom: That is great. The old cycle did have the benefit of giving the chance to implement things through that same month’s Executive vote. We have to wait to commission the DssVest since we could not do that with the new Governance cycle since the final monthly vote doesn’t occur in the Executive.

EthCC Event

Nadia Alvarez

  • Regarding what Juan said, we are planning an event between all the Core Units and different community members. This event will in Paris be during the EthCC on the 21st. We are currently defining the venue. We want to have a panel where various Core Units will speak about what they are doing. We also would like someone from the Community available to speak. If you are interested, please, reach out to us!
    • LongForWisdom: There are a few Core Units and people coming to that. Please get in touch and participate.

Presentations and Other Discussions

Discussion on Delegation

LongForWisdom

57:46

  • We spoke a bit of delegation last week. There was a spirited discussion that took place near the end of the meeting. If anybody wants to discuss anything specific about delegation, now is a good time. The main discussion point last week was on whether mandated actors should be delegates. If anybody has strong feelings about that in any direction, please feel free to opt-in.
  • I’ll kind of state my position as it is, and people can argue. I think I’m balanced. My current position is that I like the fact that there’s almost a separation of powers between mandated actors versus Maker holders. It’s not a clean separation because there were overlaps. If delegates are still not the mandated actors, then I will continue. There’ll be a kind of a give and take between the delegates of the mandated actors, which should hopefully keep both sides somewhat in check. By allowing those two parts to kind of combine in one entity, you lose that give and take a little bit anyway, which I don’t think will be ideal. That’s one point.
  • On the other hand, it’s very difficult to stop anyone from being a delegate because it’s entirely permissionless. Given that nothing is stopping a Core Unit or a mandated actor from becoming a delegate on this line, it’s probably better that they do it publicly if they do it at all. This suggests implementing a sort of draconian policy of saying that if a mandated actor is caught being a delegate, you dismiss them as a mandated actor, which is possible. I think it’s a bit heavy-handed. It’s unlikely to work well in practice, especially since you need to make a vote to sort of offboarding someone. As I said, the mandated actor will be a delegate, so it will have like a weight in that place that will get a bit complicated. I’m curious if anyone has strong feelings on either side of this issue.
    • Planet_X: I’m divided on this. In some ways, it would be a great advantage to have them as delegates because if there is a discussion, you could get answers straight away, and that would be a huge plus. On the other hand, part of the scope of the delegators, it’s going to be more or less a little bit of a boardroom. The performance of mandated actors and the Core Units will be an essential task of the delegators. With regards to that, it’s better if they’re not delegators. Anyone else who has an opinion?
    • Derek: Ideally, facilitators like myself shouldn’t be mandated actors because we already have quite a lot of centralized control in the team itself. Protocol Engineering is working on the protocol. We shouldn’t be voting on things that we’re putting forward. I think there needs to be a broader discussion with the broader community. Of course, many people are anonymous, so you can’t be strict about that. Still, I think having a broader discussion group, like with yourself, Planet X, that is not part of a Core Unit is a healthy dynamic to have. I welcome that discourse and discussion from others who are not part of core teams and will inevitably have counter views to what the different teams will have. So yeah, I’m leaning towards facilitators not being delegates even though you can’t enforce that strictly.
    • Nkunkel: I think the enforcement angle here is a little bit irrelevant. There’s much stuff, and even just like regular governments, that’s done on a gentleman’s agreement type of basis. Let’s collectively, as a community, agree that, okay, this shouldn’t happen. I don’t think you’re going to see many people cross that line.
    • LongForWisdom: Yeah. It’s tricky. I consider as well if you have a situation where some of the mandated actors want to delegate, that’s fine, and others very much don’t. You end up with a situation like voting power leading towards different domains, which I think could be problematic. It would be less bad if all Core Unit facilitators had some light weights because they could balance each other. Still, I’m worried if it’s all congregates on certain Core Units.
    • Nkunkel: Let’s say, for instance, that in terms of crypto Twitter, or popular culture, one Core Unit is very popular. Let’s use PE as an example. Let’s glorify the devs who are building the core of the protocol, and everyone delegates to the PE team. Now you have the situation that Mooney posted, where he’s taking on the liability of both writings the bug and then voting it into the protocol. That’s a little more funny way to look at it. The way I see it is that you devolve into the kind of situation that Bitcoin finds itself in, where the devs have taken over control of the protocol, where they can kill something if they don’t like it, or they can get something in if they do. That worries me. I don’t want us to be in that type of situation. Devs should write the code, but they shouldn’t influence whether it makes it into the protocol or not.
    • LongForWisdom: Yeah. I think that’s a fair point of view, avoiding any potentially problematic tribal comments at the stage. I’m curious if anyone is taking the opposite view because I know Walter did last week. Does anyone else hold the same view that mandated actors should be delegates? We’ve heard quite a lot from one side.
  • Juan: I like Nik’s point of view, but at the same time, I don’t want to build or impose any rules, even if we can enforce them. I feel that MKR holders will delegate to whomever they want, and it’s better to do it in a quote-unquote legal way. Allow for it, if needed, and all the conflict of interest being declared compared to some random wallets showing up, and it’s like, oh, who’s this? Okay. They got a bunch of delegation. We don’t know who it is. It might be a mandated actor; maybe it’s not. And not being able to interact with that person, I think it might have worse ramifications, but I share many of the points that Nik raised. I’m on the fence about this one.
    • LongForWisdom: I think if we did conclude that we didn’t think mandated actors being delegates was a good idea, as part of GovAlpha’s responsibilities, I’m planning to write a what should you consider as an MKR holder when you delegate. This will be one of the recommendations that we put in there. We don’t think mandated actors make the most sense as this kind of targets delegation to delegate for the reasons we’ve discussed. I wasn’t stopping anyone from doing it. Still, it sort of at least allows people to consider the potential issues before they do.
  • Nadia: If we know the facilitators or Core Units shouldn’t be delegators, why don’t we create a rule? I understand we can’t enforce it, but we could ask Maker holders and explain why we think it’s not a good idea, ask them if they think the same or not, and create rules about who could be delegators. I understand that we all agree now that we don’t want that to happen, but it could happen in the future if it’s not a rule. So why don’t we create a clear framework for everyone? If you want to be a delegator and part of a Core Unit, you can always quit your Core Unit and become a delegator? If we have clear rules for everyone, I think it’s much better than assume that we all agree in a social agreement that we shouldn’t have facilitators or core units as delegators.
    • LongForWisdom: I think that’s a fair point. Any rule that we make can be unmade. It’s very much the social layer that is enforcing or enforce it. Suppose the social layer develops into a group that feels that mandated actors should be delegates. In that case, they’re just going to unmake the rule that says that the mandated actors can’t be delegates because they’ll have. In theory, the social layer is the MKR holders at this stage. If that social consensus changes, then the rules will be changed. There’s no way it could be where we can make a rule that sort of binds the future community and the future MKR holders to our current recommendations. Maybe it would be good if we could do that.
  • Nadia: I think Brian mentioned that it has to do with the delegators; If the MKR holders see that a delegate might be getting too much power, they might want to remove that or switch it to another delegate.- Juan: Nadia said we all agree that they should not, and I don’t agree with that statement. I don’t think they should, but I also don’t think they should not. I’m neutral on that one. I agree that a concentration of power is dangerous at any point in the process, but this does not stop at this stage. I’m talking about the whole ecosystem. Eventually, I think that it would level out.
    • LongForWisdom: Yeah. I think it’s also important to note that the risks of power centralization exist without this, which is what people are saying in the sidebar. Nothing stops one delegate who isn’t a mandated actor from getting a huge amount of MKR delegates to them to the point where they essentially control the vertical. And there’s no way we can adjudicate that and say that can’t happen. It’s up to MKR holders. I think it’s probably like I said, we can’t enforce it, Nadia, unfortunately, as much as some of us may want to. Essentially, there’s another wrinkle to this as well: a lot of the initial delegates or people who have contributed to Core Units in the past, at the very least. The other sort of negative result of this is if we say we don’t want to want mandated actors or people with connections to Core Units to delegate, then we’d potentially lose sort of several other people who have already expressed interest in being a delegate.
    • Nkunkel: I don’t see a problem if you were a past Core Unit facilitator or contributor that you’re a delegate. It’s only if the two overlap at the current point in time. If anything, it is probably very helpful to have a delegator who used to be a facilitator and is now on the other side.
    • LongForWisdom: Yeah, I think it can be. No matter what you do, it enables the possibility for more corruption. An example of corruption in this sort of situation you just mentioned, Nik, in sort of traditional governments, you always hear like, oh, you know someone who was a minister then became like some executive of some multinational corporation that was lobbying for certain decisions in government, and potentially vice-versa. You could have the mandated actor who sorts of steps down with the express purpose of becoming a delegate and pushing the agenda that the next, probably their successor, will push.
      Nkunkel: I feel like there are much bigger and relevant problems to deal with that delegation can solve in the short term. This split between facilitators or Core Unit members and delegators solves those long-tail problems.- Nkunkel: I agree in principle, but if we’re dealing with those types of problems, we’ve already made it. If we’ve made it there, we have a whole different set of problems to worry about.
    • LongForWisdom: Yeah. I agree. I was trying to make the point that no system is going to be perfect. As I said, we’ll post something that explains our point of view and our current recommendations to MKR holders when delegating, which will cover this. Suppose anybody wants to try and submit a MIP or write a MIP that tries to enforce certain rules for delegates. In that case, that’s also something anyone can do.
  • Tim Schuppener: To clarify, is it about being a delegate or being a recognized delegate? Suppose somebody wants to be a delegate and he cannot because of some strange MIP law we put up at some random point in time. In that case, they will create a second account being unrecognized and tell their friends and become a delegate this way. I don’t think we need to vary too much about the whole topic. I mean, right now, we have something like, I don’t know, 7% to 10% of the shares being in active voting; how bad can it be in the future if we have delegation? It would just be better, and we’ll sort it out naturally.
    • LongForWisdom: Yeah. I agree. I don’t think this is a make-or-break problem. I don’t think this is something that we need to get right initially. The reality is there is no way to enforce this, and if people are going to do it, then I would rather they do it publicly so people can keep track of them as well.
    • Nkunkel: I still think we shouldn’t let the enforceability of this dissuade us from just deciding as a community that we don’t like this. I think the social signaling is more than strong enough as an enforcement mechanism, at least at first. If you’re unknown, great, but you’re going to have a hard time pulling in big bags of Maker because you can’t use your identity as your brand to attract the MKR as a delegate.
    • Tim Schuppener: No, but let’s say one of the VCs is fond of Derek, and saying, Hey, Derek, it would be cool if you could be a delegate. And Derek would say, sorry, I cannot do. And then they bribe him, and he creates a second account unknown; nobody knows about it, just the VC. This works totally. So why are we trying to prevent this?
    • Nkunkel: I agree. That’s possible.
    • Tim Schuppener: You’re not getting bribed, Derek. I was making it up.
    • Nkunkel: I agree that’s possible, but I think the social layer consensus is a lot stronger than people give it credit for. Many things in government that we have our traditions and social consensus. They’re not codified into law or anything.
    • LongForWisdom: That’s definitely true, and some of those traditions hold fairly strongly, but we’ve also seen examples recently where those traditions have been broken with limited regard for anyone. I do think the social consensus is pretty strong. If someone wants to write a MIP that says these are the rules for delegates that everyone agrees on, we can do that. We can vote on it, but I don’t think it’s critical to start with.
    • Tim Schuppener: If MKR holders don’t like the idea of Core Unit facilitators being delegates, then they won’t delegate to this person. There is no need to come up with some so-so consensus. How should this work? Is somebody going to write a MIP saying we don’t like that, and then we have to submit it to the voting portal? Is that the way to go?
    • Derek: All it will be is a social agreement. You can never have more than that.
    • Tim Schuppener: Yeah, but I mean, code is the law. So if people don’t like the social agreement, they will act otherwise because it’s possible to do. And they will find the bribable Derek out there.
    • Nkunkel: I think we’re over…
    • LongForWisdom: Scared of all the Dereks, it seems.
    • Tim Schuppener: Just sticking to the story.
  • Nkunkel: The only way that works is if the person is anonymous because if they’re a Core Unit facilitator or contributor or whatever. Then they’re a public delegator; then the next step is for governance to vote that person out of their position. And then it becomes the code is law enforcement of the social values that we’ve agreed on. We’re just talking about this edge case of someone unknown and kind of darks themselves to certain people to get their MKR delegated to them. I think that that edge case is possible. Still, I don’t think it invalidates the rest of the benefit that we get in all other cases, except for that specific edge case.
    • LongForWisdom: The potential flip side to that is that if you don’t force people to do it unknown, then they’ll do it publicly, and you can keep better track of what they’re doing. That’s the kind of counterargument. Suppose you do say it’s why you don’t recommend it, but we would rather it was public than private. In that case, potentially, it’ll be public, and it’s easier to track any conflicts of interests, any potential sketchiness, or whatever.
    • Nkunkel: Yeah. The Yakuza model in Japan. How did that work out for them?
    • LongForWisdom: I’ll admit my Japanese history is not the best. Could you elaborate?
    • Nkunkel: TLDR, it didn’t.
  • LongForWisdom: Got you. Cool. All right. As I said, I don’t think we’re going to decide on something beforehand because we’re hoping to launch fairly soon. If anyone is deeply concerned about it and thinks we should try and enforce it, it would be the way to go. I’m happy to like help review any MIPs that anyone wants to write along those lines.

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

Credits

  • 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.

G&R #148 Snippet

Domain team updates, Collateral Onboarding, active discussions, and more. All the updates from MakerDAO Governance and Risk Call #148 in this snippet.

Team Updates

GovAlpha

GovAlpha Weekly Update

  • Executive has not yet passed and needs 500 MKR to pass. Please vote.
  • One poll by the MakerDAO Open Market Committee proposing parameter changes will be in Executive this week.
  • This week’s Executive includes many things.
  • Adjusting Executive and polling system with the help of many members.
  • Put together templates for delegation, which will soon be public. We will be starting a Meet Your Delegates meetings.
  • New and improved version of the MIPs portal being pushed to production.

Forum

Forum at a Glance: June 25 - July 1, 2021

Protocol Engineering

Teamwork:

  • Optimism Dai Bridge final review. We are complete for test deployments.
  • Pending official launch date from Optimism
  • D3M. Completed code but not an immediate priority - requires a review
  • SushiJoin Adapter complete - awaiting Sushi teamwork

Technical Evaluation:

Testing:

  • Final Echidna and audit tests for the L2 escrow
  • Starting to use Certora to formally verify optimism-dai-bridge

Discussion/Documentation:

  • ESM Postmortem - to be published this week
  • MegaPoker Postmortem - to be published this week
  • Defined expected magnitude ranges for all dss parameters and quantities
  • Oracle Tail risk mitigation

Oracles

  • Oracle CU polling vote has passed.
  • Busy with legal work on the back-end.
  • Carefully working on Gopher pricing tool. A minority of stakeholders upgrading and is running smooth. We will begin to complete the remainder of the migration.
  • Spire coming out soon within the next few weeks, which adds an extra layer of redundancy similar to scuttlebutt. Both Spire and Scuttlebutt will be working in parallel.

Risk

  • Published two collateral evaluations for stETH and MATIC.
  • Ongoing work on D3M. Evaluation should be finished by next week.
  • Ongoing discussion about Institutional Vaults, which may soon be called Conditional Vaults.
  • Preparing simulations testing lower LR ratios on Vaults.
  • PE Team asked to look into Defcon Spells.

Real World Finance

Real-World Finance Core Unit Report - 2021-06

  • NewSilver request proposing to increase DC from 5 million to 20 million.
  • Improvement in the smart contract for NewSilver following an audit by ABDK.
  • Centrifuge collaterals approved by Governance were delayed, pushed to Kovan for next week.
  • For SolarX, the risk assessment is delayed as we are discussing with them to improve MakerDAO safety by having more collateral at the beginning.
  • Continuing progress on the Cayman Islands legal and tax side.
  • Began working on a real database both on-chain and off-chain to create more elaborative and useful models for data use replacing Dune Analytics.

Growth

Growth CU weekly update: June 25 - July 1

  • Speaking with various companies that require Maker to pass through KYC processes. In deep discussion with Circle.
  • Spoke with Galaxy, who like the idea of using Maker Vaults but don’t want to involve KYC processes.
  • PSM was delayed. Speaking with Paxos, Binance, and Gemini to continue business negotiations.
  • Will be working with partners to discuss why they are not using Maker Vaults.
  • BlockFi will be giving an 8.5% yield in Dai through July 30!
  • We are approaching Gnosis about Maker Vault integration.
  • Planning an event in Paris on July 21 for MakerDAO. If you will be there, reach out to get involved.

Sustainable Ecosystem Scaling

  • Our team’s MKR Compensation Budget proposal passed.
  • Potential Budget Modification for grants and/or incubation program on its way.
  • Project Sandbox meeting, which helps improve protocols, happened last week.
  • Project X-Ray happening tomorrow, which helps set up CUs through onboarding.
  • Incubees DTalent and dUX are now live! Reach out for help if you need it.
  • Working with Dai Foundation on potential MIPs.
  • CU Launch Pod Session with AmaZix Marketing CU.

MIPs

MIPs Weekly Update #42

  • All of last month’s Ratification Votes passed.
  • This week is a gap week.

June’s Governance Cycle

  • Had our first month using the new Governance Cycle, which went well.
  • We saw some proposals stay below the 10,000 MKR threshold, being passed last minute.

Other Presentations and Updates

Delegation

  • Discussion going on concerning the pros and cons for delegates becoming mandated actors and vice-versa.
1 Like

This call is now available to watch/listen on our YouTube channel

1 Like