Sherlock V2
Comment on page

Exploit Flow

If an exploit is thought to have occurred at a covered protocol, the protocol can submit a claim to Sherlock.
Some of the Sherlock Watsons can be expected to work alongside the core devs to initially mitigate the exploit if it is still live. Once the exploit has ended, the Watsons will work to understand the exploit's cause and magnitude. Through this process, a protocol will have a good sense of whether the exploit experienced is covered by Sherlock, and thus a claim should be submitted. The Watsons will help with the general claim submission process as well as choosing the correct timestamp and amount that should be submitted.
Details around Sherlock's full claim process can be found here. The first stage of the claims review is the decision made by the Sherlock Protocol Claims Committee (SPCC). If the protocol disagrees with the SPCC decision, the protocol can post a bond of ~$22k and escalate the claim to UMA's Optimistic Oracle. This allows the protocol to have access to an unbiased, third-party judgment on whether the claim should be paid out or not.
If a claim should be paid out, the payout will go to the address specified by the protocol (protocol agent) when the claim was initiated.
Note: The address that submits a claim will be linked to the claim throughout the claim's lifecycle. This is noteworthy because a protocol can update their "agent" address, but any claim that is started will have to finish with the old address. Basically, this means a protocol team shouldn't start a claim with an address that they might lose access to before the claim is resolved (a matter of weeks at most).

After an Exploit

When the dust has settled from an exploit and the claim has been resolved, the initial coverage amount (i.e. $2M) may be partially or entirely exhausted.
Note: Coverage amounts through Sherlock do not automatically regenerate after a payout.
In order to refill or "top up" the coverage amount, a new agreement must be entered into with Sherlock. This allows Sherlock to re-assess the risk of any protocol after they've suffered a large exploit.