Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add timelocks to Authorizer #588

Closed
nventuro opened this issue May 28, 2021 · 1 comment · Fixed by #1133
Closed

Add timelocks to Authorizer #588

nventuro opened this issue May 28, 2021 · 1 comment · Fixed by #1133

Comments

@nventuro
Copy link
Contributor

nventuro commented May 28, 2021

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.

Pseudo-code:

contract DelayedCall {
  constructor(recipient, calldata, delay) { ... }
  
  function trigger() external {
     require(delayPassed());
     require(!_triggered);

     _triggered = true;
     recipient.call(calldata);
  }
}
@nventuro
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant