Note: this proposal will be subject to an individual Snapshot vote; if it reaches a quorum of 3% of votable $ARB, it may be combined with several other maintenance-related proposals for a joint Tally vote.
This proposal seeks approval to replace the Upgrade Executor contracts on Arbitrum One, Arbitrum Nova, and Ethereum mainnet with upgraded versions. The modernized version introduces an additional function that enables the Upgrade Executor to execute an upgrade by directly calling the target contract, rather than indirectly delegate calling an upgrade contract. As a result, future governance actions can be executed more simply and with fewer contract deployments.
The Upgrade Executors controlled by the DAO are responsible for carrying out critical upgrades on Arbitrum One, Arbitrum Nova, and Ethereum such as protocol contract upgrades, system parameter changes, and more. Currently, the traditional Upgrade Executor contracts in place only support one function for executing an upgrade: execute(). When called by the owner of the Upgrade Executor, the execute() function delegate calls an upgrade contract, which facilitates subsequent calls to target contracts and ultimately executes the upgrade. This indirect method of calling and execution can complicate upgrades and require additional development and deployments.
The modern version of the Upgrade Executor introduces a new function, executeCall(), which allows the Upgrade Executor to directly call target contracts and execute upgrades, removing the need for delegate calls to upgrade contracts. While the existing execute() call is still supported, the new executeCall() function enables the Upgrade Executor to implement upgrades in a lighter weight fashion. In the future, upgrades that use this method may not require dedicated action contracts, simplifying the process and saving development energy.
The following timeline outlines proposed milestones from initial discussions to full implementation. Adjustments may be made based on community feedback and DAO governance requirements.
Note: this proposal will be subject to an individual Snapshot vote; if it reaches a quorum of 3% of votable $ARB, it may be combined with several other maintenance-related proposals for a joint Tally vote.
This proposal seeks approval to replace the Upgrade Executor contracts on Arbitrum One, Arbitrum Nova, and Ethereum mainnet with upgraded versions. The modernized version introduces an additional function that enables the Upgrade Executor to execute an upgrade by directly calling the target contract, rather than indirectly delegate calling an upgrade contract. As a result, future governance actions can be executed more simply and with fewer contract deployments.
The Upgrade Executors controlled by the DAO are responsible for carrying out critical upgrades on Arbitrum One, Arbitrum Nova, and Ethereum such as protocol contract upgrades, system parameter changes, and more. Currently, the traditional Upgrade Executor contracts in place only support one function for executing an upgrade: execute(). When called by the owner of the Upgrade Executor, the execute() function delegate calls an upgrade contract, which facilitates subsequent calls to target contracts and ultimately executes the upgrade. This indirect method of calling and execution can complicate upgrades and require additional development and deployments.
The modern version of the Upgrade Executor introduces a new function, executeCall(), which allows the Upgrade Executor to directly call target contracts and execute upgrades, removing the need for delegate calls to upgrade contracts. While the existing execute() call is still supported, the new executeCall() function enables the Upgrade Executor to implement upgrades in a lighter weight fashion. In the future, upgrades that use this method may not require dedicated action contracts, simplifying the process and saving development energy.
The following timeline outlines proposed milestones from initial discussions to full implementation. Adjustments may be made based on community feedback and DAO governance requirements.
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/19
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/7
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/20?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/19
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/7
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/20?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/18?u=danielm
The Event Horizon Community voted on this proposal (ehARB-119): EventHorizon.vote/vote/arbitrum/ehARB-119
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/17?u=winverse
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/20
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/15?u=griff
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/14?u=maxlomu
https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0xc08147e229fa642ee7da2e5180f225122b8c517024902f21cdcd02b376179b8d
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/12
https://forum.arbitrum.foundation/t/gfx-labs-delegate-communication-thread/13794
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/8?u=hawheik
I haven't had the time to review this properly.
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/18?u=danielm
The Event Horizon Community voted on this proposal (ehARB-119): EventHorizon.vote/vote/arbitrum/ehARB-119
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/17?u=winverse
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/20
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/15?u=griff
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/14?u=maxlomu
https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0xc08147e229fa642ee7da2e5180f225122b8c517024902f21cdcd02b376179b8d
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/12
https://forum.arbitrum.foundation/t/gfx-labs-delegate-communication-thread/13794
https://forum.arbitrum.foundation/t/constitutional-aip-update-the-upgrade-executors/29463/8?u=hawheik
I haven't had the time to review this properly.
In-flight proposals should not be affected by this upgrade because the changes will not be made until this proposal passes a Tally vote and the proposal payload is executed on-chain. Proposals that precede this change to the Upgrade Executors proposal should continue to use the existing Upgrade Executors with the current functionality.
A new third-party audit of the new UpgradeExecutor contract has been completed. Trail of Bits reviewed the change set that introduces executeCall and in their report, they found no security-relevant issues. This complements the comprehensive January 2023 audit of Governance & Token Bridge, which also covered the UpgradeExecutor.
In-flight proposals should not be affected by this upgrade because the changes will not be made until this proposal passes a Tally vote and the proposal payload is executed on-chain. Proposals that precede this change to the Upgrade Executors proposal should continue to use the existing Upgrade Executors with the current functionality.
A new third-party audit of the new UpgradeExecutor contract has been completed. Trail of Bits reviewed the change set that introduces executeCall and in their report, they found no security-relevant issues. This complements the comprehensive January 2023 audit of Governance & Token Bridge, which also covered the UpgradeExecutor.
A new third-party audit of the new UpgradeExecutor contract has been completed. Trail of Bits reviewed the change set that introduces executeCall and in their report, they found no security-relevant issues.
Thanks for raising this, Hawkheik. Since your comment, we commissioned an audit report by Trail of Bits on the Upgrade Executor repo. Trail of Bits reviewed the implementation of executeCall, assessed it against the proposal’s intent, and checked for unintended side effects. Trail of Bits found no security-relevant issues.
As described in the report, executeCall enables the executor to make a direct external call as opposed to the prior path that used delegatecalls via the execute function. The change is about how an authorized upgrade is executed, not who authorizes it. The Upgrade Executor continues to execute only changes as instructed by the DAO (via the L1 Timelock) or by the Arbitrum security council; the audit also describes this governance scope explicitly. The addition of executeCall does not alter those controls
A new third-party audit of the new UpgradeExecutor contract has been completed. Trail of Bits reviewed the change set that introduces executeCall and in their report, they found no security-relevant issues.
Thanks for raising this, Hawkheik. Since your comment, we commissioned an audit report by Trail of Bits on the Upgrade Executor repo. Trail of Bits reviewed the implementation of executeCall, assessed it against the proposal’s intent, and checked for unintended side effects. Trail of Bits found no security-relevant issues.
As described in the report, executeCall enables the executor to make a direct external call as opposed to the prior path that used delegatecalls via the execute function. The change is about how an authorized upgrade is executed, not who authorizes it. The Upgrade Executor continues to execute only changes as instructed by the DAO (via the L1 Timelock) or by the Arbitrum security council; the audit also describes this governance scope explicitly. The addition of executeCall does not alter those controls
After further consideration, we've realized that our original requirement — that a proposal must receive at least 95% FOR votes on Snapshot and reach an informal quorum of 100M votes in order to be batched with other maintenance-related proposals for a joint Tally vote — is unnecessarily stringent.
To streamline the process while still ensuring sufficient support, we're updating the requirement - that if a proposal reaches a quorum of at least 3% of votable $ARB on Snapshot, it may be eligible to be combined with other maintenance-related proposals in a joint Tally vote.
After further consideration, we've realized that our original requirement — that a proposal must receive at least 95% FOR votes on Snapshot and reach an informal quorum of 100M votes in order to be batched with other maintenance-related proposals for a joint Tally vote — is unnecessarily stringent.
To streamline the process while still ensuring sufficient support, we're updating the requirement - that if a proposal reaches a quorum of at least 3% of votable $ARB on Snapshot, it may be eligible to be combined with other maintenance-related proposals in a joint Tally vote.
voted Abstain on this past offchain vote because I haven't had the time to review this properly.
voted Abstain on this past offchain vote because I haven't had the time to review this properly.
I have voted in favour. It makes the DAO’s upgrade process simpler and smoother, reducing the steps and effort needed for future changes while keeping everything under the DAO’s control, which lowers the chance of mistakes, saves time for developers, and strengthens how the system is managed without adding new costs or risks.
I have voted in favour. It makes the DAO’s upgrade process simpler and smoother, reducing the steps and effort needed for future changes while keeping everything under the DAO’s control, which lowers the chance of mistakes, saves time for developers, and strengthens how the system is managed without adding new costs or risks.
This might be interesting to explore! @Arbitrum
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
We are voting FOR this proposal in the Snapshot voting.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
We are voting FOR this proposal in the Snapshot voting.
We support the effort to make Arbitrum DAO upgrades simpler and safer by introducing the new executeCall() function in the Upgrade Executor contracts. Reducing the need for extra contract deployments, as explained in the proposal and by other delegates like L2BEAT and @Tane, will save both time and development resources for future governance actions.
At the same time, we share the concerns raised by @Hawheik, @cp0x, about the audit status of the upgraded contract, especially around executeCall(). Security reviews for admin-level contracts are an important requirement for us. We would like to request @Arbitrum to make sure that a recent and complete audit is made public before the proposal moves to the final Tally vote.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
The integration of Upgrade Executors, offers a light weight solution to manage call functions within Arbitrum, without the need of middleman contracts. Whilst we hope contracts undergo security considerations, we do believe this development will improve the developer community. Otherwise, we are in support for this proposal.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
The integration of Upgrade Executors, offers a light weight solution to manage call functions within Arbitrum, without the need of middleman contracts. Whilst we hope contracts undergo security considerations, we do believe this development will improve the developer community. Otherwise, we are in support for this proposal.
We also would like to commend the Governance team @Sinkas, @krst, and @Manugotsuka @ L2Beat to breakdown this proposition in succinct terms.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We voted FOR and we've posted full rationale here.
As far as I can tell, this upgrade makes governance easier and cheaper by letting call contracts directly without extra steps. It doesn’t change who controls things or add risk. Same security model, same ownership, just less overhead. I hope I’m getting it right.
As far as I can tell, this upgrade makes governance easier and cheaper by letting call contracts directly without extra steps. It doesn’t change who controls things or add risk. Same security model, same ownership, just less overhead. I hope I’m getting it right.
Proposals like this are purely technical housekeeping. We don’t need to waste delegate time debating them every cycle. This kind of proposal should just be optimistically approved so the DAO can move faster and focus on bigger decisions.
gm, voted FOR as the change seems to simplify the process without changing the trust assumptions.
Thanks L2Beat for more detailed analysis.
I voted FOR this proposal. It makes the process simpler and reduces the risk surface area. I would like to point out, however, that many questions were left unanswered, and it would be a good practice to address them before the on-chain vote.
We support this proposal as it streamlines the DAO’s upgrade process by introducing executeCall(), allowing for direct contract upgrades without deploying separate upgrade contracts. This improves efficiency, reduces complexity, and maintains backward compatibility. With the code already audited and no added governance risk, we see this as a low-risk, high-value improvement to DAO operations.
can we get some independent verification that the payload on the onchain proposal actually does what it says it does? @offchainlabs @Frisson @krst @GFXlabs and so on?
ideally, before more people vote on it without verifying it.
DAOplomats is voting FOR this proposal on Snapshot.
This update to support direct contract calls is a value add and a much welcome upgrade.
Seeing that this reduces complications and thus streamlines the upgrade process, we are comfortable supporting during this temp check.
Voting "Against"
I agree with @cp0x / @Hawheik ... A 2.5 year old audit is odd and if the actual code in question is not in it I'm not sure the audit actually covers what is required? When it comes to these technical audits I default to the fact I'm not a technical user so I can only add so much... however the lack of response by the proposer at any point in the last 2 weeks is concerning. If I'm misunderstanding fair enough, but without a direct response addressing it I have to be conservative here.
Voting "Against"
I agree with @cp0x / @Hawheik ... A 2.5 year old audit is odd and if the actual code in question is not in it I'm not sure the audit actually covers what is required? When it comes to these technical audits I default to the fact I'm not a technical user so I can only add so much... however the lack of response by the proposer at any point in the last 2 weeks is concerning. If I'm misunderstanding fair enough, but without a direct response addressing it I have to be conservative here.
I get the reality that these are housekeeping votes essentially. Which on the whole is fine... but if the feedback isn't going to be addressed then why even have the vote?
I voted AGAINST this proposal
https://forum.arbitrum.foundation/t/cp0x-delegate-communication-thread/22217/200?u=cp0x
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Snapshot Vote.
Rationale
We have no reason to oppose this update. However, we would appreciate clarification regarding the audit status of the referenced contracts — as raised by other delegates — before the on-chain vote takes place.
I’m voting yes because this make the upgrade process more easy and less complicated. It help save time and not need many extra contracts like before. I think it good for Arbitrum in long run.
The actual solidity-code in question, the updated UpgradeExecutor.sol, does not appear to have been covered by the audit. The phrasing of the above sentence led me to believe it had, so I think it's important to point this out to other delegates.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
After reviewing the proposal with the assistance of L2BEAT’s research team, we’re supportive of it.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
After reviewing the proposal with the assistance of L2BEAT’s research team, we’re supportive of it.
The only real novelty is the new executeCall() function, which allows the DAO to interact directly with a target contract instead of first delegating to a throw-away “action” contract. Cutting that hop should simplify future governance actions and reduce the need for contract deployments.
Nothing else in the permission model changes—ownership remains with the DAO, the old execute() path continues to work, and we’ve seen no alteration to the underlying trust assumptions.
We also posted an X thread that simply explains the proposal for anyone interested in learning more about it.
We support this proposal, as the introduction of executeCall() will help streamline upgrades and reduce unnecessary overhead for future governance actions. That said, we’d like to raise a few questions. Since this introduces a more direct method of executing upgrades, are there any guardrails or best practices planned to ensure safe usage and prevent misuse or errors? The proposal notes that the code has been audited, it would be helpful to better understand the scope of that audit and whether it covered risks specific to executeCall(). We also encourage the team to provide documentation and usage examples so DAO participants can confidently adopt the new functionality.
I have voted in favour. It makes the DAO’s upgrade process simpler and smoother, reducing the steps and effort needed for future changes while keeping everything under the DAO’s control, which lowers the chance of mistakes, saves time for developers, and strengthens how the system is managed without adding new costs or risks.
I have voted in favour. It makes the DAO’s upgrade process simpler and smoother, reducing the steps and effort needed for future changes while keeping everything under the DAO’s control, which lowers the chance of mistakes, saves time for developers, and strengthens how the system is managed without adding new costs or risks.
This might be interesting to explore! @Arbitrum
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
We are voting FOR this proposal in the Snapshot voting.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
We are voting FOR this proposal in the Snapshot voting.
We support the effort to make Arbitrum DAO upgrades simpler and safer by introducing the new executeCall() function in the Upgrade Executor contracts. Reducing the need for extra contract deployments, as explained in the proposal and by other delegates like L2BEAT and @Tane, will save both time and development resources for future governance actions.
At the same time, we share the concerns raised by @Hawheik, @cp0x, about the audit status of the upgraded contract, especially around executeCall(). Security reviews for admin-level contracts are an important requirement for us. We would like to request @Arbitrum to make sure that a recent and complete audit is made public before the proposal moves to the final Tally vote.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
The integration of Upgrade Executors, offers a light weight solution to manage call functions within Arbitrum, without the need of middleman contracts. Whilst we hope contracts undergo security considerations, we do believe this development will improve the developer community. Otherwise, we are in support for this proposal.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
The integration of Upgrade Executors, offers a light weight solution to manage call functions within Arbitrum, without the need of middleman contracts. Whilst we hope contracts undergo security considerations, we do believe this development will improve the developer community. Otherwise, we are in support for this proposal.
We also would like to commend the Governance team @Sinkas, @krst, and @Manugotsuka @ L2Beat to breakdown this proposition in succinct terms.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We voted FOR and we've posted full rationale here.
As far as I can tell, this upgrade makes governance easier and cheaper by letting call contracts directly without extra steps. It doesn’t change who controls things or add risk. Same security model, same ownership, just less overhead. I hope I’m getting it right.
As far as I can tell, this upgrade makes governance easier and cheaper by letting call contracts directly without extra steps. It doesn’t change who controls things or add risk. Same security model, same ownership, just less overhead. I hope I’m getting it right.
Proposals like this are purely technical housekeeping. We don’t need to waste delegate time debating them every cycle. This kind of proposal should just be optimistically approved so the DAO can move faster and focus on bigger decisions.
gm, voted FOR as the change seems to simplify the process without changing the trust assumptions.
Thanks L2Beat for more detailed analysis.
I voted FOR this proposal. It makes the process simpler and reduces the risk surface area. I would like to point out, however, that many questions were left unanswered, and it would be a good practice to address them before the on-chain vote.
We support this proposal as it streamlines the DAO’s upgrade process by introducing executeCall(), allowing for direct contract upgrades without deploying separate upgrade contracts. This improves efficiency, reduces complexity, and maintains backward compatibility. With the code already audited and no added governance risk, we see this as a low-risk, high-value improvement to DAO operations.
can we get some independent verification that the payload on the onchain proposal actually does what it says it does? @offchainlabs @Frisson @krst @GFXlabs and so on?
ideally, before more people vote on it without verifying it.
DAOplomats is voting FOR this proposal on Snapshot.
This update to support direct contract calls is a value add and a much welcome upgrade.
Seeing that this reduces complications and thus streamlines the upgrade process, we are comfortable supporting during this temp check.
Voting "Against"
I agree with @cp0x / @Hawheik ... A 2.5 year old audit is odd and if the actual code in question is not in it I'm not sure the audit actually covers what is required? When it comes to these technical audits I default to the fact I'm not a technical user so I can only add so much... however the lack of response by the proposer at any point in the last 2 weeks is concerning. If I'm misunderstanding fair enough, but without a direct response addressing it I have to be conservative here.
Voting "Against"
I agree with @cp0x / @Hawheik ... A 2.5 year old audit is odd and if the actual code in question is not in it I'm not sure the audit actually covers what is required? When it comes to these technical audits I default to the fact I'm not a technical user so I can only add so much... however the lack of response by the proposer at any point in the last 2 weeks is concerning. If I'm misunderstanding fair enough, but without a direct response addressing it I have to be conservative here.
I get the reality that these are housekeeping votes essentially. Which on the whole is fine... but if the feedback isn't going to be addressed then why even have the vote?
I voted AGAINST this proposal
https://forum.arbitrum.foundation/t/cp0x-delegate-communication-thread/22217/200?u=cp0x
After consideration, the @SEEDgov delegation decided to vote FOR on this proposal at the Snapshot Vote.
Rationale
We have no reason to oppose this update. However, we would appreciate clarification regarding the audit status of the referenced contracts — as raised by other delegates — before the on-chain vote takes place.
I’m voting yes because this make the upgrade process more easy and less complicated. It help save time and not need many extra contracts like before. I think it good for Arbitrum in long run.
The actual solidity-code in question, the updated UpgradeExecutor.sol, does not appear to have been covered by the audit. The phrasing of the above sentence led me to believe it had, so I think it's important to point this out to other delegates.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
After reviewing the proposal with the assistance of L2BEAT’s research team, we’re supportive of it.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
After reviewing the proposal with the assistance of L2BEAT’s research team, we’re supportive of it.
The only real novelty is the new executeCall() function, which allows the DAO to interact directly with a target contract instead of first delegating to a throw-away “action” contract. Cutting that hop should simplify future governance actions and reduce the need for contract deployments.
Nothing else in the permission model changes—ownership remains with the DAO, the old execute() path continues to work, and we’ve seen no alteration to the underlying trust assumptions.
We also posted an X thread that simply explains the proposal for anyone interested in learning more about it.
We support this proposal, as the introduction of executeCall() will help streamline upgrades and reduce unnecessary overhead for future governance actions. That said, we’d like to raise a few questions. Since this introduces a more direct method of executing upgrades, are there any guardrails or best practices planned to ensure safe usage and prevent misuse or errors? The proposal notes that the code has been audited, it would be helpful to better understand the scope of that audit and whether it covered risks specific to executeCall(). We also encourage the team to provide documentation and usage examples so DAO participants can confidently adopt the new functionality.
The actual solidity-code in question, the updated UpgradeExecutor.sol, does not appear to have been covered by the audit. The phrasing of the above sentence led me to believe it had, so I think it's important to point this out to other delegates.
None of the commits mentioned in the audit report contain the new executeCall(...) function, the audit only seems to cover the old UpgradeExecutor.sol and framework-code around it.
The direct links for readers to confirm this themselves:
https://github.com/OffchainLabs/governance/blob/cf6762d45678847cd901544f90989d852dfdd6ea/src/UpgradeExecutor.sol
https://github.com/OffchainLabs/governance/blob/6bd1a880df96b36508b55a10c8f29327711f3750/src/UpgradeExecutor.sol
https://github.com/OffchainLabs/governance/blob/e4562df1fd165042f6fc5400063dd4a23d10e855/src/UpgradeExecutor.sol
Perhaps there is a different audit that covers the updated UpgradeExecutor.sol?
In the end the suggested upgrade does not seem to introduce new 'powers' to the executor-role beyond what it already imbued with. If anything it provides a cleaner path to achieving what execute(...), without the potential side-effects that a bad execute(...) call might cause.
Would I personally feel comfortable with this change? Yes. Would I feel comfortable suggesting the DAO embrace the change without having at least seen it audited? No. As the proposal stands right now I would feel forced to vote "Against".
We vote in favor of this proposal.
This streamlines Arbitrum’s upgrade execution by introducing a direct-call method (executeCall()), thus reducing the complexity and potential risks associated with delegate calls and single-use upgrade contracts. Maintaining existing permission structures ensures continuity of trust assumptions while enhancing operational efficiency. Additionally, the upgrade mitigates technical overhead, benefiting both developers and the broader community through clearer and safer upgrade processes.
We vote in favor of this proposal.
This streamlines Arbitrum’s upgrade execution by introducing a direct-call method (executeCall()), thus reducing the complexity and potential risks associated with delegate calls and single-use upgrade contracts. Maintaining existing permission structures ensures continuity of trust assumptions while enhancing operational efficiency. Additionally, the upgrade mitigates technical overhead, benefiting both developers and the broader community through clearer and safer upgrade processes.
That said, as many other delegates pointed out, the audit status should've been disclosed prior to the vote, considering the importance of transparency for the DAO to effectively manage contracts in a secure manner.
Please advise on this proposal:
Why is a solution that was audited 2.5 years ago being applied only now?
Is there a need for a new audit due to Ethereum updates during this time?
Thank you for submitting this maintenance proposal and continuing to improve the infrastructure that underpins DAO-led upgrades.
We support the motivation behind simplifying the upgrade execution process and introducing a more lightweight alternative, especially for operational efficiency and governance overhead reduction.
Thank you for submitting this maintenance proposal and continuing to improve the infrastructure that underpins DAO-led upgrades.
We support the motivation behind simplifying the upgrade execution process and introducing a more lightweight alternative, especially for operational efficiency and governance overhead reduction.
We would appreciate a clarification regarding how this proposed change might affect the custom gateway upgrade process, such as the one currently up for vote for Sky, are they influenced by this upgrade?
Thank you for the proposal.
We have no feedback on the proposed upgrade at this time and will support it.
However, we would like to confirm whether an audit of the new UpgradeExecutor contract rollout is being conducted or is planned, considering that the linked audit was conducted in January 2023, which is over 2 years old now.
The actual solidity-code in question, the updated UpgradeExecutor.sol, does not appear to have been covered by the audit. The phrasing of the above sentence led me to believe it had, so I think it's important to point this out to other delegates.
None of the commits mentioned in the audit report contain the new executeCall(...) function, the audit only seems to cover the old UpgradeExecutor.sol and framework-code around it.
The direct links for readers to confirm this themselves:
https://github.com/OffchainLabs/governance/blob/cf6762d45678847cd901544f90989d852dfdd6ea/src/UpgradeExecutor.sol
https://github.com/OffchainLabs/governance/blob/6bd1a880df96b36508b55a10c8f29327711f3750/src/UpgradeExecutor.sol
https://github.com/OffchainLabs/governance/blob/e4562df1fd165042f6fc5400063dd4a23d10e855/src/UpgradeExecutor.sol
Perhaps there is a different audit that covers the updated UpgradeExecutor.sol?
In the end the suggested upgrade does not seem to introduce new 'powers' to the executor-role beyond what it already imbued with. If anything it provides a cleaner path to achieving what execute(...), without the potential side-effects that a bad execute(...) call might cause.
Would I personally feel comfortable with this change? Yes. Would I feel comfortable suggesting the DAO embrace the change without having at least seen it audited? No. As the proposal stands right now I would feel forced to vote "Against".
We vote in favor of this proposal.
This streamlines Arbitrum’s upgrade execution by introducing a direct-call method (executeCall()), thus reducing the complexity and potential risks associated with delegate calls and single-use upgrade contracts. Maintaining existing permission structures ensures continuity of trust assumptions while enhancing operational efficiency. Additionally, the upgrade mitigates technical overhead, benefiting both developers and the broader community through clearer and safer upgrade processes.
We vote in favor of this proposal.
This streamlines Arbitrum’s upgrade execution by introducing a direct-call method (executeCall()), thus reducing the complexity and potential risks associated with delegate calls and single-use upgrade contracts. Maintaining existing permission structures ensures continuity of trust assumptions while enhancing operational efficiency. Additionally, the upgrade mitigates technical overhead, benefiting both developers and the broader community through clearer and safer upgrade processes.
That said, as many other delegates pointed out, the audit status should've been disclosed prior to the vote, considering the importance of transparency for the DAO to effectively manage contracts in a secure manner.
Please advise on this proposal:
Why is a solution that was audited 2.5 years ago being applied only now?
Is there a need for a new audit due to Ethereum updates during this time?
Thank you for submitting this maintenance proposal and continuing to improve the infrastructure that underpins DAO-led upgrades.
We support the motivation behind simplifying the upgrade execution process and introducing a more lightweight alternative, especially for operational efficiency and governance overhead reduction.
Thank you for submitting this maintenance proposal and continuing to improve the infrastructure that underpins DAO-led upgrades.
We support the motivation behind simplifying the upgrade execution process and introducing a more lightweight alternative, especially for operational efficiency and governance overhead reduction.
We would appreciate a clarification regarding how this proposed change might affect the custom gateway upgrade process, such as the one currently up for vote for Sky, are they influenced by this upgrade?
Thank you for the proposal.
We have no feedback on the proposed upgrade at this time and will support it.
However, we would like to confirm whether an audit of the new UpgradeExecutor contract rollout is being conducted or is planned, considering that the linked audit was conducted in January 2023, which is over 2 years old now.