Earlier this year, DAO voters passed a proposal which allocated funds to a proposal—submitted by @Frisson—which included funding for ScopeLift to upgrade the DAOs Governor contracts. This post is aimed at sharing the technical details of this process. We share it after a technical deep dive pursued by ScopeLift, in collaboration with Tally and other Arbitrum stakeholders.
No specific action is required by community members at this time. Instead, we share this post for transparency purposes, and welcome any feedback or questions the community might have.
Technical Summary
ScopeLift will upgrade the Arbitrum Core Governor and the Arbitrum Treasury Governor. The new Governors will have the same feature set as the current Governors with the following additional features:
- Proposal Cancellation: During the proposal delay phase, before the voting period has started, the delegate who put the proposal onchain will have the right to cancel it. This means voting on the proposal will not proceed. This feature comes in handy in many scenarios, notably in the instance that a malformed proposal is submitted in error. In such a case, the situation can be rectified without a mass effort to notify delegates to vote against it.
- Flexible Voting: We will add ScopeLift’s extension to the Governor which allows delegates to cast rolling, fractional votes. This is most useful when smart contract delegates are used to roll up the votes of many pooled token holders. Use cases this extension will enable include voting with tokens in DeFi, shielded voting, voting from Orbit chains, and more. Note that this extension has been audited and will soon be part of the OZ standard Governor.
ScopeLift will not upgrade the Governors using the proxy upgradeable contract pattern. The contracts will not be upgraded in place by pointing the proxies to a new implementation. Upgrades via proxy are less flexible, more time consuming, and more error prone. In the case of the Governors, a superior upgrade path is available, as described below.
ScopeLift will first assemble and extensively test new Governor contracts. The contracts will be audited, then deployed on Arbitrum One. ScopeLift will then coordinate with Frisson as the delegate who will submit proposals to each existing Governor which will transfer the proposer role on the Timelock contracts to the new Governors.
If the proposals pass and execute, the new Governors will become the entry point for Arbitrum Governance moving forward. The old Governors will continue to exist onchain, but will be vestigial, with no ability to actually execute proposals.
FAQ
This approach might raise a number of questions. We will attempt to anticipate and answer them below.
Question: How will delegates know to propose and vote through the new Governors after the upgrade?
Answer: Upgrading Governors by transferring Timelock ownership is a common pattern, and Tally is set up to handle it. Immediately after the upgrade executes, Tally will be updated to use the new Governor contracts, while all historical vote data sourced from the old Governors will still be visible in the client.
Question: Won’t upgrading the Governors require moving the treasury and assigning protocol permissions to the new contracts?
Answer: No. The Timelock contracts hold the Treasury ETH and protocol permissions, because the Timelock is the contract that ultimately executes Governance proposals. This allows us to upgrade the Governors (where virtually all the logic related to governance lives) without needing to move funds or reassign protocol permissions.
Question: How will other Governance proposals be impacted by the upgrade?
Answer: Any proposal that executes before the upgrade proposal will not be impacted, even if voting on the upgrade proposal has already begun. Any proposal that is either queued or being voted on when the upgrade proposal executes could be left in limbo1. For this reason, we suggest the DAO plan to avoid non-critical proposals during the upgrade voting window.
Question: Will the new contracts be proxy upgradeable?
Answer: Yes. Although using proxy upgradeability is not preferred in general, there are scenarios where it might be the right tool for the job. For example, adding a simple view method to the Governor might best be accomplished through a small proxy upgrade. Leaving this tool in the DAO’s toolbox is helpful. Thus, the new Governor contracts will be deployed as Transparent Proxies, using the same Proxy Admin as the existing contracts.
Question: Will customizations made by Arbitrum to the Governor contracts be carried forward to the new Governors?
Answer: Yes. Namely, the new Governor will have all the features provided by the extension from which it inherits. It will also have the custom onlyOwner relay functionality, and the fractional quorum which excludes specific tokens from the quorum calculation.
Question: Is upgrading the Governors risky?
Answer: If done carelessly, a botched upgrade could certainly cause problems. This is why ScopeLift will exercise great care in performing the upgrade.
In particular, ScopeLift will assemble the new Governor using the latest version the OpenZeppelin contracts upgradeable library, along with ScopeLift’s fully audited Flexible Voting extension. We will then write a large suite of tests and simulations to ensure the upgrade will be successful, and that all DAO operations will be able to proceed normally after it is completed.
Based on our previous experience with Gitcoin, PoolTogether, Radworks, and others, we expect this test suite will include hundreds of tests and thousands of lines of code.
These tests simulate the upgrade to the new Governor, from deployment, proposal, Governance vote, and future votes by the DAO. The tests run on a “forked” state from Arbitrum One to simulate the closest possible production state. They exercise all scenarios before and after the upgrade, and ensure governance will still function properly after it is completed.
We will also write scripts for deploying the new Governor and for submitting a proposal for the upgrade to the existing Governor. The scripts will be exercised by the tests.
All tests and simulations are specific to Arbitrum. They exercise the actual code that is live on the network in a simulated environment. They will ensure the upgraded Governor can manage the DAO treasury and execute its role within the protocol.
These tests will be written as fuzz tests and invariant tests, meaning they will take random arbitrary inputs rather than hardcoded parameters. We will execute millions of scenarios through these tests before proceeding.
The entire codebase will be carefully audited by the OpenZeppelin team before being deployed. Finally, the tests will also be updated to run with the actual, deployed bytecode, and with the proposal calldata, once both are live onchain.
ScopeLift has executed on this process for other DAOs. With these safeguards in place, we are confident the upgrade can be completed with minimal risk and without disruption to the DAO.
Timeline
ScopeLift has already begun preliminary work on this process, and will be accelerating on it in the weeks ahead. We are aiming to complete the work by the end of June, such that the contracts can be audited in early July. The DAO should expect a proposal for the upgrade to be submitted in mid-July at the earliest.
1 It is, in fact, possible to graft old proposal state onto the new governor so that even mid-flight proposals stay valid. This approach would increase complexity and risk, and on balance, we don’t find it worthwhile vs. the alternative, i.e. a short window during which no new proposals should be created.