1. Alerts content

FunctionName: which events was emitted.

Priority: Should not be used for now (so please don’t read it and don’t be influenced by the values there are incorrects for now).

RuleName: Is the name of the yaml rule that match here (this can useful for more context).

Topics: Is the keccak256 topics that is useful in the case the incident responder need to use it to make some search with etherscan for example (e.g here).

The following fields (TxHash , BlockNumber) are not in the Ops-genie alert you need to look into Grafana to have them (there are required for the triaging correctly)

<aside> ⚠️ Make sure to check the network you are etherscan (L1) but optimism.etherscan for (L2).

</aside>

2. Investigation

1. Determine if the alert is valid (rather than a config error in monitoring/alerting).

   1. Use the TxHash field and checks the logs of the transaction (on etherscan).

   

   If the number of the logs is reasonable (under 20) go directly to the logs tabs.

   1. Use the Address field checking the events emitted by the contract in etherscan. If there are a high volume of events, use the topic signature from the alert to filter:

   

2. Determine if the call to ****setRespectedGameType ****was intended:

   Do this by checking in #eng-oncall & #proofs for recent messages notifying of a blacklisted on a Fault Dispute Game.

   If there are no such messages, use @channel to ask about the upgrade and proceed immediately to the actions.

• Possible setRespectedGameType() vectors (help during investigation)

3. Actions

Base on the investigation follow one of these paths:

1. If the setRespectedGameType action was unexpected and coming from the SC:
   1. Reach Alisha (Lead of the Security Council) on Signal immediately (ask if this is legitimate action).
      1. Secondly, share the TxHash of the action to Alisha or any other members of the SC.
2. If it is determined that the L1 safe is compromised (SC/FND) proceed to a whitehat rescue of the bridge assets.