The process of upgrading a chain built on the OP Stack presents a significant source of risk to the users and assets on that chain.

Therefore we must aim to minimize the need to trust any organization or individual providing inputs to be used in an upgrade. In particular here we are seeking to protect against the possibility of a malicious OPCM being used in an upgrade.

Fortunately, the blockchain industry has a well established pattern for minimizing trust, which is to enable anyone to verify the result of execution.

How to verify an upgrade

This document lays out the steps that must be taken, and the assumptions that must be made, in order for any person to conclude that an upgrade to an OP Stack chain will be successful.

Requirements

• The commit provided to governance has been audited for security.
• The scope of the audit includes the OPCM code and any changes to the VerifyOPCM script.

Verification process

The entire set of changes to an OP Chain which occur during an upgrade are defined by the following:

1. The calldata submitted to the OPContractsManager.
2. The address (and thus the bytecode and storage) of the OPContractsManager.

1. Verifying the calldata submitted to the OPContractsManager

The calldata submitted to the OPContractsManager’s upgrade() method contains 3 arguments.

1. ProxyAdminOwner
2. SystemConfig
3. PrestateHash

<aside> 👉

How to verify

****All of these values can be located in the superchain-registry for a given chain.

• ProxyAdminOwner and SystemConfig addresses are available in the toml file for each chain. (ie. superchain/configs/mainnet/op.toml)
• Prestate hashes are available at validation/standard/standard-prestates.toml (prestate hashes in this file are suitable for use with any chain in the superchain registry).

Links for verifying these values are also available in the Validation.md document of a runbook (example).

</aside>

Note that the potential consequences for an error in the calldata are relatively low compared to an error the logic of the OPCM.

• If either of the first two values are incorrect, the upgrade will simply fail because the ProxyAdminOwner must be authorized to upgrade the OPChain defined by the SystemConfig.