Sherlock Seed Round

What is Sherlock?

Sherlock is a new type of security solution for protocol teams.

Sherlock provides teams with all the tools they need to securely launch decentralized apps:

  • Audits from leading security experts
  • Bug bounty paid for by Sherlock
  • Smart contract coverage against exploits

With these tools, protocol teams are set up for success and can get back to building. Even further, the users of these protocols can sleep easier knowing there is recourse even if a bug slips through the protocol’s strict security practices.

The Mission

The Sherlock team thinks Web3/crypto/DeFi will be one of the greatest positive influences on the world in the 21st century. DeFi has the ability to give anyone with an internet connection access to cutting edge financial tools and currencies. NFTs and Web3 gaming democratize access to wealth for artists and gamers. And soon, Web3 social media will ensure everyone has a voice.

There are 3 big problems that prevent this vision from becoming reality:

  • Scalability (gas prices too high, transactions too slow)
  • User Experience (wallets, ramps, and custody are hard)
  • Security (exploits and insecure code)

The Sherlock team thinks the “Security” category has garnered the least attention and little has changed in the last 5 years. It is time for a new approach. End users have no recourse when current security practices fail and this will hurt crypto’s ability to scale.

Sherlock’s mission is to make crypto safe for everyone.

This means starting with users. Sherlock is designed with end users in mind. The Sherlock team believes that users shouldn’t have to deal with security considerations (like smart contract coverage) at all.

This is why Sherlock takes a protocol-to-protocol approach. The best way to protect users is to make it as easy as possible for protocol teams to use industry-leading security practices and provide recourse for exploits.

The Problem

Exploits in crypto are causing billions of dollars per year in damages.

  • Users don’t know how to differentiate well-secured protocols from poorly-secured ones. Worse, even well-secured protocols get hacked sometimes.
  • Protocol teams don’t know where the bar for security is. Is one audit enough? What about an audit plus peer reviews? Do they need a bug bounty? Is formal verification the same as an audit? What if they want to make small changes to deployed code?
  • Audit firms don’t feel the same pain of exploits as protocol teams: there is no penalty or recourse if an audit firm’s client gets hacked.

Sherlock’s Approach

  • Sherlock DOES provide recourse for exploits, meaning Sherlock and actors within the Sherlock protocol are highly incentivized to keep covered protocols safe.
  • Sherlock sets the security bar for protocols, and protocol teams can respect the bar because Sherlock’s interests are aligned with theirs. Teams can decide whether to clear the bar and work with Sherlock, or not.
  • Users come to see Sherlock as the ultimate stamp of approval. They feel more comfortable using Sherlock-covered protocols because they know a high bar has been cleared for security, and there is a high probability of recourse in the event of an exploit.

How Does It Work?

There are 3 parties in the Sherlock ecosystem:

  • Protocols who want coverage
  • Security experts who review protocol code
  • Stakers who provide capital for recourse

Sherlock helps protocols who want coverage by connecting them with external audit firms as well as through Sherlock’s own security review process, conducted by the Watsons (Sherlock’s whitelisted security reviewers). The Watsons do a fundamental security assessment of each prospective protocol and provide input to the pricing of coverage.

This process has a dual purpose:

  • Helping the protocol to secure its codebase
  • Helping Sherlock understand and price the risk of the codebase

If an exploit occurs on a covered protocol’s codebase, capital provided by stakers is used to repay the bug bounty or exploit (up to the agreed-upon coverage amount).

In the meantime, stakers receive APY from 3 sources:

  • Sherlock-approved strategies (e.g. depositing USDC into Aave)
  • Premiums paid by protocols (based on Sherlock’s security assessment)
  • SHER token incentives

Detailed info on the design and mechanisms can be found in the docs.

How Does a Protocol Get Repaid for an Exploit?

When the worst case happens, how does a protocol trust that Sherlock will repay the lost funds?

Good news: it doesn’t have to.

