3 delay tiers are defined, both for granting permissions and executing actions:
LONG: for critical actions that should not happen frequently, or not happen at all. E.g. granting a contract permission to mint BAL, which has the potential impact of modifying the tokenomics and the whole liquidity mining programme.
MEDIUM: for actions that might have a big impact, but are expected to happen from time to time. E.g, granting permission to add gauges in the gauge controller, which will in turn indicate the minter how much to mint. This should only happen e.g. with a new gauge adder.
SHORT: for operations that are expected to happen frequently and/or with very limited impact. E.g. set a network remapping manager in the voting escrow remapper.
The tiers may have different values in different networks. E.g. in Sepolia or any testnet we can have the long delay be 2 days, while in mainnet it could be a month. While mainnet has more actions than L2s, in principle the values should be the same in any production network.
For existing contracts, we can define this in the deployment scripts, since all the delays will be set at once by the migrator. But for new contracts, we'll need to specify what the delays will look like for each applicable action.
The proposal would be to build a script that generates a JSON with the recommended delays for each task. Then, we can check that the delays are in place on-chain with a CI job.
Again, for existing tasks this will happen right after the authorizer migration is complete, since the delays will be set by the migrator itself. For new task, we'll need to wait until governance (i.e. the timelock authorizer root) sets up the delays appropriately.
As a second step, we can also do a script that aggregates the delay suggestions by iterating the tasks as we did with the addresses.
With the new timelock authorizer, we'll be including a developer recommendation of what the timelocks should be for each action.
An early example can be found in the migration configuration for Sepolia.
In summary:
LONG: for critical actions that should not happen frequently, or not happen at all. E.g. granting a contract permission to mint BAL, which has the potential impact of modifying the tokenomics and the whole liquidity mining programme.MEDIUM: for actions that might have a big impact, but are expected to happen from time to time. E.g, granting permission to add gauges in the gauge controller, which will in turn indicate the minter how much to mint. This should only happen e.g. with a new gauge adder.SHORT: for operations that are expected to happen frequently and/or with very limited impact. E.g. set a network remapping manager in the voting escrow remapper.The proposal would be to build a script that generates a JSON with the recommended delays for each task. Then, we can check that the delays are in place on-chain with a CI job. Again, for existing tasks this will happen right after the authorizer migration is complete, since the delays will be set by the migrator itself. For new task, we'll need to wait until governance (i.e. the timelock authorizer root) sets up the delays appropriately.
As a second step, we can also do a script that aggregates the delay suggestions by iterating the tasks as we did with the addresses.