Change to New Governance Contracts that Allow Proposal Cancellation

Proposals
1

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.

6 Likes
2

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!

1 Like
3

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?

4

updated, appreciate you king

5

Good point Paulo, I updated the proposal title

1 Like
6

Fully agree, this is planned

1 Like
7

I like that you were able to split a large update into two proposals.
However, I have a question.

I looked at the pull request and not all tests were successful.
Can one of the technical specialists who did the tests explain how critical this is?

image
image620×604 26.2 KB

1 Like
8

maybe this above is a question to @bendi so tagging him here

Also, another technical question, are the contracts that were deployed a few months ago mentioned here, not the ones that are going to be used now? if not, why? if so, why does this proposal still doesn’t mention the new governor addresses and says that the addresses will be included before this proposal goes for a temperature check vote?

9

I think it’s necessary to have the ability to cancel proposals. This will allow us to correct mistakes or adapt to changing circumstances more quickly. Also, clearly documenting the changes and motivations in the governance forums will generate more trust in the proposal development process.

I suppose this will help prevent the [Cancelled] tag on Tally and Snapshot, which helps new users avoid confusion with the voting process.

I’m just not entirely clear on the flexible voting; could you explain what this means?

1 Like
10

Hey Paul. The new contracts will be upgradeable, but it’s not yet decided whether the second “upgrade” (in quotes because I don’t mean proxy upgrade) will use the proxy pattern or will transfer timelock permissions again. In general, it is our position that proxy upgrades are more error prone than simply transferring timelock permissions, and that the latter should be normalized as the way to “upgrade” DAO governance contracts in most cases. The only downside, which you have correctly identified, is the need to make sure that third party clients know to cut over to the new contract addresses.

This is the old PR. The tests failed because GitHub does not allow PRs opened by third parties to access repository secrets—in this case those are needed for RPC URL endpoints to run the tests. We’re working with @stonecoldpat from the foundation to get a first-party PR opened with the new code and will update once we have it.

Those contracts include both the Flexible Voting code and the cancel code. Since we’ve decide to break this upgrade up, we have to deploy new ones that only do the latter. They have not been deployed yet, but will be soon. We’re waiting for the aforementioned PR to be opened and approved.

All very good questions. Thank you all for taking the time to look carefully into this!

2 Likes
11

I find no reason not to move forward with this proposal, as it adds significant flexibility and increased security for the future, ensuring agile cancellation when needed. Additionally, the testing and audit by OpenZeppelin give me confidence that everything is in order.

Thanks for the proposal!!

1 Like
12

It is good to allow proposals to be canceled, but what are the process and criteria for doing so? Will there be arbitrary cancellations that affect the efficiency of governance?
It is recommended that the supporting come with a simple refinement rule for the cancellation function:
Clearly define the process, reasons, and triggers for proposal cancellation, such as requiring a quick vote by the community or a quick review by a person with a governance role to cancel a proposal.

The proposal cancellation function is a small feature update, but you can be sure that the team is optimizing it to screen out low-quality or immature proposals in a timely manner to avoid wasting time and resources.

13

As far as I understand, only the one who launched the proposal can cancel it.

If not, then I would like to see a comment from @Frisson

14

Thanks for the great proposal. This is a much-needed upgrade, and in the past practice we’ve encountered many times where Tally proposals have been canceled and didn’t dovetail well with the updated proposal.

My only confusion is whether this is just a technical upgrade or does it involve DAO governance? I mean, under what circumstances does this kind of proposal cancelation usually happen? Does it still have to go through a community proposal and vote (I hope not, that would be too complicated).

1 Like
15

hey @bendi thank you for your quick answers.

In summary, I think this approach is really not ok and therefore I will of course vote against it.

The current gov contracts were made to be upgradable in the first place and this approach of deploying new governance contracts every time we want to upgrade something, is really jarring.

And by jarring I mean what @fred expressed here much better than me:

Also, if there’s even the remote possibility that in less than 6 months, on March 2025 after the next planned change to allow flexible voting, Arbitrum DAO would have 3 different versions of sets of governors, instead of having just one canonical set of governors from it’s beginning, as it does now, this needs to be a decision that is very carefully justified, with much stronger arguments than “it’s less error prone”.

The consequences of changing the governance contract addresses for the biggest L2 in Ethereum needs to be taken into account. I don’t even know, I don’t think anybody knows to be honest, all of the consequences of that change. Numerous 3rd party apps, dune dashboards, internal tools, analytics dashboards, etc. will be impacted by this and will stop working out of the blue. That’s a huge impact.

