Change to New Governance Contracts that Allow Proposal Cancellation

[EzR3aL]

Im trying to wrap my head around but I think i need some help.
Whats the difference between the current solution and the proposed one?
What are the trade-offs of both and the benefits?
Really appreciate some explanation.

[Argonaut]

Hi, and thanks for this proposal. We appreciate the way it has been divided into two separate proposals, as this new focus provides greater clarity. Regarding this particular proposal, which aims to add the canceling functionality to on-chain voting, We would like to support the proposal, but we have some concerns.

The PR shared in the proposal states the following:

To achieve the Arbitrum Governor V2 upgrade, we at ScopeLift developed contracts, scripts, and tests in a separate repo. This PR brings those contracts into the main Arbitrum governance repo.

We understand that the audit/review was conducted on an external repository. For that reason, wouldn’t it be wise to conduct it again, since it directly impacts the governance repository?

We also share the same concerns regarding the non-use of the proxy upgradeable contract model and all the implications of not using it. We believe there should be solid reasoning for not utilizing it, and these reasons should be clearly presented.

[bendi]

Hey all, I appreciate the healthy discussion. I don’t think a governance forum is the right venue for a longwinded explanation of the technical details of proxy upgrades, but I will share some high level thoughts.

In short, upgrades via proxies are subject to a host of issues that make them more brittle, error prone, and sensitive. These include storage layout collisions, function selector conflicts, initialization bugs, and more. They also limit the scope of what can be added and require developers use the same toolchain (compiler version, etc…) as the originally deployed contracts. Finally, they make it harder to reason about smart contract code and push developers toward writing less-readable code to accommodate their limitations. Here are some resources for further reading if you’re interested. Many more could also be found via Google or Perplexity search.

• GitHub - Quillhash/Proxies-Security: This repository comprises of everything you need to know about Solidity proxies, upgradeable smart contracts and their security.
• Learn How To Make Secure Upgradeable Smart Contracts
• Proxy Upgrade Pattern - OpenZeppelin Docs

For the reasons above, ScopeLift broadly recommends our clients avoid proxy upgrades except in the specific, limited circumstances where the tradeoffs involved make sense. This is not a contrived opinion we’ve backed into for this project, but one we’ve long held and advocated for, and we’re far from the only ones who hold it. These are not theoretical risks. Errors and bugs introduced by upgradeable proxies have caused noteworthy issues in the ecosystem over the years, including for projects like Wormhole, Audius, and Ronin Bridge just to name a few.

Furthermore, migrating to a new Governor is not an uncommon approach for updating DAO governance contracts. We have helped a number of DAOs upgrade to new Governors via this process, including Gitcoin, Radworks, and PoolTogether. We’re currently helping Compound upgrade with this approach as well. In fact, many DAOs don’t even use proxy upgradeable Governors, and enabling the non-proxy upgrade path is one of the reasons the Timelock exists as a separate contract, rather than simply enforcing the execution delay inside the Governor itself.

@paulofonseca

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

@paulofonseca I’m not sure the point you’re making here. ScopeLift and Tally want the upgrade to the contracts to be a safe and secure as possible, period. There’s no secret reason we’re choosing this approach, it’s simply the one that we think has the best set of tradeoffs. To review, those tradeoffs are:

Proxy Upgrades

• Pros: Governor address stays the same
• Cons: Upgrade process subject to the risks outlined above

Timelock Transfer Upgrades

• Pros: Less error prone and more flexible
• Cons: Governor address changes

While it’s not totally trivial to change the Governor address, the change is one that needs to be made to software which is offchain. Clients, dune dashboards, etc… can be updated, and the process of updating them does not put funds at risk. We think prioritizing onchain security, even if slightly at the expense of offchain integrators, is the right call. Note that Tally has skin in the game here: they have to support the changing Governor address in their client. In general, we think offchain DAO tooling should be built with this expectation in mind, i.e. that new Governors will be deployed as a regular process.

I hope this clears up the concerns. I do appreciate the discussion, but also want to encourage everyone participating to do so in good faith, and to extend the benefit of the doubt to others that they are doing the same. We’ve gone to great lengths to extensively test the upgrade process. Our number one priority is making sure the upgrade process is 100% safe and secure. That’s what driving our recommendations.

[Juanrah]

I will support this proposal, as it prioritizes on-chain security and introduces key governance improvements like proposal cancellation and flexible voting. OpenZeppelin’s track record and the thorough testing process provide confidence in the upgrade’s safety.

While changing Governor addresses impacts off-chain tools, this tradeoff is preferable to the risks associated with proxy upgrades pointed out by bendi. Important to note that the separation of Timelock functionality ensures funds remain secure during this transition.

The DAO must continue evolving, and this proposal is a step forward. I would just add that proactive communication with stakeholders will be essential to minimize any disruption during the transition.

