Arbitrum Governance Upgrade Rollout & Timeline

Arbitrum Research & Development Committee (ARDC) Security Member
1

Edit Notice: This Rollout Plan has been updated on Sept 5th, 2024 to remove the need for a Proposal Moratorium based on the suggestion from @offchainlabs. We updated the timeline accordingly.

Abstract

OpenZeppelin, as the Security Member of the ARDC, recommends the following timeline and plan for the Rollout of the Arbitrum Governance Upgrade, based on the recommendations of ScopeLift, to prevent new proposal submissions during key stages of the Upgrade.

We propose a detailed timeline of the anticipated Upgrade Rollout and information on the current and new Governor contacts, including key periods for when each set of contracts should be utilized for the submission of new proposals.

Background

The Governance Upgrade has been funded by a proposal from Tally and the upgrade implementation by ScopeLift has already been reviewed by OpenZeppelin to ensure it is secure. ScopeLift has since shared the finalized contract code and migration scripts which have been available for the community to review for the past two weeks.

As ScopeLift moves forward to propose the upgrade, it’s important to ensure that the Arbitrum community is aware of the need for a moratorium on new proposals during the early stages of the upgrade process. This is due to the fact that the upgrade is being performed by migrating both the Treasury and Core Governor contracts to new smart contracts, rather than performing a proxy upgrade. ScopeLift has specifically stated:

We recommend that once this proposal is onchain, no new proposals are created until after it passes… (or fails, of course). If a proposal were to be created during this time, it would likely get stuck and have to be resubmitted to the corresponding new Governor.

Our initial Rollout Plan included a proposal moratorium period of several weeks that would require delegates to abstain from submitting new proposals during key stages of the upgrade. However, Offchain Labs has since proposed the following solution:

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.

After all parties reviewed this solution, ScopeLift has stated that they will now include the additional 10 day Timelock delay in their proposal, which removes the need for a proposal moratorium. However, it still important for delegate to have clear expectations for when and where new proposals can be submitted during the Upgrade Rollout.

Upgrade Rollout Timeline

Given the requirement for a proposal moratorium while the Upgrade is pending, it’s important that all governance participants are made aware of each stage of the Upgrade Rollout. As such, we recommend all delegates review and understand the following stages of the upgrade timeline below. Please note that some dates are estimates due to the potential for small extensions or delays in the governance process.

  1. On Sept 9th: An Upgrade Proposal will be submitted to upgrade Arbitrum governance through a migration to the new Governor contracts.

  2. Sept 9th to Sept 26th: The Upgrade Proposal will go through a 3-day review period followed by a 14-day vote.

  3. Sept 26th to Oct 16th: Assuming the Upgrade Proposal has passed, it will be pending execution, taking its usual path of going from the L2 Timelock, to the L1 Timelock, and finally to the L2 Executor which can make upgrade calls on the L2 Timelock. This includes an additional 10 delay added. During this time, DAO infrastructure tools, such as Tally, should begin the process of migrating to use the new Governor contracts targeted in the Upgrade, while still preserving the history of prior proposals from the old Governor contracts. This will ensure that all new proposals submitted on-chain by delegates will default to the new Governor contracts.

  4. Oct 16th: The Upgrade Proposal will be executed with a call to the respective timelocks to remove the old Governor’s proposer and canceller roles and add those roles for the new Governors. This will complete the upgrade with new governance contracts having the role permissions necessary to execute any proposals submitted prior.

Proposal Submission Periods

Given the upgrade timeline, there will need to be a clear set of time periods when proposals can submitted to the current legacy Governor contracts and new Governor contacts. With the additional 10-day time delay on the Upgrade Proposal, it should be feasible for the current legacy contracts to be utilize for proposal submissions up until the end of the Upgrade Proposal vote. Once the vote is completed and successful, all future proposals should be submitted to the new Governor contracts. This plan allows proposals to be submitted throughout the Upgrade Rollout timeline with only the minor risk that proposals submitted to the new Governor contracts are disrupted by an unforeseen issue with the execution of the Upgrade Proposal.

