Conversation
|
|
||
| There is an immediate need to deploy the Movement Token (MOVEToken) using a robust, secure, and auditable upgrade mechanism. By creating two multisigs—one for proposal and one for execution—we ensure a transparent and decentralized governance process over upgrades to critical contracts. | ||
|
|
||
| The first multisig allows Core Contributors engineers to propose upgrades via Safe’s multisig service. A remote key will automate the population of upgrade proposals. The second multisig, held by the Movement Foundation, will be responsible for executing the scheduled upgrades after a time delay, ensuring community trust and review. |
There was a problem hiding this comment.
A remote key will automate the population of upgrade proposals.
Do you have an idea of how this is implemented. It's unclear how and where this remote key will be stored and how it will, without some program automate population of proposals.
I'm also unsure what you mean by 'population of upgrade proposals'.
There was a problem hiding this comment.
if there is a need to upgrade, we need to propose a transaction that will get stored in Safe's offchain solution. Populating it means adding the data required for the proposal to be initiated.
|
|
||
| The first multisig allows Core Contributors engineers to propose upgrades via Safe’s multisig service. A remote key will automate the population of upgrade proposals. The second multisig, held by the Movement Foundation, will be responsible for executing the scheduled upgrades after a time delay, ensuring community trust and review. | ||
|
|
||
| Also, while developing an independent multisig, handling signature showed to be an issue that might be indicative of better letting signature to be handled by safe.global. |
There was a problem hiding this comment.
Did this come up in review? If so linking back to the review comments would be helpful.
There was a problem hiding this comment.
What are you referring to, sorry
There was a problem hiding this comment.
Just where you say it showed to be an issue, but no worries
| - Role: Deploy contracts. | ||
| - Addresses: [redacted]. | ||
|
|
||
| Both multisigs are part of a timelock mechanism to enforce a 2-day waiting period between the proposal and execution of upgrades. The engineers' multisig schedules the upgrade, while the foundation multisig executes it after the timelock expires. |
There was a problem hiding this comment.
Once the timelock is set, can its value every be updated without a redeployment?
There was a problem hiding this comment.
I'm under the impression that maybe you could change it by using the fallback functionality, but maybe I'm wrong. That would require going through a transaction proposal to itself then executing it using the foundation multisig. I do believe that transferring to a new timelock is easier.
|
|
||
| ### Multisig Security Considerations | ||
|
|
||
| - Believe it is best practice to rely on a service that is fully dedicated to multisigs. Eventual exploits found might open us up to exploits while safe.global could've prevent the exploit for us. |
There was a problem hiding this comment.
safe.global is a third-party service
| ## Appendix | ||
|
|
||
| - [R1] Safe Multisig: https://safe.global/ | ||
| - [R2] SafeKit API Documentation: https://docs.safe.global/sdk/api-kit |
There was a problem hiding this comment.
Thanks for the flow chart. In the case that a proposal is not signed on by at least 4 / 5 engineers, a proposer can just re-submit that proposal again? I'm just thinking in the case that an engineer missed the timelock period for some reason
There was a problem hiding this comment.
proposals are live until it's either valid or cancelled as a multisig safe transaction
apenzk
changed the title
2 participants
MIP-18