[andreiv]

Thanks for the response!

While I agree with your points about upgradability, I think this falls more under preference and tradeoffs, just as you said, it’s not about choosing the technically superior option. My main issue with this decision is that it feels big enough to not be in the scope of the functionality upgrade itself-proposal cancellation.

Changing the upgradability strategy of the DAO contracts is a very serious deal, and maybe this should be a decision in itself. This affects how the future upgrades are done, affects the ease of indexing of historical data forever, and potentially can require completely different indexer implementations for all 3rd parties in the future if new upgrades change the implementations a lot. I’m not arguing against different upgrading strategies or the proposal cancellation functionality; I’m arguing against changing the governance upgrade strategy now, to the level where I think this is a more important discussion than the proposal cancellation functionality itself. Considering the current contracts are upgradable, I could argue that the DAO’s current stance on this topic is that contracts should be upgraded through proxy implementations rather than replaced. Changing the upgrading strategy of the contracts is a one-way door which we cannot come back to and “fix” once historical data is split.

If we proceed with the decision to make a new deployment and adopt this new upgrading strategy in the future, it’s unclear why then the new contracts implement the upgradability function. It feels like taking on the complexity risk without fully utilizing the benefits.

I am overly simplifying this, but it’s just as if instead of painting the walls, in order to avoid spilling paint on the floor, we’re building a new house next door with walls of different colors, which can be painted over either way.

[paulofonseca]

then I really don’t understand this recommendation @bendi, please help me understand.

if you say that upgradeable smart contracts are “a huge anti-pattern” why are you recommending to change our governance smart contracts to a new version… that is still upgradeable?

also, by having this position, aren’t you implicitly saying that Offchain Labs/Arbitrum Foundation made the wrong move by choosing upgradeable smart contracts for the Arbitrum DAO’s governance in the beginning? and aren’t you even kinda saying that OpenZeppelin made the wrong move by developing a whole governor standard that is built from the ground up to be upgradeable?
if that’s the case then, I’ll repeat my previous argument, why are we using upgradeable OZ governor smart contracts, at all?

I would also love to have the perspective of Offchain Labs people and Open Zeppelin people on this matter to be honest, because this contradiction doesn’t really make sense to my smooth brain.

Also, I really think this issue of “deciding on the governance contracts upgrade approach” should be a DAO wide decision and independent of the “do we want cancellable onchain proposals (for when the proposals are on their pending state, before the voting starts)” decision. Because again, this approach to “change governance contracts for every new governance feature” has huge consequences, as I described previously.

And another question, since your position is so strongly against upgrading contracts, it seems highly likely that, despite your answer here:

@bendi

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.

you will most likely be proposing deploying new governance contracts yet again, as to be congruent with your position against upgrading contracts.

so, why are you proposing to do this change, for the cancellable proposals, now? and then a second change after the Security Council elections in March 2025 for the flexible voting?

wouldn’t it be better if we would only do just one change of governance contracts, that would have to be communicated to all downstream 3rd party apps and consumers of our governance data, only once, after the March 2025 security council elections? and after all the issues identified by offchain labs previously about the security council governors are sorted out? and just change all 5 governors once, after March 2025?

in essence, do you feel that we really need the ability for the proposer to cancel proposals (in between the time they post the proposal on monday and the time the proposal voting starts on thursday), from now until after March 2025? do you feel we need that so much that it would warrant breaking the governance historical data of Arbitrum DAO and force all downstream 3rd party apps and consumers to update their stuff… twice… in the next 6 months? instead of just one time?

so… why do this now?

[Frisson]

@duokongcrypto

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.

During the proposal delay phase, before the voting period has started, the delegate who put the proposal onchain will have the right to cancel it. This means voting on the proposal will not proceed. More information can be found here: Arbitrum Governance Smart Contract Upgrade Technical Details

[Frisson]

@Argonaut

We understand that the audit/review was conducted on an external repository. For that reason, wouldn’t it be wise to conduct it again, since it directly impacts the governance repository?

The code itself has already been audited. I’m not sure opening an issue in the Arbitrum governance repository is relevant to the audit.

[gauntlet]

These changes make sense and address an existing annoyance that results in many versions of proposals on the Arbitrum Tally page. That said, we’re watching the technical discussions re the re-deployment from the foundation following testing failures and feedback from stakeholders to understand if there are any unforeseen risks prior to voting.

[Frisson]

@GensDAO

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.

Change to New Governance Contracts that Allow Proposal Cancellation

During the proposal delay phase, before the voting period has started, the delegate who put the proposal onchain will have the right to cancel it. This means voting on the proposal will not proceed. More information can be found here: Arbitrum Governance Smart Contract Upgrade Technical Details

@GensDAO

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.

Why would this make the flow of governance complicated?

@GensDAO