As @dk3 said here:

And although @Frisson said above “this is planned” I’m not sure if there is a way to do this well at all, and even less, in a timely manner.

To be completely honest, it sounds to me that you, Scopelift and Tally, don’t want to hold the liability of developing the payload that upgrades a governance contract that controls billions of USD by potentially locking forever all of the assets in the arbitrum contracts and treasury. I understand if that’s the case, but please, don’t propose us down a path where we will be changing the governance contracts of the world’s biggest DAO, several times a year.

And honestly, if you continue to be adamant in proposing this approach, I think it’s time for the DAO to reconsider if open zeppelin governor contracts that need to be changed for every upgrade in functionality, are even what we want to use at all.

Because if we’re going to change the governance contracts, to be able to have more functionality like cancelling published proposals, and then change them again to be able to have flexible voting, we might as well just change the governance contracts once, to a new set of governance contracts that can do all of the functionality that the DAO requires and that can be in fact upgraded in-place and are designed from the beginning with modularity in mind, so that we can evolve our governance without having to go through these breaking changes several times a year.

1 Like
16

Hello all, thanks for the proposal.

I have a few questions:

  • @Frisson, is there any particular reason to try to release the “cancel” feature now, instead of waiting for the full deployment next year?
  • @bendi Can you provide a bit more of context on “proxy upgrade x new deployment” (additional sources, for example)? Since a great part of the delegates are not technical folks, it would be great to have more info on that. Also, on your previous collaborations, how many new deployments were made (Gitcoin, PoolTogether, etc)?
1 Like
17

If the code is not committed to the governance repository, long-term maintenance and upgrades may face higher complexity and affect the stability of the governance contract, agree to commit the code to the governance repository.

There is no transfer of funds or change of authority involved, low risk and no impact on historical governance records. Recognition

It is recommended that the timeline for future flexible voting upgrades be clarified, for example, as soon as technically possible after the 2025 Security Council elections, to achieve full compatibility and avoid long-term inconsistency issues. It is also recommended that a simple user guide be published to help new delegates and communities adapt to the new features and operating methods

18

Could you elaborate, maybe with more technical details, on why proxy upgrades are considered more error-prone? This is hard to accept, especially since new contracts might also use the proxy pattern anyway.

The “error-prone” argument isn’t really enough on its own - this risk can be handled with thorough testing of both the contracts and deployment process. We have good tools for this now - a local development fork of the network can be made with foundry’s anvil, impersonating accounts and contracts can simulate all the transactions needed for the upgrade, so the upgrade can be fully simulated and tested. That seems like the right way to handle potentially risky operations.

Also worth noting - if we deploy a new governance contract instead of upgrading, we permanently split the governance history. We can’t undo that, and it makes things permanently harder for any 3rd party apps trying to index the governance data.

The only sensible reason I can see for deploying new contracts is if the upgrade to the new functionalities is not technically possible, as in, the data structures are wildly different and the new implementations cannot be mapped onto the old data.

1 Like
19

Thanks for the proposal @Frisson.

Correct me if I am misunderstanding something - but considering that the now passed extend timelock delay proposal has extended the timelock delay from 3 to 8 days, would having a L1 timelock delay of 10 days for this proposal actually achieve the objective of allowing existing governors to still be used for proposing until the voting period of this proposal has ended?

20

The proposal undeniably adds much-needed functionality to governance. It’s now been presented on a much more robust basis after the adjustments and audits that were requested in previous discussions, but there are still some concerns that need to be addressed.

First, I would like more clarity on the criteria for a delegate to cancel a proposal and the guidelines that will guide these decisions. Given the reputation-based nature of the Arbitrum ecosystem, it is critical that this mechanism is used responsibly and without room for abuse.

Also, limits must be put in place to prevent the same proposal from being submitted and cancelled several times with minor changes. Otherwise, the flow of governance will be significantly complicated.

Another point, will cancelled proposals leave a visible public record? This is an important way to maintain transparency, and in an ecosystem like this where trust in the processes is everything, I think it would be key not to leave these cases hanging in the air.

I understand that the Tally team and delegates have a central role in maintaining order, but I am a bit concerned about how situations of potential sabotage or malicious use of this functionality would be handled.

We know that reputation is a fundamental counterbalance, but we are also in an environment where there is no shortage of actors who might try to destabilize (or troll) the system. Is there a plan in place to prevent this type of risk?