Status: DRAFT, NOT READY TO SIGN
[!IMPORTANT] !!! DO NOT SIGN using this playbook yet, as the Security Council membership ratification proposal is not passed, and the final multisig is not set up yet.
This is the playbook for executing the Security Council Phase 0 as approved by Governance. There are two governance proposals related to this:
Both of them should be treated as the source of truth and used by the multisig signers to verify the correctness of the onchain operations.
cd superchain-ops
git pull
just install
cd eth/1-security-council-phase-0
Your Ledger needs to be connected and unlocked. The Ethereum application needs to be opened on Ledger with the message "Application is ready".
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 nonce). If you wish to use a different account, run just simulate [X]
, where X is the derivation path of the address
that you want to use.
just simulate
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:
- Validate integrity of the simulation.
- Validate correctness of the state diff.
- Validate and extract domain hash and message hash to approve.
Make sure you are on the "Overview" tab of the tenderly simulation, to validate integrity of the simulation, we need to check the following:
- "Network": Check the network is Ethereum Mainnet.
- "Timestamp": Check the simulation is performed on a block with a recent timestamp (i.e. close to when you run the script).
- "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.
Now click on the "State" tab. Verify that:
- There is only a single state override at address
0x9BA6e03D8B90dE867373Db8cF1A58d2F7F006b3A
, which overrides storage slot0x4
to new value0x1
. This override is only intended to change the Foundation multisig's quorum threshold to 1 so we can perform a tenderly simulation of the execution, - The
ProxyAdmin
contract at0x543ba4aadbab8f9025686bd03993043599c6fb04
's_owner
is changed to a new multisig, and the configuration of this new multisig correctly implements the two approved proposals: - Both of the other state changes are nonce changes only.
All of these addresses should be part of the Optimism Governance vote that approves this upgrade if this is a Normal Operation.
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:
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.
Once the validations are done, it's time to actually sign the transaction. Make sure your ledger is still unlocked and run the following:
just sign # or just sign <hdPath>
[!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:
- on your Ledger screen.
- 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.
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!
- Collect outputs from all participating signers.
- Concatenate all signatures and export it as the
SIGNATURES
environment variable, i.e.export SIGNATURES="0x[SIGNATURE1][SIGNATURE2]..."
. - 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:
Data: 0xDEADBEEF
Signer: 0xC0FFEE01
Signature: AAAA
Data: 0xDEADBEEF
Signer: 0xC0FFEE02
Signature: BBBB
Then you should run
export SIGNATURES="0xAAAABBBB"
just execute 0 # or 1 or ...