UPDATE 29.08: changed suggestions on rotating in-and-out based on the latest applications.
This proposal is aimed at (1) rotating some multisigs signers and (2) setting up unpause role.
Going through the latest Notion report, you can notice that some singers are basically MIA. That is natural to expect given that multisigs were set up almost a year ago: some people have quit the industry or went offline more. Regardless of the reasons, it’s not efficient and can at some point affect safety in times when asap multisig quorum is required. Current policies are in docs.
You can check this yourself:
Part 1: Rotating Signers
Technical Multisig
See at the bottom of this page how active or inactive a certain signer has been. It becomes logical that signer 0x1D35DFE2c3B9A0D9f200Ee70a62D73da832606CD has to be rotated out.
Currently, multisig is 6/9. I would propose a motion to add two new tech-knowledgeable signers and turn the technical multisig into 6/10. That still keeps the multisig extremely concervative, but improves the response time in critical situations. Volunteering members have so far been:
As such, suggesting to add:
-
0xcD25fFc7888e0cA96014dC729394E8F09Faf7706 (Alex from Graviton application)
-
0x66a3c94814dc3a37C9d61f1a977ea3730c621426 (Alex from Mellow application)
If there are other experienced volunteering DAO members, this list should be updated.
Financial Multisig
The same logic goes for the financial multisig too. It is currently 5/7 but can be upgraded to 5/9 as it would still keep the signer count significantly high yet improve the response time.
Rotating in:
- 0xf3D476566BCC8E882A3910F1471428522449d89E (myself)
- 0x6D526f6b4C86FBdc8e359e6bef4Cd6a42aceA2d7 (amantay)
If there are other experienced volunteering DAO members, this list should be updated. The application of bananacrypto seems good too, and I would suggest to add them next time. That is, because financial multisig had so little activity so far - it would be unfair to rotate out inactive members just yet. Once the rotation happens, the other eligible volunteers can step in instead of those rotated out.
Part 2: Unpause Role Separation
As discussed in GIP-16, there are multiple approaches to security both before a protocol goes live (audits pre-deployment of anything new) and post-deployment (bug bounties, bot system, etc). To further increase security, the PAUSE function as having been executed in times when Immunefi bounties were confirmed, allowed the protocol to be paused (or some specific pools / Credit Managers / assets) immediately upon an issue discovery. This role has so far been in the hands of two addresses run by those have the knowledge of the system / have monitoring bots:
-
0xD5C96E5c1E1C84dFD293473fC195BbE7FC8E4840
-
0x65b384cecb12527da51d52f15b4140ed7fad7308
Having this PAUSE be under EOA control is not a centralization issue as it doesn’t actually grant any other rights to these members. It only just pauses a system if there is an issue detected.
However, when pausing, unintended consequences - such as untimely liquidations - can occur. In that case, nobody (be it a hacker, a developer, or whoever else) can actually benefit, but it could result in bad debt in the pools in case Credit Accounts’ assets went below HF 1. As such, timely unpauses after resolving an issue are crucial. And, so far, with 6/9 or even 6/10, they still take over half a day, which is not acceptable. But still, it’s a security-sensitive move (to unpause a system) so it can’t be given to an EOA. So Part 2 aims at requesting the DAO’s approval for:
-
Separate the unpause functions into a new multisig
-
The new multisig for unpause will be 3/10
-
Same signers from the updated technical multisig will be here, no changes to the list.