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.

Abstract

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.

Motivation

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.

Key Terms

• Upgrade Executor: A smart contract responsible for executing upgrades on Arbitrum One, Arbitrum Nova, and Ethereum mainnet; owned and administered by the DAO
• Upgrade Contract: A smart contract that contains dedicated logic for a particular upgrade; receives a call from the Upgrade Executor and subsequently calls other contracts targeted in that upgrade
• execute(): The sole function for executing an upgrade in existing Upgrade Executor implementations; relies on indirect delegate calls to upgrade contracts
• executeCall(): A new function for executing an upgrade in the modern Upgrade Executor implementation; allows for direct calls to target contracts

Specifications

• Deploy the latest UpgradeExecutor contract on each network
• Update proxy contracts on each network to reflect new UpgradeExecutor addresses:
  • Arbitrum One: 0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827
    • upgradeTo: 0x3d745b8815F9be5BF053858165f8aB1F58c77932
  • Arbitrum Nova: 0x86a02dD71363c440b21F4c0E5B2Ad01Ffe1A7482
    • upgradeTo: 0x3d745b8815F9be5BF053858165f8aB1F58c77932
  • Ethereum: 0x3ffFbAdAF827559da092217e474760E2b2c3CeDd
    • upgradeTo: 0x3d745b8815F9be5BF053858165f8aB1F58c77932

Steps to Implement

1. Deploy new UpgradeExecutor contracts on Arbitrum One, Arbitrum Nova, and Ethereum using the parameters specified above
2. Update proxy contracts on Arbitrum One, Arbitrum Nova, and Ethereum to point to the new UpgradeExecutor contracts If this proposal passes a Snapshot vote successfully (as defined above), it will be combined with other maintenance-related proposals for a unified Tally vote and on-chain payload. The portion of the Tally payload that covers the actions described in this proposal will be shared as soon as each individual proposal passes a Snapshot vote.

Timeline

The following timeline outlines proposed milestones from initial discussions to full implementation. Adjustments may be made based on community feedback and DAO governance requirements.

1. June 17th: AIP forum post outlining the proposed modifications to update the upgrade executors. Requisite code has already been written, tested, and audited as of 6 January 2023
2. July 10th: Temperature check held on Snapshot
3. July/August: Should the temperature check pass, as specified above, it will be included in the AIP draft combining several other maintenance-related proposals for a joint Tally vote.
4. On-chain Tally vote: Will commence once all other maintenance-related proposals have passed the respective temperature checks on Snapshot
5. Post-on-chain Tally vote: Should the Tally vote pass, the total waiting period will be 11 days, after which the upgrade executors will be updated