Sherlock’s V2 claims process is completely trustless.

A protocol can submit a claim at any time, and if either of two “committees” decide the exploit falls within the terms of the coverage agreement (example agreement here), the funds are automatically transferred to the protocol’s chosen address. No trust in Sherlock is required.

The two committees are:

  • The SPCC -- this committee is made up of well-known security experts in the space. The strengths of this committee are its speed and expertise, but its potential weakness is that many of these experts have affiliations with Sherlock.
  • The UMA Optimistic Oracle -- because SPCC members may be affiliated with Sherlock, a protocol can also submit its claim to the UMA Optimistic Oracle. The strengths of this committee are its numbers (thousands of UMA tokenholders) and lack of affiliation to Sherlock. However, this committee may take more time and start with less expertise around security issues.

While not a panacea, a protocol team should feel good about at least one of these committees making the correct choice when it counts.

What Makes Sherlock Different?

The space is chock full of different approaches to smart contract coverage. We think this is a great thing. The unfortunate reality is that no approach has been able to cover more than 1% of the TVL in DeFi. Of course, this lack of market penetration represents a huge opportunity for any approach that gets traction.

Generally, we support other approaches to smart contract coverage in the space and we are actively working on partnerships with some of them. The coverage market is extremely big and it is the Sherlock team’s belief that the space will benefit the most from many different providers and approaches.

There are generally three things that separate Sherlock’s approach from all others:

  • B2B instead of B2C
    • This is a key tenet of Sherlock’s approach. If crypto and DeFi are going to scale to a billion users, you can’t expect all of those users to manage their own coverage positions -- it’s not an easy task. Nobody likes buying and managing coverage and the reality is that 99% of addresses affected by exploits haven’t purchased coverage. So who pays when an exploit happens? Often the protocol. As we’ve seen time and again, it is the protocol team that gets the blame and loses trust when an exploit occurs. It is also the protocol team or supporters that usually try to pay back the hack, often with much difficulty.
    • Most traditional financial applications also bake in coverage to their products. This is the user experience that people are used to. All US banks have FDIC insurance and applications like Coinbase also have coverage on their hot money funds.
    • Last, protocols are used to paying up for security. It’s essentially table stakes to spend six figures on security even as an upstart protocol. “Blue chip” protocols like Compound and Maker spend millions each year. Smart contract coverage is essentially the gold standard for security, so it makes sense that protocols would be willing to add it to their security budget, as we’ve already seen many do with Sherlock.
  • Security Expert Pricing
    • Many protocols have taken a “set it and forget it” approach to pricing smart contract risk. Picking arbitrary values and using utilization curves to increase pricing as demand rises.
    • Sherlock believes that getting the pricing right is absolutely essential to a properly functioning coverage provider. The Sherlock team has experience in machine learning which is precisely why we’ve chosen not use it for pricing. For ML to work successfully, you need a LOT of data. If you will have a lot of features, you’ll need EVEN MORE data. The number of positives samples in smart contract data is low (a few hundred at best) and the number of features is very high (probably in the hundreds as well). This is a really difficult setup for isolating signal in ML/AI/data science/actuarial science.
    • Sherlock has instead decided to start out with a fundamental approach: working with top security experts to look at every line of code in a potential protocol and decide the risk from there. The B2B approach makes this possible. And proper incentivization of security experts makes it powerful.
  • Trustless, Unbiased Claims Process
    • The claims process is probably the most important piece of any coverage protocol for a potential customer. If a protocol is going to pay for coverage, how do they know they’ll get repaid if the worst occurs?
    • Other coverage protocols tend to fall into two camps:
      • Coverage protocol tokenholders decide. This is a huge conflict of interest because protocol tokenholders often suffer directly and indirectly by approving a claim. It’s essentially asking someone to vote money out of their pocket and into yours.
      • The code decides. This is known as parametric payouts. Parametric payouts are tricky because they can’t reason about unknown unknowns, the exploit-detecting code often shares logic with the code in question, and smart contract risks can be hard to isolate from other risks. The last point is important because it means the price of coverage may converge with the APY of the opportunity, rendering coverage useless.
    • Sherlock utilizes a fully trustless process made up of two distinct committees:
      • The Sherlock Claims Committee is made up of top smart contract experts in the space such as John Mardlin and Rajeev Gopalakrishna. These experts are public figures with reputation outside of any involvement with Sherlock. And they are experts in the field so they can make quick and accurate decisions.
      • If a protocol customer thinks that process is unfair for any reason, they can escalate the claim to UMA’s Optimistic Oracle. This functions much like an on-chain jury: slower-moving and without the expertise, but the chances of bias or collusion (among thousands of jury members) are extremely low.

