Arbitrum Governance Upgrade Rollout & Timeline

Arbitrum Research & Development Committee (ARDC) Security Member
4

@offchainlabs - Thank you for the detailed comments.

  1. Though the new governor has been audited, it does not appear as though all of its dependencies were included in the audit scope. The governor uses OZ Upgradeable Contracts at commit f960f47267044822613be18e149c2e0ee1a3bf6e, which differs slightly from the v5.0.2 release. For example, the GovernorUpgradeable has a small diff that is not mentioned in the audit scope. Should this small diff also be audited?

The new governor and one of its dependencies, GovernorCountingFractionalUpgradeable.sol, was in scope of the Arbitrum Governor V2 Review. The differences between the v5.0.2 version and the versions of the OpenZeppelin contracts used by the new governor as of commit f960f47267044822613be18e149c2e0ee1a3bf6e were audited by OpenZeppelin separately from the scope in the Arbitrum Governor V2 Review. Since this audit report will not be publicly available until after the end of September, the team that reviewed Arbitrum Governor V2 also reviewed the findings of the internal report and the new governor’s dependency graph to ensure there are no security issues introduced by using OpenZeppelin contracts as of commit f960f47.

  1. The proposal suggests a 17 day moratorium. During this time new proposals could not be created on chain. One alternative could be to use an 10 day L1 Timelock delay in this proposal, this would bring the round trip time to 20 days, just above the max voting period. That way the existing governor could still be used for proposing until the voting period of this proposal ended, if the proposal passed then users would now start using the new governor, if it failed they would continue using the old one. There may be other alternatives to a proposal moratorium that could be explored.

This is an intriguing alternative to the proposal moratorium. We will review it in more details with the ScopeLift team to ensure there are no unforeseen issues to using an extending L1 Timelock to allow proposal submissions to the current Governor Contract. If so, we’ll update the Upgrade Rollout Plan with a new timeline.

On questions #3 and #4, we’ll defer to the ScopeLift team for their response. We do agree that maintaining an up-to-date governance codebase is important for security and we support having a PR made to the repository.