`guardian` in `governance-timelock` is redundant
Currently the guardian in governance-timelock is a deprecated msig, where the only owner is devmsig as of now.
This configuration kind of defeats the purpose of guardian which has rights to cancel transaction that has being queued, while the admin and the guardian are exactly the same addr.
General consensus
It is to set the techops as the guardian for the time being, despite that still devmsig atomically could remove the guardian at pleasure. Something to consider that needs more check/balances to ensure that could not happen atomically
Considerations:
- [ ] update the guardian to techops
probably worthy to be batch whenever #1277 is posted
I agree on changing the guardian to a live Multisig and it should be one with very little overlap with Dev, for instance TechOps. The reason for this is that the guardian should be able interfere vetoing malicious transactions in case that dev is compromised.
I would defer to @GalloDaSballo and @dapp-whisperer for the best configuration though.
@dapp-whisperer if we want to be super cautious guardian could be a List of EOAs Else can use techops or similar
No strong opinion until I understand the goal of the timelock
the goal of the TL is to put the minting/burning actions of badger token behind that currently it could happen atomically by the devmsig and to keep higher sec standard we want to keep it behind TL at least cc: @GalloDaSballo
so without the guardian role being able to call cancelTransaction, the timelock really only serves one purpose: telegraph an upcoming change (such as a upgrade or parameter change) in the badger system. the only entity able to cancel that queued change would be the dev msig itself.
~~being able to cancel queued transactions from another msig (guardian role) would increase security in cases where the dev msig is queueing up malicious transactions. note that this 'veto' permission does give the guardian the ability to grief the timelock by cancelling everything that gets queued.~~
~~both should be trusted and have high security imo for that reason.~~
@GalloDaSballo how can the guardian be a list of eoas? only way that could work imo is by setting up a separate multisig owned by these eoas with a threshold of 1..
i would say techops is best option for now too, and agree to batch it with #1277
edit: setGuardian does not need to occur through a timelock, so the guardian cannot protect against a malicious dev msig. only make cancelling easier.