Arbitrum Governance Upgrade Rollout & Timeline

Arbitrum Research & Development Committee (ARDC) Security Member
2

Flexible voting allows an individual delegate to vote multiple times with For/Against/Abstain, each time with a fraction of their votes. DeFi protocols that wish to can then upgrade their contracts to allow their users to vote with their DeFi-locked tokens. Users would be able to use defi without losing their ability to vote. However, unless the DeFi protocols also implement an additional delegation mechanism, these DeFi users will be able to vote directly but will not be able to nominate a delegate to do so on their behalf.

In reviewing the code for this proposal we, Offchain Labs, have some technical comments that we would like to raise to the DAO’s attention:

  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?

  2. 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.

  3. The proposal only upgrades 2 of the 5 Arbitrum One governors. That means that when votes take place in the 3 other governors (SecurityCouncilMemberElectionGovernor, SecurityCouncilNomineeElectionGovernor and SecurityCouncilMemberRemovalGovernor), voters using flexible voting will not take part by default. For flexible voting to be compatible with all 5 governors, the SecurityCouncilMemberRemovalGovernor must be upgraded and flexible voting clients must build in custom support for the SecurityCouncilNomineeElectionGovernor and SecurityCouncilMemberElectionGovernor. This could have an unexpected effect on governance dynamics, giving non-flexible votes an exaggerated effect when using those governors and affecting quorums. Users using flexible voting may be surprised that they are unable to participate in security council elections.
  4. The code is not presented as a PR to the governance repository. We believe that this will make it harder to maintain the codebase going forward, as the code would be fragmented across different repos using different dependencies and solidity versions. The code will also not benefit from the governance test suite, CI and tooling already present in the governance repository. We suggest considering that a PR be made to the governance repository as we think that that would make long term maintenance more practical.
4 Likes