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.
Specifications This proposal will:
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:
These new contracts include the following enhancements:
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
Post-Transfer Actions
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.
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.
Specifications This proposal will:
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:
These new contracts include the following enhancements:
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
Post-Transfer Actions
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.
The introduction of clearer proposal cancellation authority, particularly where exercisable by the Security Council, appears to formalise discretionary intervention within the governance execution process.
Has consideration been given to how this expanded intervention pathway may affect decentralisation assessments under the EU MiCA framework, especially where a defined body retains structured authority to halt or modify governance outcomes?
The introduction of clearer proposal cancellation authority, particularly where exercisable by the Security Council, appears to formalise discretionary intervention within the governance execution process.
Has consideration been given to how this expanded intervention pathway may affect decentralisation assessments under the EU MiCA framework, especially where a defined body retains structured authority to halt or modify governance outcomes?
While such powers may be justified for security and error mitigation, their existence may be relevant when analysing whether governance remains sufficiently autonomous or is subject to identifiable managerial control.
The introduction of clearer proposal cancellation authority, particularly where exercisable by the Security Council, appears to formalise discretionary intervention within the governance execution process.
Has consideration been given to how this expanded intervention pathway may affect decentralisation assessments under the EU MiCA framework, especially where a defined body retains structured authority to halt or modify governance outcomes?
The introduction of clearer proposal cancellation authority, particularly where exercisable by the Security Council, appears to formalise discretionary intervention within the governance execution process.
Has consideration been given to how this expanded intervention pathway may affect decentralisation assessments under the EU MiCA framework, especially where a defined body retains structured authority to halt or modify governance outcomes?
While such powers may be justified for security and error mitigation, their existence may be relevant when analysing whether governance remains sufficiently autonomous or is subject to identifiable managerial control.
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.
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.
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.
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.
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.
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:
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.
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?
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.
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.
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.
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.
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.
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.
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:
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.
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?
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.
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?
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!
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.
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.
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?
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!
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.
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.
Hi everyone, quick update here - as mentioned on the governance call, the proposal cancellation changes have been bundled with the DVP changes on the constitutional onchain AIP that is on Tally at the moment.
Update: the implementation and security audit for the proposal cancellation work is complete.
The execution payload is currently under a security audit. In accordance to the process laid out in this thread, if DVP Quorum upgrade ( https://forum.arbitrum.foundation/t/constitutional-dvp-quorum-for-arbitrumdao-implementation-parameters/30484 ) proceeds to an onchain vote, the payloads will be combined, unless a significant portion of delegated voting power (30M ARB) objects by Thursday, Feb. 5th, in which case the proposal cancellation upgrade will be taken through a separate temperature check. This is done to avoid unnecessary voting cycles on an upgrade which has been extensively discussed in the past and the community has reached alignment on the motivation and specification of.
Update: the implementation and security audit for the proposal cancellation work is complete.
The execution payload is currently under a security audit. In accordance to the process laid out in this thread, if DVP Quorum upgrade ( https://forum.arbitrum.foundation/t/constitutional-dvp-quorum-for-arbitrumdao-implementation-parameters/30484 ) proceeds to an onchain vote, the payloads will be combined, unless a significant portion of delegated voting power (30M ARB) objects by Thursday, Feb. 5th, in which case the proposal cancellation upgrade will be taken through a separate temperature check. This is done to avoid unnecessary voting cycles on an upgrade which has been extensively discussed in the past and the community has reached alignment on the motivation and specification of.
We invite everyone to participate in the upcoming ‘Open Discussion of Proposals Governance Call’ where this upgrade will also be covered.
what happens if it’s a malicious proposal?
what happens if it’s a malicious proposal?
Great points - the Security Council is the last resort that needs to step in to halt the outcome of the proposal in the event that it is passed maliciously. That said, such malicious proposals should also be cancellable before the Security Council has to step in with this proposal cancellation function.
Hi everyone! Since we have not received any feedback or strong objections on when the proposal cancellation function can be called in the 2 week period, we are proceeding with the DAO’s optimistic approval that proposals should only be cancelable by the proposer during the pending period before voting begins, unless the proposal is clearly malicious.
We will work together with the @Arbitrum Foundation moving forward on next steps, and update the DAO when this is ready to go onchain via a constitutional AIP on Tally. Thank you!
Hi everyone, thanks for joining the call yesterday! For those who couldn't make it or would like to revisit the discussion, here’s the recording: 🔗 Meeting Recording
As discussed, we’re moving forward with an optimistic governance approach regarding when proposals can be canceled. Our recommendation is that proposals should only be cancelable by the proposer during the pending period before voting begins, unless the proposal is clearly malicious. This is to ensure the integrity of the voting process and respect the legitimacy of votes already cast.
Hi everyone,
Following the detailed feedback from @OffchainLabs in this comment, Tally will proceed with the proxy-upgrade path to introduce proposal cancellation functionality to the Arbitrum DAO governance contracts.
Hi everyone,
Following the detailed feedback from @OffchainLabs in this comment, Tally will proceed with the proxy-upgrade path to introduce proposal cancellation functionality to the Arbitrum DAO governance contracts.
Tally will upgrade to the Treasury Governor and Core Governor contracts to implement the cancel() functionality. To do each upgrade, Arbitrum DAO will have to pass a proposal to upgrade each contract in place.
The change itself is small, just a few lines of Solidity. Most of the work here is auditing, integration testing, and dry runs to make sure that the upgrade goes smoothly.
Offchain Labs confirmed that a proxy upgrade preserves the DAO’s existing contract addresses and historical data, while cleanly inserting the new cancellation logic.
It avoids migrating any voter balances or open proposals, and reduces operational risk for delegates.
Before we lock in the workstream and audit slot, we want to share cancellation details that we would strongly recommend.
We suggest that proposals should only be cancelable by the proposer during the pending period before voting begins. All of the past Arbitrum proposals that someone wanted to cancel were caught during the pending period (typos, wrong addresses included in proposal calldata), and having proposals be canceled when there are already votes cast can raise questions towards the legitimacy of the cancelation, unless it is an outrightly malicious proposal.
We’re open to feedback on this point. Please comment in this thread if you have a strong view about when proposals can be canceled. If there are no strong objections raised in 2 weeks, we would assume that the DAO has optimistically agreed to this detail.
Additionally, we’re happy to host a short governance call (details below) to walk delegates through how the proposal cancellation feature works, how delegates can work with Tally to cancel any proposal that was erroneously created, and address any potential feedback on when proposals should be cancellable.
Call details:
29th July (Tuesday) at 3pm UTC (before Open Discussion of Proposals Governance Call)
Meeting link: https://meet.google.com/fys-ejpy-jgn
Looking forward to collaborating and shipping this improvement!
Sharing an update after comments from @paulofonseca on the GRC call on proposal cancellation details - sorry I had to clarify most of these with our engineering team and couldn’t answer timely on the call yesterday.
On when the proposal can be cancelled - the proposal can only be canceled during the pending period before voting, and this is enforced at contract level.
On who can cancel - Only the proposal author can cancel proposals, and this is enforced at contract level.
In the event that the proposal author is malicious, and in the edge case that the proposal got majority FOR and achieved quorum, the Security Council would have to intervene to manually cancel the proposal.
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.
Hi everyone, quick update here - as mentioned on the governance call, the proposal cancellation changes have been bundled with the DVP changes on the constitutional onchain AIP that is on Tally at the moment.
Update: the implementation and security audit for the proposal cancellation work is complete.
The execution payload is currently under a security audit. In accordance to the process laid out in this thread, if DVP Quorum upgrade ( https://forum.arbitrum.foundation/t/constitutional-dvp-quorum-for-arbitrumdao-implementation-parameters/30484 ) proceeds to an onchain vote, the payloads will be combined, unless a significant portion of delegated voting power (30M ARB) objects by Thursday, Feb. 5th, in which case the proposal cancellation upgrade will be taken through a separate temperature check. This is done to avoid unnecessary voting cycles on an upgrade which has been extensively discussed in the past and the community has reached alignment on the motivation and specification of.
Update: the implementation and security audit for the proposal cancellation work is complete.
The execution payload is currently under a security audit. In accordance to the process laid out in this thread, if DVP Quorum upgrade ( https://forum.arbitrum.foundation/t/constitutional-dvp-quorum-for-arbitrumdao-implementation-parameters/30484 ) proceeds to an onchain vote, the payloads will be combined, unless a significant portion of delegated voting power (30M ARB) objects by Thursday, Feb. 5th, in which case the proposal cancellation upgrade will be taken through a separate temperature check. This is done to avoid unnecessary voting cycles on an upgrade which has been extensively discussed in the past and the community has reached alignment on the motivation and specification of.
We invite everyone to participate in the upcoming ‘Open Discussion of Proposals Governance Call’ where this upgrade will also be covered.
what happens if it’s a malicious proposal?
what happens if it’s a malicious proposal?
Great points - the Security Council is the last resort that needs to step in to halt the outcome of the proposal in the event that it is passed maliciously. That said, such malicious proposals should also be cancellable before the Security Council has to step in with this proposal cancellation function.
Hi everyone! Since we have not received any feedback or strong objections on when the proposal cancellation function can be called in the 2 week period, we are proceeding with the DAO’s optimistic approval that proposals should only be cancelable by the proposer during the pending period before voting begins, unless the proposal is clearly malicious.
We will work together with the @Arbitrum Foundation moving forward on next steps, and update the DAO when this is ready to go onchain via a constitutional AIP on Tally. Thank you!
Hi everyone, thanks for joining the call yesterday! For those who couldn't make it or would like to revisit the discussion, here’s the recording: 🔗 Meeting Recording
As discussed, we’re moving forward with an optimistic governance approach regarding when proposals can be canceled. Our recommendation is that proposals should only be cancelable by the proposer during the pending period before voting begins, unless the proposal is clearly malicious. This is to ensure the integrity of the voting process and respect the legitimacy of votes already cast.
Hi everyone,
Following the detailed feedback from @OffchainLabs in this comment, Tally will proceed with the proxy-upgrade path to introduce proposal cancellation functionality to the Arbitrum DAO governance contracts.
Hi everyone,
Following the detailed feedback from @OffchainLabs in this comment, Tally will proceed with the proxy-upgrade path to introduce proposal cancellation functionality to the Arbitrum DAO governance contracts.
Tally will upgrade to the Treasury Governor and Core Governor contracts to implement the cancel() functionality. To do each upgrade, Arbitrum DAO will have to pass a proposal to upgrade each contract in place.
The change itself is small, just a few lines of Solidity. Most of the work here is auditing, integration testing, and dry runs to make sure that the upgrade goes smoothly.
Offchain Labs confirmed that a proxy upgrade preserves the DAO’s existing contract addresses and historical data, while cleanly inserting the new cancellation logic.
It avoids migrating any voter balances or open proposals, and reduces operational risk for delegates.
Before we lock in the workstream and audit slot, we want to share cancellation details that we would strongly recommend.
We suggest that proposals should only be cancelable by the proposer during the pending period before voting begins. All of the past Arbitrum proposals that someone wanted to cancel were caught during the pending period (typos, wrong addresses included in proposal calldata), and having proposals be canceled when there are already votes cast can raise questions towards the legitimacy of the cancelation, unless it is an outrightly malicious proposal.
We’re open to feedback on this point. Please comment in this thread if you have a strong view about when proposals can be canceled. If there are no strong objections raised in 2 weeks, we would assume that the DAO has optimistically agreed to this detail.
Additionally, we’re happy to host a short governance call (details below) to walk delegates through how the proposal cancellation feature works, how delegates can work with Tally to cancel any proposal that was erroneously created, and address any potential feedback on when proposals should be cancellable.
Call details:
29th July (Tuesday) at 3pm UTC (before Open Discussion of Proposals Governance Call)
Meeting link: https://meet.google.com/fys-ejpy-jgn
Looking forward to collaborating and shipping this improvement!
Sharing an update after comments from @paulofonseca on the GRC call on proposal cancellation details - sorry I had to clarify most of these with our engineering team and couldn’t answer timely on the call yesterday.
On when the proposal can be cancelled - the proposal can only be canceled during the pending period before voting, and this is enforced at contract level.
On who can cancel - Only the proposal author can cancel proposals, and this is enforced at contract level.
In the event that the proposal author is malicious, and in the edge case that the proposal got majority FOR and achieved quorum, the Security Council would have to intervene to manually cancel the proposal.
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.
Hi everyone, thanks for joining the call yesterday! For those who couldn't make it or would like to revisit the discussion, here’s the recording: 🔗 Meeting Recording
As discussed, we’re moving forward with an optimistic governance approach regarding when proposals can be canceled. Our recommendation is that proposals should only be cancelable by the proposer during the pending period before voting begins, unless the proposal is clearly malicious. This is to ensure the integrity of the voting process and respect the legitimacy of votes already cast.
We’ve suggested a two-week contest period, ending on August 4, 2025. If no strong objections are raised by then, we’ll consider this approach approved by the DAO. After August 4, we’ll evaluate with other key stakeholders like the Foundation on whether this update can be bundled with other constitutional AIPs for an onchain vote. If so, we’ll move forward with launching the proposal on Tally.
Let me know if you have any questions. Thanks again!
Sharing an update after comments from @paulofonseca on the GRC call on proposal cancellation details - sorry I had to clarify most of these with our engineering team and couldn’t answer timely on the call yesterday.
On when the proposal can be cancelled - the proposal can only be canceled during the pending period before voting, and this is enforced at contract level.
On who can cancel - Only the proposal author can cancel proposals, and this is enforced at contract level.
In the event that the proposal author is malicious, and in the edge case that the proposal got majority FOR and achieved quorum, the Security Council would have to intervene to manually cancel the proposal.
Hope this helps! Let us know if there are any additional questions that we have not addressed.
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.
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.
Thanks for the proposal @Frisson.
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.
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?
Hi everyone, thanks for joining the call yesterday! For those who couldn't make it or would like to revisit the discussion, here’s the recording: 🔗 Meeting Recording
As discussed, we’re moving forward with an optimistic governance approach regarding when proposals can be canceled. Our recommendation is that proposals should only be cancelable by the proposer during the pending period before voting begins, unless the proposal is clearly malicious. This is to ensure the integrity of the voting process and respect the legitimacy of votes already cast.
We’ve suggested a two-week contest period, ending on August 4, 2025. If no strong objections are raised by then, we’ll consider this approach approved by the DAO. After August 4, we’ll evaluate with other key stakeholders like the Foundation on whether this update can be bundled with other constitutional AIPs for an onchain vote. If so, we’ll move forward with launching the proposal on Tally.
Let me know if you have any questions. Thanks again!
Sharing an update after comments from @paulofonseca on the GRC call on proposal cancellation details - sorry I had to clarify most of these with our engineering team and couldn’t answer timely on the call yesterday.
On when the proposal can be cancelled - the proposal can only be canceled during the pending period before voting, and this is enforced at contract level.
On who can cancel - Only the proposal author can cancel proposals, and this is enforced at contract level.
In the event that the proposal author is malicious, and in the edge case that the proposal got majority FOR and achieved quorum, the Security Council would have to intervene to manually cancel the proposal.
Hope this helps! Let us know if there are any additional questions that we have not addressed.
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.
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.
Thanks for the proposal @Frisson.
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.
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?
in which case the proposal cancellation upgrade will be taken through a separate temperature check
in which case the proposal cancellation upgrade will be taken through a separate temperature check
there's no need for another temp check for proposal cancellation, since this was already approved, as a temp check, on March 26, 2024, here in this offchain vote: https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x1204041955b729052b9adb4da9e3fa9a03c415ca45aeefd5c41da4d9d45ea851
as well as:
Add Flexible Voting to the Arbitrum DAO Governors to enable future innovations like voting from Orbit chains, voting from DeFi contracts, and shielded voting.
which is still pending to be delivered.
Voting in Favor — allowing the proposal submitter to cancel (during the 3-day delegation period) is a strict win, accounting for e.g. human-error cases caught after proposal submission. It also gives the Security Council a cleaner means of canceling proposals if need be.
Voting in Favor — allowing the proposal submitter to cancel (during the 3-day delegation period) is a strict win, accounting for e.g. human-error cases caught after proposal submission. It also gives the Security Council a cleaner means of canceling proposals if need be.
I also support the ultimate decision to carry out this upgrade via a proxy upgrade instead of a redeploy, on the following grounds:
We fully support the approval of this proposal. The ability for the proposer to cancel their own proposal is an essential feature to prevent further issues resulting from mistakes made during on-chain submission.
Although this is not the primary objective of the proposal, it is also important to discuss other ways of enabling proposal cancellation in governance.
We fully support the approval of this proposal. The ability for the proposer to cancel their own proposal is an essential feature to prevent further issues resulting from mistakes made during on-chain submission.
Although this is not the primary objective of the proposal, it is also important to discuss other ways of enabling proposal cancellation in governance.
As @cliffton.eth pointed out, only the Security Council currently has the authority to cancel a malicious proposal. This creates a reliance on a single protective mechanism within Arbitrum.
Designing redundancies for DAO governance security is essential to maintaining its integrity. This is one of the criteria we consider when evaluating the security of a DAO in our product, Anticapture.
Paulo raised a good question, and I believe we don’t even need to answer it directly — we can simply remove this clause.
After all, we already have another tool in place: the Security Council. That’s exactly what this committee is for — to halt malicious transactions (as defined by the committee) and revert the outcomes of such votes if necessary.
pending period before voting begins.
pending period before voting begins.
We support this proposal to introduce native cancellation functionality directly within the Governor contracts and agree that cancellation should be available for the proposer during the pending period.
Would it be helpful to make proposals cancelable by an emergency moderator like the Arbitrum Foundation? This might be relevant in case a malicious proposal is initiated, in which case the emergency moderator can cancel it to prevent it from becoming votable. It’s not a guarantee against governance attacks, but it might make them one step harder.
what do you mean by this?
what happens if it’s a malicious proposal?
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.
@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.
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.
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.
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.
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 @bendi any news on the new proxy upgrade approach on this?
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.
in which case the proposal cancellation upgrade will be taken through a separate temperature check
in which case the proposal cancellation upgrade will be taken through a separate temperature check
there's no need for another temp check for proposal cancellation, since this was already approved, as a temp check, on March 26, 2024, here in this offchain vote: https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x1204041955b729052b9adb4da9e3fa9a03c415ca45aeefd5c41da4d9d45ea851
as well as:
Add Flexible Voting to the Arbitrum DAO Governors to enable future innovations like voting from Orbit chains, voting from DeFi contracts, and shielded voting.
which is still pending to be delivered.
Voting in Favor — allowing the proposal submitter to cancel (during the 3-day delegation period) is a strict win, accounting for e.g. human-error cases caught after proposal submission. It also gives the Security Council a cleaner means of canceling proposals if need be.
Voting in Favor — allowing the proposal submitter to cancel (during the 3-day delegation period) is a strict win, accounting for e.g. human-error cases caught after proposal submission. It also gives the Security Council a cleaner means of canceling proposals if need be.
I also support the ultimate decision to carry out this upgrade via a proxy upgrade instead of a redeploy, on the following grounds:
We fully support the approval of this proposal. The ability for the proposer to cancel their own proposal is an essential feature to prevent further issues resulting from mistakes made during on-chain submission.
Although this is not the primary objective of the proposal, it is also important to discuss other ways of enabling proposal cancellation in governance.
We fully support the approval of this proposal. The ability for the proposer to cancel their own proposal is an essential feature to prevent further issues resulting from mistakes made during on-chain submission.
Although this is not the primary objective of the proposal, it is also important to discuss other ways of enabling proposal cancellation in governance.
As @cliffton.eth pointed out, only the Security Council currently has the authority to cancel a malicious proposal. This creates a reliance on a single protective mechanism within Arbitrum.
Designing redundancies for DAO governance security is essential to maintaining its integrity. This is one of the criteria we consider when evaluating the security of a DAO in our product, Anticapture.
Paulo raised a good question, and I believe we don’t even need to answer it directly — we can simply remove this clause.
After all, we already have another tool in place: the Security Council. That’s exactly what this committee is for — to halt malicious transactions (as defined by the committee) and revert the outcomes of such votes if necessary.
pending period before voting begins.
pending period before voting begins.
We support this proposal to introduce native cancellation functionality directly within the Governor contracts and agree that cancellation should be available for the proposer during the pending period.
Would it be helpful to make proposals cancelable by an emergency moderator like the Arbitrum Foundation? This might be relevant in case a malicious proposal is initiated, in which case the emergency moderator can cancel it to prevent it from becoming votable. It’s not a guarantee against governance attacks, but it might make them one step harder.
what do you mean by this?
what happens if it’s a malicious proposal?
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.
@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.
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.
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.
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.
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 @bendi any news on the new proxy upgrade approach on this?
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.
@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.
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?
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?
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?
Hey, thanks for pointing this out. :sweat_smile: It appears this discussion is paused anyway, but if it comes back I'll keep this in mind.
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?
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?
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:
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?
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.
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.
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:
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.
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.
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.
Proposal Cancellation: Allows the delegate who submitted a proposal to cancel it during the delay phase, before voting begins.
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.
Proposal Cancellation: Allows the delegate who submitted a proposal to cancel it during the delay phase, before voting begins.
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.
The new Governors maintain all existing features of the current Governors, including custom relay functionality and fractional quorum calculations.
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?
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.
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: https://forum.arbitrum.foundation/t/arbitrum-governance-smart-contract-upgrade-technical-details/24642
We will present this proposal as a PR to the governance repository before beginning the governance process.
We will present this proposal as a PR to the governance repository before beginning the governance process.
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.
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
Hello all, thanks for the proposal.
I have a few questions:
Hello all, thanks for the proposal.
I have a few questions:
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.
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).
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
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.
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!!
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?
@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.
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?
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?
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?
Hey, thanks for pointing this out. :sweat_smile: It appears this discussion is paused anyway, but if it comes back I'll keep this in mind.
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?
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?
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:
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?
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.
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.
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:
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.
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.
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.
Proposal Cancellation: Allows the delegate who submitted a proposal to cancel it during the delay phase, before voting begins.
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.
Proposal Cancellation: Allows the delegate who submitted a proposal to cancel it during the delay phase, before voting begins.
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.
The new Governors maintain all existing features of the current Governors, including custom relay functionality and fractional quorum calculations.
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?
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.
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: https://forum.arbitrum.foundation/t/arbitrum-governance-smart-contract-upgrade-technical-details/24642
We will present this proposal as a PR to the governance repository before beginning the governance process.
We will present this proposal as a PR to the governance repository before beginning the governance process.
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.
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
Hello all, thanks for the proposal.
I have a few questions:
Hello all, thanks for the proposal.
I have a few questions:
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.
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).
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
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.
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!!
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?
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:
This would be a big deviation.
This will lead to a loss of history. Offchain systems attempting to index and surface governance information will need to integrate the old and new governors.
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:
a change in contract address will require a proactive awareness campaign to ensure all downstream consumers affirm they are ready to consume the changes.
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.
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.
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?
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?
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?
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.
Fully agree, this is planned
Given that, I think we should title this proposal something along the lines of: “Change to new governance contracts that allow proposal cancellation” or something along those lines.
Given that, I think we should title this proposal something along the lines of: “Change to new governance contracts that allow proposal cancellation” or something along those lines.
Good point Paulo, I updated the proposal title
@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!
updated, appreciate you king
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.
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?
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!
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 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?
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:
This would be a big deviation.
This will lead to a loss of history. Offchain systems attempting to index and surface governance information will need to integrate the old and new governors.
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:
a change in contract address will require a proactive awareness campaign to ensure all downstream consumers affirm they are ready to consume the changes.
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.
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.
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?
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?
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?
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.
Fully agree, this is planned
Given that, I think we should title this proposal something along the lines of: “Change to new governance contracts that allow proposal cancellation” or something along those lines.
Given that, I think we should title this proposal something along the lines of: “Change to new governance contracts that allow proposal cancellation” or something along those lines.
Good point Paulo, I updated the proposal title
@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!
updated, appreciate you king
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.
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?
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!
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 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?