Given this new setup, we propose a Legacy Governor Submission Period followed by a New Governor Submission Period to determine where and when new proposals should be submitted:

  • Legacy Governor Proposal Period (Sept 9th to Sept 16th): Proposals should only be submitted to the CURRENT LEGACY Governor contracts during this period. This is already the current status quo for how Arbitrum DAO proposals are submitted and will last up until the end of the voting period of the Upgrade Proposal.

  • Preliminary New Governor Proposal Period (Sept 26th to Oct 16th): Proposals may be submitted to only the NEW Arbitrum Governor contracts between the end of the Voting Period (assuming the Upgrade Proposal has passed) and the Upgrade execution. Any proposals submitted during this time take the risk of an issue in the Upgrade execution disrupting their proposal, although that risk is minimal and will simply require the proposal to be resubmitted later. Tally (@frisson) has committed to migrating their platform to the new Governor contracts during this period so that proposals can be submitted with minimal friction.

Governor Contract Addresses

ScopeLift has already deployed the new governance contracts that will be utilized in the Governance Upgrade. We include information on both the current legacy contracts and new contracts for everyone’s reference during the Upgrade Rollout.

Current Legacy Contracts

New Contracts

Please ensure you use the Current Legacy Contracts for any proposal submissions prior to the Upgrade Proposal and the New Contracts after the Proposal Moratorium has passed. Tally will be performing this migration on their platform and so is the preferred choice for making submissions during this period to avoid confusion.

Impact on Security Council Elections

As first identified by Offchain LAbs, this Governance Upgrade DOES NOT include the Security Council Governors (SecurityCouncilMemberElectionGovernor , SecurityCouncilNomineeElectionGovernor and SecurityCouncilMemberRemovalGovernor). Voters using flexible voting will not be able to take part in Security Council elections by default. The ScopeLift and Tally teams have indicated they are aware of the limitation and have plans to propose additional upgrades in the future to address this concern. We recommend that they propose a plan to roll this upgrade out before the March 2025 Security Council elections begin.

Security Council elections for the next cohort will begin on Sept 15th with final voting starting on Oct 13th. Given the lack of impact on the Security Council Governors and the fact that the Upgrade Proposal will not be executed until Oct 16th, there should be no direct disruption to the Security Council voting process. We do recommend that Arbitrum delegates first cast their votes in the October Security Council election before making use of the new Flexible Voting feature.

Conclusion

We trust this forum post will provide all Arbitrum delegates the information needed to understand the impact of the impending governance upgrade. We specifically ask that all delegates ensure they understand and agree to adhere to the following recommendations:

  1. If you have an on-chain proposal to submit in the near future, please review the Proposal Submission Periods and be aware of the time periods at which to utilize the current legacy Governor contracts (up until Sept 26th) or new Governor contracts (after Sept 26th).

  2. If you wish to submit a proposal during the Preliminary New Governor Proposal Period (Sept 26th to Oct 16th), please ensure that you understand and accept the potential risks, however minor. We highly recommend waiting until Tally has confirmed completion of their migration to the new Governor contracts before submitting proposals during this period.

  3. Once the Upgrade Rollout is complete, ensure that you only use the new Governor contracts for all proposal submissions going forward.

  4. If you wish to make use of the new Flexible Voting feature following the Governance Upgrade, please be aware that it will prevent you from being able to vote in Security Council Elections while in use. Please cast your votes for the Security Council elections starting on Oct 13th before making use of the Flexible Voting feature.

This Upgrade Rollout plan has been developed in cooperation with ScopeLift, Tally, Offchain Labs and the Arbitrum Foundation for which we greatly appreciate their support. If there any questions or concerns regarding this Upgrade Rollout and our recommendations to the community, we welcome feedback in the forum below.

