This proposal aims at introducing timelocks for the DAO and changing a few parameters in the Morpho.eth space.
The communities of different protocols considering an integration with the Morpho protocol raised the absence of timelocks. Even though timelocks are not necessary, they have become common practice and add an extra layer of security.
This is why we suggest by integrating a timelock with the following properties:
- Lock time: 24h.
- The same owner can stop the execution of the transaction during this period.
- In a first instance, there would be no expiration period (time after which the transaction can’t be executed).
- Functions that can upgrade the implementations of the contracts.
- Functions that can change the ownership of the Safe in any way.
This timelock would be using the Zodiac Delay Modifier and could be triggered by the DAO itself.
The trigger should be, in a first instance, optional. Indeed, the implementation of a Timelock in the current Zodiac framework should be done with extreme care. Thus we have decided to propose first this small step. To go through the full timelock setup on the different Roles of the Role modifier, a much bigger proposal should be made with a full technical specification of the plan.
The community has raised concerns about voting times that are on average 24 hours longer than similar protocols.
With the introduction of timelocks, time between proposal and execution may be extended even further. The protocol is still young, and we propose to shorten the voting time from 96 hours to 72 hours to keep execution nimble.
While a voting time decrease makes sense for general proposals, gauges require a longer period. This is why we propose to introduce a Snapshot subspace for gauges. Here are the settings of the corresponding space: https://snapshot.org/#/gauges.morpho.eth/settings.
There are currently 5 rules to calculate the voting power of an address on the Morpho DAO.
With MIP2 (forum post & vote), early contributors and investors were given the ability to vote with a part of their tokens (linear vesting over 36 months), even if they were locked in a separate smart contract.
While this solution is practical for tokens vested in smart contracts, it complexifies the code logic of voting rules that should remain very simple.
Instead, we suggest enabling the claimability of vested tokens such that the Snapshot Space only requires the use of the rules balance-of and delegation. This requires the whitelisting in the token contract of the three vesting smart contracts :
The HAL plugin enables Morpho community members to be notified of new and ended proposals on Snapshot. This is a practical feature to improve governance. Yet, it requires the action of the Governance to be added.
The code repository is available here.
This proposal is quite large. Hence, if accepted, it would be executed in multiple steps over the following weeks/months. Moreover, an audit work on the different contracts (eg. Zodiac Delay Module) would have to be conducted.