guardian in governance-timelock is redundant

[petrovska-petro]

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

[petrovska-petro]

probably worthy to be batch whenever #1277 is posted

[sajanrajdev]

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.

[GalloDaSballo]

@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

[petrovska-petro]

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

[gosuto-inzasheru]

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

[gosuto-inzasheru]

edit: setGuardian does not need to occur through a timelock, so the guardian cannot protect against a malicious dev msig. only make cancelling easier.