DAO Proposal: Sherlock

Hey MetaCartel! Been following you guys for a while and excited to finally be posting a proposal!

Sherlock

A Better Alternative to DeFi Insurance

Mission

Sherlock’s goal is to bring DeFi to mass adoption. One of the biggest blockers we see is the security of DeFi. Audits are great but they aren’t 100% effective. Existing insurance is missing the mark and covers less than 3% of TVL in DeFi. Sherlock has a novel approach that we’ve already gotten a ton of validation for.

Problem

Existing insurance fails mainly on two fronts: affordability and user experience.

Solution

Sherlock makes insurance affordable by selling wholesale to protocols and integrating an internal team of smart contract security experts to accurately price insurance in DeFi (something that is sorely missing). And Sherlock makes the user experience easy by working with protocols to insure their TVL so users never need to worry about insurance – they are always covered.

Protocol Design

At the heart of the protocol, there’s a pool of tokens that’s set aside to reimburse hacks for any of the protocols we cover. There are 3 main parties who interact with the pool:

Protocols
Protocols pay a small fee in exchange for full coverage against hacks. The fee is decided by our team of security experts who conduct diligence on the protocol and decide on a fair price.

Stakers
Stakers put tokens into the insurance pool in exchange for one of the highest yields in DeFi. Protocols fees go into the pool and contribute to the yield for stakers. In the event of a hack, funds contributed by stakers reimburse the users of the hacked protocol.

Security Team
Our internal security team does research on protocols who want coverage and gives them a price for that coverage. The team’s compensation is based on the return to stakers. If stakers get more fees from protocols, the team’s compensation will be higher. If stakers pay out significant amounts for hacks, the team’s compensation will be lower.

Progress

Sherlock was created in the MarketMake hackathon in February. You can see our project here. We’ve since re-branded to Sherlock – would link but Discourse won’t let me post more than two links :frowning: and are working on a mainnet launch which we see coming in 6-8 weeks (including audits).

Traction

We’ve gotten really great responses from customers and are working super closely with Badger DAO ($1.5Bn TVL) to be one of our first customers when we launch. Other customers on our waitlist include Matic/Polygon, PieDAO and Superfluid.

Team

Jack Sanford (full-time): Biz Dev / Full-stack (jack__sanford on twitter)
Evert Kors (full-time): Backend / Smart Contracts (Evert0x on twitter)

Ask

5000 DAI to get Sherlock to mainnet.

Since we’re building out an internal smart contract security team, we think we can get massive discounts on audits (or free ones hopefully), so we need funding to bridge our frontend guy so he can leave his job as well as for deploying contracts to mainnet.

Plan

We have finished the protocol design (can share that with you guys soon) and we’re translating it into Solidity which should take about 3 weeks. Our frontend is on a similar timeline and we think we can get audits done over the course of the following 2 weeks. Our goal is to get 5 protocols covered with our insurance and we think we can hit that in the next 3 months.

Check us out on Twitter for more info (pinned) about our protocol as well as for updates! And feel free to reach me at jsanford9292 on Telegram. Looking forward to your feedback!

Interesting idea! Theres definitely room for more insurance, I wish Furucombo had some for me last week. But how can you be sure the amount the protocols are paying is enough to cover hacks?

Should the existing customers have a say in who else will join and contribute to the pot? Existing protocols wouldnt want to share the cost / risk with some random yearn thing that someone cranked out in a day and is alphaware with no audits.
I’d like to see your protocol design before funding this since I’m not sure its actually practical even if it works theoretically

Hey Joseph!

Thanks for your comment and your interest. Really great questions.

“How can you be sure the amount the protocols are paying is enough to cover hacks?”

^This is the hardest question by far in the insurance space. We’ve designed our entire protocol around it actually. Our protocol design rests on an incentivized security team that assesses protocol risk for any protocol we may cover. This team decides which price would make it worthwhile for Sherlock to cover the protocol given the estimated security risks surrounding it. The team’s compensation is entirely based on their accuracy in this assessment (if a covered protocol gets hacked, the security team’s compensation is slashed).

Like stakers, existing customers will need to trust the capabilities and incentive structure of the security team that does the assessments. We think they are best suited to analyzing protocol risk (even better than other customers who think they understand the risks around yearn, etc.). They also would need to get very comfortable around insuring an “alphaware” protocol with no audits and the internal security processes said protocol employs. Existing customers just need to feel comfortable that the insurance pool won’t be drained by a less secure protocol. There are two factors that mitigate this:

  1. We charge “riskier” protocols a higher fee, meaning that stakers will be more incentivized to stake funds into the pool and the pool will grow faster due to the higher fees of “risky” protocols. In the end, it should all be a wash since we expect “risky” protocols to be hacked more.

  2. Because “riskier” protocols get charged a higher price (it could even be magnitudes higher, say 10x higher), it likely won’t be economical/affordable for the “riskiest” protocols to pay for our insurance – this would naturally preclude them from the pool.

As for the protocol design, we don’t share this much outside of a small circle of advisors but here’s a good primer on how we are currently thinking about it. Please don’t send this around any more than you need to: