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.

   b. 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):

   

   Example of filtering the events with the logs (the topic used here an example).

2. Determine if the usage of pause was intended:

   Do this by checking in #eng-oncall for recent messages notifying of an upgrade.

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

• Possible Pause Vectors (help during investigation).

3. Actions

Base on the investigation follow one of these paths:

1. If the pause was unexpected:
   1. declare an incident on Grafana.
2. If it is determined that the L1 safes are compromised (SC or FOS/FUS) proceed to a whitehat rescue of the bridge assets.