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