feat: TimelockGuard #324
feat: TimelockGuard #324
Conversation
introduces the TimelockGuard proposal.
| ### Configuration | ||
|
|
||
| A Safe configures the Guard by setting two delay periods, one that applies when a threshold is | ||
| reached and a second that applies if all members of the multisig sign the transaction. |
There was a problem hiding this comment.
This will work for our 2/2 and 3/3 multisigs, but would be less useful as the number of signers grows, because the chances that one will be unavailable increase, stopping the multisig from executing in the shorter period.
| for execution of the transaction. If a threshold of signers have signed the timer is set to one | ||
| value, if all signers have signed the timer is set to some second (presumably shorter) value. | ||
| 4. After the specified time, anyone can then call `Safe.execTransaction` as normal and execution | ||
| will complete as expected. |
There was a problem hiding this comment.
This will need to be merged somehow with the UnorderedExecutionModule. Maybe the TimelockGuard incorporates the bytes32 hashes from the UnorderedExecutionModule and offers a function different from exectTransaction for execution.
There was a problem hiding this comment.
I think that this is doable simply by ensuring that the params of the scheduled transaction match the transaction being executed whether that is by a module or by the normal flow.
Something to consider though, is that certain versions of the Safe (pre 1.4.0 I believe), do not call to the Guard at all when executing a module transaction. So we will likely need to upgrade some if not all of the Safes we use.
| A Safe configures the Guard by setting two delay periods, one that applies when a threshold is | ||
| reached and a second that applies if all members of the multisig sign the transaction. | ||
|
|
||
| ### Transaction Flow |
There was a problem hiding this comment.
👍 Love the flow. This feels like a best case world for a module based system.
| <!-- Provide a brief summary of the customers for this design document. --> | ||
|
|
||
| The customers for this design doc are any participants in the multisig accounts that would utilize | ||
| this module, as well as any 3rd parties who rely on the security properties of these accounts. |
There was a problem hiding this comment.
| this module, as well as any 3rd parties who rely on the security properties of these accounts. | |
| this guard, as well as any 3rd parties who rely on the security properties of these accounts. |
| faster, but this will be difficult to coordinate regularly and leads should not expect this to be | ||
| a norm. | ||
|
|
||
| ### Critical Transactions |
There was a problem hiding this comment.
Maybe rename this section to "Time Critical Transactions".
Introduces the TimelockGuard proposal.