You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the interest of reducing the need for trust of the multisig signers, it is desirable to add a timelock to some of the permissioned actions, such as setting protocol fees, or changing the Authorizer itself.
We considered following an approach similar to OpenZeppelin's TimelockController, but in the end decided against it as it is considered too implicit: understanding which actions have timelocks and how long they are requires querying multiple contracts and looking at their individual configuration.
The approach that is currently being considered as a replacement is having the timelock information (minimum delay) baked into the action data itself. Actions are then divided into two types: immediate and delayed actions.
Immediate actions behave as they do today: the query returns true for accounts that can perform them. Delayed actions however work differently. Permissioned accounts cannot perform the action, but can instead deploy a contract for which the query returns true. These special contracts are created with a recipient, calldata and delay, and can be triggered after the delay expires to make the requested call. This triggering can only happen once.
Some important features timelocks should have (mentioned in #988):
scheduled actions should be cancellable: it is otherwise impossible to go back on the scheduling on an action, and it remains a threat as it will be valid past the execution data
scheduled actions should be configurable to be either public or private. In some scenarios, it is important to have control over the party that actually triggers the action, while in others that can be left open
In the interest of reducing the need for trust of the multisig signers, it is desirable to add a timelock to some of the permissioned actions, such as setting protocol fees, or changing the Authorizer itself.
We considered following an approach similar to OpenZeppelin's
TimelockController
, but in the end decided against it as it is considered too implicit: understanding which actions have timelocks and how long they are requires querying multiple contracts and looking at their individual configuration.The approach that is currently being considered as a replacement is having the timelock information (minimum delay) baked into the action data itself. Actions are then divided into two types: immediate and delayed actions.
Immediate actions behave as they do today: the query returns
true
for accounts that can perform them. Delayed actions however work differently. Permissioned accounts cannot perform the action, but can instead deploy a contract for which the query returnstrue
. These special contracts are created with a recipient, calldata and delay, and can be triggered after the delay expires to make the requested call. This triggering can only happen once.Pseudo-code:
The text was updated successfully, but these errors were encountered: