Minting upgradability

[petrovska-petro]

Currently the minting capabilities are restricted to the controller, which is governed by the dev_msig, which under current conditions this could occur atomically and its status presents an opportunity to upgrade the flow considering the following approaches (but not limited to):

• Establish a timelock with at least x amount of days as delay behind this action
• Consider enforcing governance to a greater group of msig for consensus of proceeding with the action. Example: devmsig, treasury and badger council should be align to queue the tx in the timelock
• Introduce a mint cap per action, including a setter, which again will be behind timelock. For example: at once no more than y tokens can be minted (400k, 500k…y)

This will achieve a greater standard of security around this action matching our practices across-the-board.

[petrovska-petro]

Refs:

• transferOwnership. It could transfer it to timelock
• for queueTransaction in the timelock the admin could be a msig where the owners are the folllowing existing msigs: dev_msig, treasury_msig and a new one badger_council_msig
• cap could be introduce one L above this with a require statement check

[gosuto-inzasheru]

conclusions from discussion with @dapp-whisperer:

• yes, moving minting func to the timelock makes sense. security policy currently in place for the badger system should also apply to the badger token itself
• broadening the scope of what governance is (ie making treasury also a signer on dev msig, or something similar) is a good convo to have but outside of the scope of the ticket. convo should take place though
• introducing a mint cap again is outside the scope. introducing such a cap would imply a consensus on inflation rate, which needs a bip first or some form of agreement between councils.

tldr: scope of this ticket is therefore reduced to:

• [ ] transfer ownership to timelock, so that minting cannot be done atomically

[sajanrajdev]

@petrovska-petro, given the reach of the contract in matter, Dapp requested that we include a bit more of testing diligence in the script before executing. Specifically, we wants confirmation via a test that the controller and the BADGER token will continue to work properly after the change.

Adding a simulation of a few of the actions on both the controller and the token within the same script (scripts/issue/1277/mint_controller_admin_update.py) will be enough.