Conversation
specs/governance/timelock-guard.md
Outdated
|
|
||
| ### constructor | ||
|
|
||
| ### enable(delay_period) |
There was a problem hiding this comment.
Maybe just configure(TimelockGuardConfig) where TimelockGuardConfig is a struct that at least includes a delay uint
There was a problem hiding this comment.
Removed setDelay so that enable both enables and configures, and a module can be re-enabled to re-configure.
I also added disclaimers to both definitions and the function specification to allow the developer to choose better function and variable names if they can think of any (I don't think we need to decide on enable vs configure).
I don't think I need to require which structs should be used.
|
|
||
| To allow for identical transactions to be scheduled more than once, but requiring different signatures for each one, a `salt` parameter can be included in `data` with the sole purpose of differentiating otherwise identical transactions. | ||
|
|
||
| ### checkTransaction |
There was a problem hiding this comment.
A function to see pending txns would be nice too
There was a problem hiding this comment.
This revealed a bit of an issue. The TimelockGuard doesn't know which transactions have been executed, for that it would need to peek into the storage of the Safe. more importantly, if a module (UnorderedExecutionModule) overrides the replayability mechanism, the TimelockGuard needs to be tailored to also check in the module storage, if we want the TimelockGuard to be execution-aware.
specs/governance/timelock-guard.md
Outdated
| Called by anyone, verify that the `cancellation_threshold` has been met for the Safe to cancel a given scheduled transaction. | ||
|
|
||
| - MUST revert if the TimelockGuard is not enabled for the safe. | ||
| - MUST revert if `scheduling_time(safe, tx) + delay_period(safe) >= block.timestamp` |
There was a problem hiding this comment.
Should also check that each owner is actually an owner on the safe, and that the owner set is unique
There was a problem hiding this comment.
We check that the owner is an owner of a valid safe for the transaction in rejectTransaction to avoid spamming.
As for the set of owners being unique, the specs don't include the arguments for the cancelTransaction function, and don't require that a list of owners is provided as an argument.
Also, the owner set won't necessarily be unique. It is possible and valid in a nested setup for the same address to be an owner in two different safes, and to reject and be counted in both.
|
Superseded by PR761 |
3 participants
Specs for TimelockGuard