conduit: upgrade 4 playbook

README.md

@@ -2,7 +2,7 @@
 
 This repo contains execution code and artifacts related to superchain deployments and other tasks.
 
-This repo is structured with each network having a high level directory which contains sub directories of any "tasks" which have occured on that network.
+This repo is structured with each network having a high level directory which contains sub directories of any "tasks" which have occurred on that network.
 
 Tasks include:
 

tasks/conduit/001-upgrade-04/.env

@@ -0,0 +1,3 @@
+ETH_RPC_URL="https://ethereum.publicnode.com"
+OWNER_SAFE=0x4a4962275DF8C60a80d3a25faEc5AA7De116A746 # Proxy admin owner for Lyra, Mode, Orderly, and PGN mainnet
+SAFE_NONCE=""

tasks/conduit/001-upgrade-04/README.md

@@ -0,0 +1,189 @@
+# Upgrade #4 Multisig Ceremony
+
+Status: DRAFT, NOT READY TO SIGN
+
+## Objective
+
+This is the playbook for executing [Upgrade #4](https://gov.optimism.io/t/upgrade-proposal-4/7534) on Conduit mainnet and testnet chains.
+This playbook is based on the OP Mainnet playbook for this upgrade which can be found [here](../../eth/004-add-superchainConfig/README.md).
+
+The proposal was:
+- [X] approved by Token House voting here: https://vote.optimism.io/proposals/110376471005925230990107796624328147348746431603727026291575353089698990280147
+- [X] not vetoed by the Citizens' house here: https://snapshot.org/#/citizenshouse.eth/proposal/0x9e85524badfcec19856bfc51cfefc78cb5f36a9b77ec0b3b304d7d7768bdf810
+
+The proposal should be treated as the source of truth and used by the multisig signers to verify the
+correctness of the onchain operations.
+
+The playbook can be used for the following chains, which is the set of chains controlled by `0x4a4962275DF8C60a80d3a25faEc5AA7De116A746`.
+- Lyra Mainnet
+- Mode Mainnet
+- Orderly Mainnet
+- Public Goods Network Mainnet
+
+## Setup
+
+If you have not run through a playbook in this repository before, please read through the root [README](../../../README.md) to get an understanding of the directory structure and how to install the necessary tools.
+
+## Approving the transaction
+
+### 1. Update repo and move to the appropriate folder for this rehearsal task:
+
+```
+cd superchain-ops
+git pull
+just install
+cd tasks/conduit/001-upgrade-04
+```
+
+### 2. Setup Ledger
+
+This playbook assumes all signers are using ledger wallets.
+
+Your Ledger needs to be connected and unlocked. The Ethereum
+application needs to be opened on Ledger with the message "Application
+is ready".
+
+### 3. Simulate and validate the transaction
+
+Make sure your ledger is still unlocked and run the following.
+
+Remember that by default just is running with the address derived from
+`/0'` (first account). If you wish to use a different account, run `just
+simulate [X]`, where X is the account index for the address
+that you want to use. Specifically, the derivation path is `m/44'/60'/{X}'/0/0`.
+
+``` shell
+just simulate {l2ChainName} # or `just simulate {l2ChainName} {X}` where X is the account index
+```
+
+You will see a "Simulation link" from the output.
+
+Paste this URL in your browser. A prompt may ask you to choose a
+project, any project will do. You can create one if necessary.
+
+Click "Simulate Transaction".
+
+We will be performing 3 validations and extract the domain hash and
+message hash to approve on your Ledger:
+
+1. Validate integrity of the simulation.
+2. Validate correctness of the state diff.
+3. Validate and extract domain hash and message hash to approve.
+
+#### 3.1. Validate integrity of the simulation.
+
+Make sure you are on the "Overview" tab of the tenderly simulation, to
+validate integrity of the simulation, we need to check the following:
+
+1. "Network": Check the network is Ethereum Mainnet.
+2. "Timestamp": Check the simulation is performed on a block with a
+   recent timestamp (i.e. close to when you run the script).
+3. "Sender": Check the address shown is your signer account. If not,
+   you will need to determine which “number” it is in the list of
+   addresses on your ledger. By default the script will assume the
+   derivation path is m/44'/60'/0'/0/0. By calling the script with
+   `just simulate 1` it will derive the address using
+   m/44'/60'/1'/0/0 instead.
+
+![](./images/tenderly-overview-network.png)
+
+#### 3.2. Validate correctness of the state diff.
+
+Now click on the "State" tab, and refer to the accompanying [validation file](./Validation.md) for instructions.
+
+#### 3.3. Extract the domain hash and the message hash to approve.
+
+Now that we have verified the transaction performs the right
+operation, we need to extract the domain hash and the message hash to
+approve.
+
+Go back to the "Overview" tab, and find the
+`GnosisSafe.checkSignatures` call. This call's `data` parameter
+contains both the domain hash and the message hash that will show up
+in your Ledger.
+
+Here is an example screenshot. Note that the hash value may be
+different:
+
+![](./images/tenderly-hash.png)
+
+It will be a concatenation of `0x1901`, the domain hash, and the
+message hash: `0x1901[domain hash][message hash]`.
+
+Note down this value. You will need to compare it with the ones
+displayed on the Ledger screen at signing.
+
+### 4. Approve the signature on your ledger
+
+Once the validations are done, it's time to actually sign the
+transaction. Make sure your ledger is still unlocked and run the
+following:
+
+```shell
+just sign {l2ChainName} # or `just sign {l2ChainName} {X}` where X is the account index
+```
+
+> [!IMPORTANT] This is the most security critical part of the
+> playbook: make sure the domain hash and message hash in the
+> following two places match:
+
+1. on your Ledger screen.
+2. in the Tenderly simulation. You should use the same Tenderly
+   simulation as the one you used to verify the state diffs, instead
+   of opening the new one printed in the console.
+
+There is no need to verify anything printed in the console. There is
+no need to open the new Tenderly simulation link either.
+
+After verification, sign the transaction. You will see the `Data`,
+`Signer` and `Signature` printed in the console. Format should be
+something like this:
+
+```
+Data:  <DATA>
+Signer: <ADDRESS>
+Signature: <SIGNATURE>
+```
+
+Double check the signer address is the right one.
+
+### 5. Send the output to Facilitator(s)
+
+Nothing has occurred onchain - these are offchain signatures which
+will be collected by Facilitators for execution. Execution can occur
+by anyone once a threshold of signatures are collected, so a
+Facilitator will do the final execution for convenience.
+
+Share the `Data`, `Signer` and `Signature` with the Facilitator, and
+congrats, you are done!
+
+## [For Facilitator ONLY] How to execute the rehearsal
+
+### [After the rehearsal] Execute the output
+
+1. Collect outputs from all participating signers.
+2. Concatenate all signatures and export it as the `SIGNATURES`
+   environment variable, i.e. `export
+   SIGNATURES="0x[SIGNATURE1][SIGNATURE2]..."`.
+3. Run `just execute 0 # or 1 or ...` to execute the transaction onchain.
+
+For example, if the quorum is 2 and you get the following outputs:
+
+``` shell
+Data:  0xDEADBEEF
+Signer: 0xC0FFEE01
+Signature: AAAA
+```
+
+``` shell
+Data:  0xDEADBEEF
+Signer: 0xC0FFEE02
+Signature: BBBB
+```
+
+Then you should run
+
+``` shell
+export SIGNATURES="0xAAAABBBB"
+just execute 0 # or 1 or ...
+```