Sherlock Security Practices

Unfortunately, Sherlock can’t use itself to stay secure.

Because of this, Sherlock’s V2 codebase is one of the smallest and simplest codebases in DeFi. We let our customers have the fun, while Sherlock itself stays extremely conservative in terms of development:

  • No oracles
  • No assembly code
  • No proxy patterns
  • Codebase only on Ethereum L1
  • $500k bug bounty (will at least double in a few weeks)

In terms of audits, we’ve tried to get the largest number of skilled auditors to look at the V2 codebase:

  • Trail of Bits audit in December 2021
  • Secureum security review with 24 Secureum participants in December 2021
  • Code Arena audit with 15 independent auditors in February 2021

Go-To Market

Sherlock’s top priority will always be quality underwriting. The ability to grow is important as well, but Sherlock is entering a completely new market space and the top priority is to prove the viability of this unique model and build trust behind it.

Because of this priority, Sherlock’s underwriting standards are extremely high. Sherlock unfortunately doesn’t take on most protocols as customers out of the box, because most protocols don’t meet Sherlock’s high security standards.

Sherlock is very focused on EVM-compatible protocols on high quality chains. We’ve found Ethereum L1 to be plentiful grounds for high-quality protocols that put security first, so that has been our main focus. However, Sherlock’s services can apply just as easily to any EVM-compatible chain, and with a bit more legwork we can get to non-EVM compatible chains and bridges as well.

Because of Sherlock’s risk limits and focus on bootstrapping the staking pool, most protocols that fit well into the Sherlock model are small to medium sized. That will change as Sherlock’s staking pool grows. We are also excited about ancillary products such as bug bounty coverage which can apply to even the largest protocols in the space.

Right now, our early offering to a protocol tends to look like this:

  • $10M of smart contract coverage
  • $1M bug bounty of critical vulnerabilities paid for by Sherlock
  • Security reviews and connections to vetted security firms/experts for code updates
  • The all-in cost to the protocol for this package is ~$16k per month (a 2% fee on $10M of coverage)

One of the most important ratios for Sherlock is the coverage-to-capital ratio (CTC). If the CTC is too low, Sherlock will not attract enough capital into the staking pool. If the CTC is too high, capital providers may become uncomfortable. Right now Sherlock is in the bootstrapping phase so the CTC has been too low. In the near-term, we think a 3x to 5x CTC ratio is very healthy. We may end up capping this ratio somewhere around 10x, but we think that new capital will enter the staking pool long before we get there (because the USDC APY will be approaching 20% not including yield strategies).

Customers

We’ve publicly announced coverage with Euler (lead investor: Paradigm), Opyn (lead investor: Paradigm), Primitive (lead investor: Framework), Teller (lead investor: Framework) and new coverage starting on Feb 15th with Tempus (lead investor: Lemniscap). Look out for more announcements in the coming weeks. The demand for coverage has been strong and we’ve been struggling to keep up.

We have also had to turn down or defer the vast majority of protocols that approach us for coverage because of the high bar we set around security practices. This should be a temporary phenomenon as many of those protocols are now working to clear the bar and Sherlock is working on a few tools that can help new protocols understand and clear the bar more easily.

