‼️Disclaimers

Important information for protocol customers, stakers, security experts, and customers of Sherlock's protocol customers

What is Sherlock?

The contributors to Sherlock don't think there's a great parallel between what Sherlock is and what may exist in other industries, etc.

Sherlock was created solely to solve a problem: smart contracts are ALWAYS at risk of getting exploited, and this is not a good user experience. If crypto and smart contracts are going to be a bigger part of the world, more needs to be done to try to mitigate the exploit risk and fallout from exploits of smart contracts that were not implemented perfectly.

Sherlock is trying to go further than anyone else in attempting to prevent smart contracts from being exploited and attempting to mitigate the monetary damages from those events.

What is Sherlock NOT?

Sherlock is not a perfect solution to smart contract hacks. Sherlock cannot EVER guarantee that a smart contract won't get hacked, and Sherlock cannot EVER guarantee that funds will be available to repay those hacks or bug bounties.

Sherlock is not "insurance" or an "insurance company", as defined by various jurisdictions across the world. In some parts of the world, the term "insurance" only applies to entities that have government funds backing them in terms of repaying claims. If an insurance company goes bankrupt in those jurisdictions, government funds can often be used to repay claimants. Sherlock DOES NOT have backing from any government funds. Because of this (and other reasons) Sherlock cannot guarantee that any funds will be available for a protocol customer if the protocol has a bug bounty payout or gets exploited. Of course, Sherlock will try hard to ensure that funds will be there, but there is no guarantee. Traditional insurance companies also make decisions about whether insurance policies should get paid out or not. Sherlock operates very differently, and any payment to a protocol customer is NOT decided on by Sherlock. It is decided by a 4-of-7 multi-sig wallet, which Sherlock does not control. And if escalated, it is decided by the UMA Optimistic Oracle, which Sherlock does not control. For these reasons, Sherlock cannot guarantee that any payout will be made, even if it's plainly obvious to bystanders that a payout should be made.

What is a Protocol Customer paying for?

On the auditing side, a protocol customer is paying for the opportunity to use the Sherlock auditing marketplace. Sherlock does not currently employ "security experts" directly and does not claim to have expertise in finding the most pernicious bugs in the world. However, many of the security-minded participants in the marketplace are very talented at finding bugs. Sherlock's system is designed to aggregate the very best security experts in the world, but there is no guarantee that those experts will be available at all times, or that they will find every bug. Sherlock believes that any security service that claims it can prevent 100% of bugs in smart contracts is lying. Sherlock does not claim to be able to do this, but the Sherlock auditing marketplace is designed to have a strong chance of finding the most bugs possible in the smart contracts that are audited through the marketplace. However, the expectation should be that bugs will be missed. On the coverage side, Sherlock has made a large effort (more than any other crypto security firm that Sherlock is aware of) to attempt to have some amount of funds available for paying out to protocol customers for smart contract bug bounties or exploits that were missed during the Sherlock audit marketplace process. When each respective protocol seeks to engage Sherlock to identify potential smart contract exploits through the marketplace of talented security-minded participants and takes that process to completion (finishes the fix reveiw, etc.), they are eligible for activating coverage (unless it's a "best efforts" audit or any other conditions are not met). Sherlock backs its process by allowing such respective protocol a potential recovery as specified in their respective coverage agreement, in the event Sherlock missed an attack vector that is identified through a bug bounty or exploit, so long as no other nonqualifying events apply. Protocol teams (and the users of those protocols) must conduct their own research, and Sherlock makes no representations about the economic viability of each given protocol or associated cryptocurrency. Only the respective protocol itself may recover using Sherlock, and any such recovery is not guaranteed, cannot be guaranteed, and is subject to various terms, conditions, and limitations. A protocol customer may pay for a certain amount of coverage (i.e. 1M USDC), but there is no guarantee that the Sherlock staking pool will have 1M USDC to fulfill the 1M USDC repayment. It's not possible to guarantee this for many reasons: the Sherlock protocol can itself be exploited and all funds drained, other protocol customers may experience exploits first and the funds can get drained, and other instances can occur. Besides this, there are many other reasons why the 4-of-7 multisig or the UMA Optimistic Oracle may decide NOT to send funds to a protocol customer that believes it has experienced an exploit. Every protocol customer has a publicly available "Coverage Agreement" which explains to the multi-sig and to the UMA Optimistic Oracle, what the intended details of coverage are. If an event occurs which those mechanisms decide does not fall into the correct category in the Coverage Agreement, then the protocol customer may not receive funds. There are also risks such as governance attacks, smart contract exploits, malicious behavior etc. that can cause the 4-of-7 multisig or UMA Optimistic Oracle to behave unexpectedly, and potentially not send funds to a protocol customer who believes they should be paid out.

What does a user of a protocol that has coverage from Sherlock get in a bug bounty or exploit event?

Aside from all the risks and potential malfunctions detailed in the paragraphs above, a user of a protocol that has coverage from Sherlock has even more risks for why they may not receive any payout in a loss situation. The Sherlock protocol is designed for management by, and payout to, protocol customers, NOT their users. Sherlock hopes, but cannot guarantee or provide expectation, that the protocol customer will decide to use the funds to repay users. Because of this, even if a payout DOES occur to a protocol customer, there can be no expectation that a user will receive benefit, because the protocol customer would have control of any funds. If the protocol customer makes a mistake (sets up the funds to be sent to the zero address, etc.) then the user of the protocol customer may receive no monetary benefit from the coverage relationship between Sherlock protocol and the protocol customer. If the protocol customer behaves maliciously (runs away with the payout from Sherlock) then the user of the protocol customer may also receive no monetary compensation in this situation. Sherlock wants to make it very clear that there is no guarantee of a payout, and that there is no guarantee that the payout actually reaches the affected users.

How might a protocol customer handle these risks?

From the user perspective, Sherlock strongly discourages a protocol customer from messaging anything to users that includes some kind of promise or guarantee. Sherlock cannot promise or guarantee that any protocol customer, or user of a protocol customer, will receive a payout from Sherlock, even if it seems obvious that the criteria for payout have been met. Many (but not all) of the reasons (smart contract hacks, etc.) are detailed in the paragraphs above. Sherlock wants to make it very clear that a protocol customer should not message to users that Sherlock coverage is anything more than an attempt to provide a possible path to a partial or full payout in the event of a covered smart contract exploit, but with no guarantees of such payout.

From a protocol customer's viewpoint, Sherlock encourages thinking about Sherlock coverage as a very uncertain, but potentially helpful payout in the event of a covered smart contract bug bounty submission or exploit and nothing more. Sherlock does not guarantee or promise the payout or availability of funds. Sherlock strives to never charge a protocol customer for an amount that is more than what is available to that customer at any given moment. For example, if a protocol is paying for 1M USDC of coverage at T=1, the protocol should also have access to 1M USDC of coverage at T=1. If the available coverage goes to 0 USDC at T=2, Sherlock strives to charge the protocol for 0 USDC worth of coverage at that time. This doesn't always happen perfectly, because Sherlock can't adjust coverage amounts every block, but Sherlock strives to at least re-align the coverage and payment aspects every two weeks, and at best much more often (whenever there is a material change).