[GIP-17] Multisig Reshuffle & Pausable Admin

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: https://safestats.xyz/

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:

https://gov.gearbox.fi/t/multisig-ceremony-apply/95

As such, suggesting to add:

• 0xcD25fFc7888e0cA96014dC729394E8F09Faf7706 (Alex from Graviton application)
• 0x66a3c94814dc3a37C9d61f1a977ea3730c621426 (Alex from Mellow application)

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 (nikitakle)
• 0x6D526f6b4C86FBdc8e359e6bef4Cd6a42aceA2d7 (amantay)

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:

1. Separate the unpause functions into a new multisig
2. The new multisig for unpause will be 3/10
3. Same signers from the updated technical multisig will be here, no changes to the list.