Near-Term Roadmap

Sherlock is covering 5 protocols currently and, based on the pipeline, the team would expect to roughly double that number in the next 3 months.

By the end of the year, Sherlock plans to cover ~20 of the most secure protocols in crypto, which would translate to at least $200M in coverage outstanding and at least $4M in premiums.

Sherlock’s Future

Sherlock plans to become the be-all and end-all solution for smart contract security. Crypto is a dark forest and protocols often have no one in their corner when it comes to securing their protocol.

Because Sherlock will have massive skin-in-the-game alongside protocols, teams will finally have a trusted partner that they can turn to for opinionated smart contract audits, follow-up security reviews, bug bounty programs and general code practices. Sherlock will set the standard for building practices and self-regulation in DeFi, much like the early beginnings of the fire insurance industry.

This will make Sherlock an invaluable and irreplaceable partner for DeFi protocols, as well as a trailblazer in creating recourse for smart contract hacks. This will allow DeFi to be trusted by users and achieve its full potential.

On the staking side, Sherlock will offer the highest risk-adjusted yields in all of DeFi to stakers. How will this be possible? Pick your favorite high-yielding protocol in DeFi. Sherlock will invest staking pool funds into that protocol, then pay 10% to 20% on top of that through premiums. All organic and no token incentives necessary.

By year end, Sherlock will have millions of dollars flowing through the platform. At scale, this will be billions. Because of the nature of this business model, Sherlock will always be able to pay more than anyone else for security talent.

This will create an ecosystem where all security spend in DeFi flows through Sherlock and is directed by Sherlock. The potential for monetization is obvious. And as the first-mover, Sherlock will be able to lock in partnerships with the largest and most secure protocols in DeFi. Any B2B competitors will have an adverse selection problem when bringing on new protocols, and any B2C competitors will need to target protocols that don’t already have B2B coverage.

At the end of the day, Sherlock’s adoption will create a safer DeFi ecosystem and allow end users to feel more comfortable placing their trust and money into a cryptographic financial system. This has been the goal of Sherlock since Day 1 and will continue to be the goal.

Team

The Sherlock team is strong and growing. The founders of Sherlock marry years of experience investing in banks and insurance companies at Citadel with years of experience writing Solidity contracts on Ethereum (since 2018) and working in cybersecurity.

The rest of the core team has relevant experience such as investing in cybersecurity at Mark Asset Management, years of Silicon Valley engineering experience and nearly everyone has been an entrepreneur at some point.

We believe the collective background of the team is the right one to create a new archetype of smart contract security in crypto.

Support

Sherlock is lucky to have the support of some of the most talented angels, VCs and advisors in crypto:

  • Angels: Kain Warwick, Ric Burton, Mariano Conti, Hart Lambur, and many others
  • VCs: Dragonfly Capital, GSR, IDEO CoLab Ventures, A Capital, Scalar Capital, Lattice Capital, Maven 11, CoinFund, LedgerPrime, DeFi Alliance
  • Advisors: John Mardlin, Rajeev Gopalakrishna, Greg DiPrisco

Tokenomics

See the “Guide to SHER Tokenomics” for a breakdown of SHER token allocations and unlock schedules.

Raise Details

Sherlock is looking to raise $2.5M in its seed round. The valuation is still being finalized. There will likely be a 1-year lockup followed by a 24-month linear vesting schedule.

Funds are expected to be used for general operating purposes such as continuing to build out the engineering and business development teams at Sherlock as well as costs related to continued development of the Sherlock protocol, like audits.

Reviews

Don’t take it from us. Here’s what our customers have had to say:

Contact

Feel free to reach out to Jack Sanford with any questions/comments or to set up a meeting.

Telegram: @jsanford9292
Email: jack@sherlock.xyz

Subscribe to Sherlock
Receive the latest updates directly to your inbox.
Verification
This entry has been permanently stored onchain and signed by its creator.