Arbitrum

Constitutional / Non-Constitutional
Constitutional

Abstract
This proposal will move the Arbitrum Core Governor and Arbitrum Treasury Governor contracts to new contacts that allow on-chain proposal cancellation. This is accomplished by transferring the proposer and canceller roles from the current Arbitrum Core Governor and Arbitrum Treasury Governor to newly deployed Governor contracts that include proposal cancellation functionality.

Motivation
As part of Tally’s proposal to Expand Support for the Arbitrum DAO, Scopelift developed an upgrade to the Arbitrum governance contracts that adds the ability to cancel proposals and adds Flexible Voting to the Arbitrum Treasury and Arbitrum Core governors. The proposal to implement the upgrade did not pass, primarily because delegates wanted to see the points of feedback raised by Offchain Labs that are listed below fully addressed before voting on the upgrade.

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

In order to most efficiently address these points of feedback, we divided the upgrade into two separate proposals with separate timelines.

• This proposal to add cancel functionality to the Arbitrum Core and Arbitrum Treasury governors is the first of the two proposals. This proposal is already audited and does not need to include the Security Council governors in scope. We presented this proposal as a PR to the governance repository.
• The second of the two proposals will add Flexible Voting to all five Arbitrum governors, including the Security Council Election governors. This proposal will require significant additional development time, particularly given that the Security Council governors are heavily customized. We plan to implement this upgrade after the March 2025 Security Council Election. This will allow plenty of time for the audit of OZ Upgradeable Contracts at commit f960f47267044822613be18e149c2e0ee1a3bf6e to be completed and published. We will present this proposal as a PR to the governance repository before beginning the governance process.

Specifications
This proposal will:

1. Grant the newly deployed Core Governor and Treasury Governor contracts the ‘PROPOSER_ROLE’ and ‘CANCELLER_ROLE’ on the timelock contract.
2. Revoke the current Core Governor and Treasury Governor contracts’ ‘PROPOSER_ROLE’ and ‘CANCELLER_ROLE’ on the timelock contract.

This proposal has a longer than usual L1 timelock delay of 10 days, so the existing governors can still be used for proposing until the voting period of this proposal has ended.

The new Governor contracts will be deployed on Arbitrum One at the following addresses:

• Core Governor: [to be added prior to moving to temp check]
• Treasury Governor: [to be added prior to moving to temp check]

These new contracts include the following enhancements:

• Proposal Cancellation: Allows the delegate who submitted a proposal to cancel it during the delay phase, before voting begins.
• The new Governors maintain all existing features of the current Governors, including custom relay functionality and fractional quorum calculations.

The rationale for upgrading the Governors by granting and revoking roles on the Timelock contract instead of using the proxy upgradeable contract pattern is discussed in detail in this forum post.

Security Considerations

• The new Governor contracts have been tested and audited by OpenZeppelin.
• This transfer does not move any funds or change permissions on the Timelock contracts. Historical governance actions will remain visible and valid.

Post-Transfer Actions

• Immediately after this transfer executes, Tally will update to interface with the new Governor contracts.
• Delegates should use the new Governor contracts for all future proposal submissions.
• The old Governor contracts will remain on-chain but will no longer have the ability to execute proposals.

Timeline
If this proposal passes, the transfer will be executed immediately after the Timelock delay. By approving this proposal, the Arbitrum DAO will upgrade its governance infrastructure, enabling new features and improvements in the governance process.

Adding the cancel functionality to on-chain proposals feels like a solid upgrade, and I don’t see any drawbacks. I’ve reviewed Offchain Labs’ concerns and appreciate this proposal wasn’t rushed and the decision to split this into two separate proposals, allowing more focused feedback. My only concern was security, but with OpenZeppelin’s review/audit already completed, I’m confident in moving forward.

@Frisson There’s a small typo in the Abstract—it says “Arbitrum Gore” instead of “Arbitrum Core,” haha. Other than that, let’s push this proposal through and move to the temp-check!

Hey @Frisson! I find the title of this proposal is a bit misleading… potentially… because this is not an upgrade of the (current) governance contracts, this is a transfer of timelock permissions to the newly deployed governance contracts.

Given that, I think we should title this proposal: “Change to new governance contracts that allow proposal cancellation” or something along those lines.

Also, as I mentioned before, we should conduct a serious effort in communicating that the governance contracts of Arbitrum are going to change so that all 3rd party apps can update accordingly. And this type of change should be communicated through official channels by the Arbitrum Foundation I believe.

And also, a question:

If using the proxy upgradeable contract pattern was not used this time because it wasn’t the most secure option according to Scopelift, will it be used in the second upgrade to allow for flexible voting? If so, why? If not, will the governor contracts change again in a few months because of the flexible voting change?

updated, appreciate you king