Another point, will cancelled proposals leave a visible public record?

Yes, the proposals will exist onchain in a cancelled state.

[Blueweb]

The following reflects the views of the Lampros DAO (formerly ‘Lampros Labs DAO’) governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.

Based on the ongoing discussions, it is evident that upgrading the governance contracts carries risks, and deploying a new governor contract with cancellation functionality is a necessary step. However, deploying another new contract within a few months to address other issues seems inefficient and could be consolidated into a single deployment.

Are there any other reasons that we should know for urgency in this change being deployed right away?

@paulofonseca

Wouldn’t it be better if we only made one change to the governance contracts, communicating this to all downstream third-party apps and consumers of governance data just once—after the March 2025 Security Council elections? This would allow time to address all previously identified issues with the security council governors.

We believe that combining the changes into one deployment after March 2025 would streamline the process and reduce the burden on downstream users.

Additionally, since the current contract was upgradable but is still being replaced, it may be worth considering avoiding upgradability in the new contracts altogether. Deploying a final, non-upgradable contract could simplify future governance and eliminate complexities associated with potential upgrades.

Are there specific reasons why we should have the new contracts upgradeability?

[Bob-Rossi]

I’d be for this. In short, this is a nice convenience upgrade for the DAO at no cost to the DAO. Tally has proven themselves capable of these types of deliverables and I trust their reasoning behind New vs Upgradeable contacts. The contract has been tested and audited by OpenZeppelin, so no concerns there.

[0x_ultra]

@Frisson thanks for the proposal. I fully support the introduction of proposal cancellation. The current system demands excessive coordination from the DAO for cancellation, which is both frustrating and not ideal for security.

Regarding the debate on whether to upgrade the current contract or create a new one, I believe there are not significant differences between the two options. On the one hand, deploying a new contract provides a cleaner on-chain solution with a clear distinction between proposals that can be canceled and those that cannot. However, it requires all tooling to support the new contract, which may lead to some downtime for external tooling as support is added.

On the other hand, an upgrade is a more seamless option for developers because all external tooling will continue to work as is. The respective teams can take their time implementing support for the canceling feature. While it may be riskier, I am confident that the Tally team will conduct thorough testing before pushing the upgrade to production.

What’s best? I think that we are focusing too much on formalities, forgetting that our goal is improving the security of the DAO and ease of execution for proposal cancellation. This is my opinion, but if there are other aspects that I’m not considering, I’m open to discussion.

[paulofonseca]

@Bob-Rossi

at no cost to the DAO

this is incorrect @Bob-Rossi. the DAO has paid $220,000 USD for this and other improvements, in this onchain proposal that was executed in April 16th, 2024.

[offchainlabs]

We’re excited to see, and deeply value, the efforts of Tally, as well as other delegates and teams in their ongoing contributions to enhancing ArbitrumDAO’s onchain governance infrastructure. This specific proposal, if passed, aims to introduce the ability for an ArbitrumDAO AIP author to cancel an onchain proposal, as outlined in the original Forum Post to Expand Tally Support for the Arbitrum DAO. To enable onchain proposal cancellation, the current implementation plan proposes deploying new Arbitrum Core Governor and Arbitrum Treasury Governor contracts, which would both use OpenZeppelin Contracts 5.0.

After reviewing the current implementation plan, we at Offchain Labs, would like to propose an alternative approach for consideration. Instead of adopting OpenZeppelin Contracts 5.0, we recommend performing a proxy upgrade to the existing OpenZeppelin 4.x-based governor contracts to add the new proposal cancel function. This alternative approach avoids the need to deploy new contracts, cuts down the code diff, and provides a streamlined path to enable the proposal cancel function.

While we recognize the risks associated with complex proxy upgrades, we believe this specific case—making a minimal addition to the existing code to enable cancellation—entails low risk and complexity. In our view, this approach is less complex and easier to maintain, compared migrating to entirely new contracts. The complexity of execution, the externalities, and the long term engineering & codebase maintenance costs are important factors to consider when performing any sort of upgrade to production software.

Looking ahead, we acknowledge that some future proposals, such as those that entail widespread changes to storage layout, may indeed necessitate a migration to new governor contracts. However, we feel that this proposal isn’t one of those cases.

We would welcome the opportunity to collaborate with both delegates and the team to explore this alternative approach further.

[Frisson]

Thank you everyone for your feedback on the question of whether to implement this proposal via proxy upgrade or via deploying new contracts. In particular, we appreciate @offchainlabs feedback given their valuable perspective as the original developers and maintainers of Arbitrum governance contracts. Implementing this proposal via proxy upgrade does require meaningful additional development, so we will pause the governance process on this proposal while we explore this alternative approach further.

[Bob-Rossi]

Hey, thanks for pointing this out. It appears this discussion is paused anyway, but if it comes back I’ll keep this in mind.