Charles St. Louis
April Governance Cycle Review
- The governance vote has passed. All inclusions will continue into the executive vote on Monday. This includes core units for content production, growth, critical engineering, and the Swag Shop. There’s a Declaration of Intent proposal for Euro-DAI along with several amendments to various MIPs, including MIP4, MIP9 and MIP0.
- MIP0 amendments are minor. MIP4 amendments are a little more involved but not groundbreaking. MIP9 amendments are only setting it for green light polls twice a month rather than once a month. We’ll also be doing some of the budget distributions on Monda. We will begin with Protocol Engineering and try to get to the other core units as well. However, I will need to speak to them first. Make sure to look for that on Monday.
End Book Fixes
- LongForWisdom: Do anyone from the Smart Contracts team want to speak about the end book fixes?
- Kurt: There’s a detailed forum post about this. Along with the Liquidations 2.0 spell that was recently voted in were some bug fixes concerning the ESM and the end module, which is the smart contract that orchestrates the global settlement process after an emergency shutdown. In the process of scrutinizing them, we had found issues with the ESM. It didn’t revoke the access of Governance to certain aspects of the system. A quick overview: the ESM is used to dump a certain amount of MKR and shut down the system. The primary intent of it is to allow an honest minority to defend against malicious majority within Governance. Another usage will be if there’s were a critical bug in the system that can’t be safely patched. Some minority of MKR holders could be notified and safely shut things down. It didn’t work very well for the first intent of defending against a malicious majority because there was still access for governance to retain the system. The fix was to completely shut Governance out if the ESM were to get triggered. If there is a bug in the emergency shutdown process itself that Governance could intervene and repair turns out to be the exact kind of bug that we had at the end; if there was a certain amount of collateral reserved to cover Dai, and it exceeded a particular value you’d get an overflow. The end process would get stuck. Governance could have stepped into for repair, but we changed the ESM to shut Governance out completely. The fix was relatively quick. It took longer to write the forum post explaining this than it did to fix the issue.
- LongForWisdom: Risk spoke about future mitigations to pick up these sorts of bugs. Would you like to summarize those?
- Kurt: there will be fully detailed post mortems at some point within the near future. Unfortunately, we’re a little bit oversubscribed at the moment. I don’t want to make false promises. The ESM bug was caught by discussing how it worked while we were looking to redeploy it. Originally, there wasn’t a good enough specification for the ESM. It was around the time that the system was first being deployed. The Governance system wasn’t well defined or finalized. The lesson is that we require better specifications upfront for the requirement of these things. Of course, we can add test coverage for that, which we now have. The end big was caught now because we were writing tests to perform the emergency shutdown process with the LINK-A executive applied. By performing those tests, we saw they were getting stuck, not working, and reverting.
- Kurt: But how can we find these bugs sooner? We have a few different things we want to do. We want continuous integration tests that are running all the time or periodically against the mainnet state. We could catch the bug as soon as we have more than a certain amount of DAI from ETH-A, for example. We could have added formal verification where you say ‘here are the expected magnitudes for values in the system’ and then run an automated checking tool that says confirm the intermediate calculations overflow and revert if the magnitudes are in those expected ranges. That’s another thing we want to do. Generally, we’d love to be spending more time on security and safety work. There’s been a big road map published for that that you could find on the forum as well. We could use these issues to invest more into upstream activities instead of pushing everything out at once.
- LongForWisdom: Awesome, thank you for summarizing that. I like the idea of having a sandbox running and constantly shutting down the protocol to make sure everything works.
- Kurt: it would be running against the current state and values on the mainnet. Somebody may ask if the emergency shutdown was tested before? Well, it was tested extensively, even on the mainnet. This bug only surfaced when we had a certain amount of collateral in the system. all those tests were done with too small values to trigger the bug. That’s why continuous integration tests can help discover it as soon as it happens. It’s not ideal since you do have to find it on the mainnet. These solutions are not complete. We need this more intensive and frequent early checking within the dev process where you write tests or do some verification using a wide range of values to look for problems anywhere in these specified ranges.
- LongForWisdom: I think that makes a lot of sense. Any other questions?
- Christopher Mooney: We have a full response to the MIP45 audits posted in the forums today authored by Kurt. We took a little while to collect our thoughts. Kurt did a good job at describing each issue in the audit and how they were addressed. It’s a very comprehensive response.
- Kurt: In the audits, there were no super severe bugs that were found. There were potentially two or three that were fairly significant. These were fixed. Most of the issues were either minor, informational, or simply remarks on design aspects of the system, such as how we do authorizations or conventions. There were also good ones that were brought up concerning the risks of MEV to the Liquidations 2.0 system.
- LongForWisdom: I’m sure I’ll be able to find time to read it.
- Kurt: Let us know whether your issue was addressed or potentially what does the issue even means. They refer to very detailed things about the system. Hopefully, this will help anyone who wants to understand the audit reports.
- I posted a thread on the forum concerning delegation. In summary, delegation is coming fairly soon. People volunteered to be delegated. Gov Alpha and I are reaching out to interested people. We are discussing best practices and creating a collaborative set of goals.
- Payton: A concern that sprouts within the discussion of the delegation are the potential for one person or entity to be able to retain all the voting power all while everyone else is content and thereby allowing this person to become malicious. Do we have any practical limitations in mind or anything related?
- SamM: This person would have to maintain the voting power for two days to secure the
hat. Delegators will be made aware of this to allow them to pull their MKR to reverse their vote. This is not a critical scenario but concerning.
- LongForWisdom: Does Dss Gov change this because it works off a snapshot system?
- Kurt: It’s unknown if Dss Gov will ship in its current form, but we spent a lot of time discussing mechanisms regarding delegation expiry time to prevent delegates from misbehaving or becoming apathetic. These mechanisms are put in but do require to be revisited and reviewed.
- Christopher Mooney: It’s a problem. We tried to address it in Dss Gov. However, the type of delegation we will have here is a minimum viable implementation of delegation. We are hacking up a voting proxy to allow for delegation.
- SamM: We don’t have any vote decay implemented at the moment because we don’t need it. We are redoing the delegation when Dss Gov releases. That will be sufficient.
- Christopher Mooney: I can imagine scenarios where it doesn’t work. However, I agree that it is most likely that we move to Dss Gov and perform the best implementation. Does anybody object?
- Frank Cruz: Is decaying similar to slashing in POS?
- Christopher Mooney: At a certain threshold, the delegator’s delegation will eventually become ineffective and require re-up through participation in the protocol. This prevents early delegates from being apathetic or monopolizing locked or lost MKR.
- LongForWisdom: I hope that we will have an initial set that will help avoid everyone piling into a single delegate. We will be able to keep MKR distributed between delegates through the delegate’s quality. Overall, we will have to experience this through practice.
- Brian McMichael: The Protocol Engineering team has no intention of being delegates because that can be an issue of power.
- Frank Cruz: Are any core unit members will be delegates?
- Christopher Mooney: It’s permissionless. Anybody could put their name forward, but it would be a poor idea for MKR holders to delegate due to potential power concerns for the delegator.
- Kurt: Somebody can go and mix my MKR and make it untraceable, come back with a pseudo identity, and convince MKR holders to delegate to them. This is a realistic possibility.
- LongForWisdom: We are planning for Gov Alpha to perform delegate verification. It won’t be anything forceful, but there will be communication involved between these people. Verified delegators can receive a checkmark status or something like that.
- Kurt: That sounds like a good place to start. Delegates will evolve, and anything can happen in the future. We may have much more comprehensive investigational capabilities in the DAO or something. These are crazy ideas, but who knows.
- Peyton: I know the SES Core Unit presentation mentioned a vision involving parties as delegates. Does anybody have opinions on this?
- Wouter: There are three models that we discussed. These are three bottlenecks for scalability. We are trying to develop a vision of what things may evolve into. We have a decentralized workforce and capital allocation. One of the issues we are addressing is that MKR holders have limited bandwidth. As the ecosystem scales, you can expect MKR holders to continue getting involved in the nitty-gritty and micromanage every little thing. On the other end, there will be much involved in understanding which work needs to be funded in the DAO based on importance. We will also check the quality of every Team’s work. Finally, we are concerned with the potentially coming need to have a budget limit. Currently, our budget is like a buffet as we are adding on tasty core units, and it may look like there is no limit, but sooner or later, it will happen. Then we will need to know how to prioritize core units and the DAO budget. The idea is to have a limit set for groups who develop their vision and priorities for the DAO. We can have people who work to focus on budget allocation for these goals within the budget limit. This is a very compatible and scalable idea. However, delegation is the first step. I am excited to create more documentation discussing how these ideas can evolve in the future. Please, listen to our launch-pod session here.
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
- Artem Gordon produced this summary.
- David Utrobin produced this summary.
- Dennis Mitchell produced this summary.
- Sai Teja produced this summary.
- Everyone who spoke and presented on the call, listed in the headers.