We will monitor and provide updates on the upgrade process as it occurs in the forum, including any potential changes to the estimated timeline. For more information on OpenZeppelin’s role as Security Member of the ARDC, please visit our Notion homepage.

8 Likes
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
3

Looking forward to governance upgrades

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.

5

From ScopeLift, re: moratorium and 10 day L1 Timelock delay, sounds like a great idea. We’ve already edited the proposal creation script to include a parameterizable Timelock delay. We’re happy to work with the proposer to ensure a correct delay configuration.

1 Like
6

Given the confirmation from ScopeLift that @offchainlabs’s solution to add an additional Timelock delay is feasible, we’re going to modify our Rollout Plan to remove the need for a proposal moratorium.

The new target date for the submission of the Upgrade Proposal is now September 9th. Please note that while a proposal moratorium is no longer necessary, delegates will still need to stay informed of the timeline to understand when proposals should be submitted to either the current or new Governor contracts.

We’ll be updating the original post with the new timeline and Rollout Plan updates shortly.

3 Likes
7

We’ve updated the original post above with a new timeline. There is now no proposal moratorium. The main takeaway is that on Sept 26th, the end of the Upgrade voting period, delegates should begin making submissions to the new Governor contracts, assuming the Upgrade proposal has passed.

We greatly appreciate the suggestions from Offchain Labs to make the Upgrade Rollout an easier process for delegates.

3 Likes
8

I’m confirming that Tally plans to upgrade the Security Council Governors before the March 2025 election so that voters using Flexible Voting will be able to take part in Security Council Elections by default.

2 Likes
9

Tell me, why can’t we leave the current addresses of the Governor and the canceller?
If contracts are changing, then why can’t we use a proxy contract so as not to change the current addresses?

1 Like
10

Tell me, why can’t we leave the current addresses of the Governor and the canceller?
If contracts are changing, then why can’t we use a proxy contract so as not to change the current addresses?

This post explains the approach to moving to new addresses rather than upgrading by proxy Arbitrum Governance Smart Contract Upgrade Technical Details

1 Like
11

The OpenZeppelin team is well respected within the community, but as an independent security reviewer I would appreciate the opportunity to review the audit report before voting starts.

I am sure others have similar sentiment here, and since the audit report isn’t available publicly - as a bare minimum I believe it should be shared privately with the Arbitrum Security Council (which includes you, me, and other parties elected by the community).

That said, there are 2 days left until voting starts which might prove not to be actionable time for some involved.

I would also like to emphasize the lack of proportionality that this will create between governance voting and the security council elections.
There will be a period with unequal representation in the governance systems.

As an independent security reviewer I would also like to emphasize this setup is not ideal.
This makes it harder to review, recreate, and leverage existing tooling that is used far spread within the Arbitrum ecosystem to ensure the security of its governance.

All this said, I find this proposal interesting but a couple aspects of it could be tweaked to help ensure better security, verifiability, and consistency with current processes.

6 Likes
12

I believe it should be shared privately with the Arbitrum Security Council (which includes you, me, and other parties elected by the community).

@fred - We are happy to confidentially share the early draft of the audit report with the Arbitrum Security Council that covers the changes introduced in the OpenZeppelin contracts since commit f960f47 so that you may all confirm there is no impact on the Upgrade.

We’ll reach out to you privately to arrange this disclosure.

3 Likes
13

We’ve received feedback from delegates that they would like additional time to see all of items raised by @fred and @offchainlabs fully addressed before voting on this proposal. As a result, we are “canceling” the onchain upgrade proposal. Because Arbitrum governance does not currently allow onchain proposal cancelation, canceling the proposal constitutes labeling the proposal as canceled on Tally and suggesting delegates to vote against.

Thank you all for your feedback. We will follow up with a detailed plan to evolve the proposal to fully address all comments and ensure delegates have enough information to perform a full evaluation.

5 Likes
14

thank you @Frisson I think this is the right move! this kind of things are the ones that should really not be done in a rush.