Alchemix DAO has two different multisig accounts that are used to secure the treasury funds, secure administrative functions, and to conduct protocol operations. The operational multisig (0x9e2b6378ee8ad2A4A95Fe481d63CAba8FB0EBBF9) handles various functions, such as payroll, Olympus Pro, and DeFi 2.0 initiatives for the treasury. The treasury timelocked multisig (0x8392F6669292fA56123F71949B52d883aE57e225) holds the ALCX, receives protocol fees, and has admin rights to change certain parameters, and has a 24 hour timelock guarding all function calls.
The security of the timelocked multisig is undoubtedly better as there is a set duration of time where anyone can see a queued transaction, and can sound the alarm if something suspicious is about to happen. However, the timelock adds additional friction to responding to and updating parameters in the contracts.
The Alchemix core team suspects that we might have a need to be agile in the early phase of the v2 deployment, and by having the operational multisig be given admin rights, it will allow us to change parameters expediently during the initial phase post-rollout. It is expected that we will need to increase debt caps, deposit caps, convertible caps, and perhaps other parameters as we scale out the deployment. Therefore, the core team would prefer initially giving the admin rights to the non-timelocked operational multisig for the v2 deployment.
From what we gathered from the call, giving the admin rights to this multisig is something most of the community is fine with as long as it is temporary, and the admin rights are transferred to the timelocked multisig at a later date.
With that in mind, we propose that the operational multisig be given the admin rights to v2 for a period of up to 1 month after the guarded-launch phase is finished. This will allow the core team and community to be able to respond and react much faster to protocol and market conditions, and after parameters have stabilized, we can transfer admin rights to the timelocked multisig for the greater security guarantees it offers.
A vote "for" authorizes the operational multisig to be the admin for v2 for up to one month after the guarded-launch period has finished (0x9e2b6378ee8ad2A4A95Fe481d63CAba8FB0EBBF9)
A vote "against" will result in the timelock multisig being the admin for v2 from day 1 (0x8392F6669292fA56123F71949B52d883aE57e225)