All permissions of the old timelocks are migrated to the new ones. So yes, the old governors can interact with old timelocks, but those won’t have any power after ZIP5 as it will be transferred to the new timelocks corresponding to the new governors.
Oh, so we’re not just deploying new governors; we’re also deploying new timelocks that differ from the existing ones. I don’t believe that was mentioned in the proposal. If the new governor implementations aren’t already in the zk-governance repository, it would be helpful to open a pull request for them—or, if they’re already there, to link them in the proposal.
Deploying new timelocks could introduce some unexpected scenarios. One example that might be addressed by this proposal is the role of the current Token Governor timelock as a minter and burner admin on the ZK token. Will this proposal remove those roles from the current timelock and assign them to the new timelock instead?
Another consideration is that, under the GovOpsGovernor, we accepted the SEAL Safe Harbor agreement using the old timelock. Does this mean we need to re-accept the agreement under the new governor and timelock?
There may be additional scenarios like these, which is why it might have been better to simply grant and then renounce permissions to the new governor using the existing timelock.
If the new governor implementations aren’t already in the zk-governance repository, it would be helpful to open a pull request for them—or, if they’re already there, to link them in the proposal.
Will this proposal remove those roles from the current timelock and assign them to the new timelock instead?
Yes, it will.
Does this mean we need to re-accept the agreement under the new governor and timelock?
No, we do not need to reaccept it.
There may be additional scenarios like these, which is why it might have been better to simply grant and then renounce permissions to the new governor using the existing timelock.
Unfortunately, the way our timelocks were deployed, the TIMELOCK_ADMIN_ROLE was revoked and our governors do not have any control over it, so the new EXECUTOR_ROLE can not be granted. So the only way to change a governor was to change the timelock as well.
I may be missing something, but this pr seems to only have the protocol handler changes, and redeployment scripts, not the new governor and timelock redeployment scripts or implementation changes. I did find this WIP pr which has the new timelock deployment for the protocol governor, but didn’t find a script for GovOps or the Token Governor
Unfortunately, the way our timelocks were deployed, the TIMELOCK_ADMIN_ROLE was revoked and our governors do not have any control over it, so the new EXECUTOR_ROLE can not be granted. So the only way to change a governor was to change the timelock as well.
I don’t think this is true. Both the GovOps timelock and the Token governor timelock have the TIMELOCK_ADMIN_ROLE. Since the timelocks have the role, a governance proposal for each governor could grant the EXECUTOR_ROLE. PROPOSER_ROLE, and CANCELLER_ROLE to a new governor via a governance proposal on the old governors.
didn’t find a script for GovOps or the Token Governor
True, the Governance contracts have not changed their code, so we reused the existing scripts (while only temporarily changing the hardcoded constants).
I don’t think this is true.
Agree. Now I see that not changing timelock for GovOps / TokenGovernor would’ve been a cleaner approach. In any case, the GovOps timelock did not have any permissions, while all the TokenGovernor’s ones were moved to the new timelock. So the ZIP5 is safe. I do agree with your points and we will try to avoid doing it in the future.
After ZIP5 is executed on L1, an emergency upgrade will have to be performed by the new ProtocolUpgradeHandler to do acceptOwnership() of the new contracts.
The upgrade will contain 5 calls to the following contracts:
0xf553E6D903AA43420ED7e3bc2313bE9286A8F987 (A bridge that allows ZK chains to bridge tokens that may migrate to minting of canonical USDC in the future)
Each call just encodes the call to acceptOwnership() function.
