Sherlock V2
  • ๐Ÿ‘‹Intro to Sherlock
  • ๐Ÿ™‹FAQ
  • ๐Ÿ“šGlossary
  • โ€ผ๏ธDisclaimers
  • Audits
    • ๐Ÿง‘โ€๐Ÿ’ปProtocol Teams
      • How it Works for Protocols
      • Audit Timeline
      • Scheduling Process
      • Audit Preparation
      • Protocol Involvement During the Audit Process
      • Protocol Involvement Post-Audit
      • Rescheduling and Cancellations
      • Interim Updates and Upgrades
    • ๐Ÿ•ต๏ธWatsons
      • Lead Senior Watson Selection Process
      • Fix Review Process
      • Contest Points
      • How to Score Issue Points in a Contest
      • Meeting the Payout Criteria
      • First Blood Pot
      • Leaderboard Points Example
      • FAQ
    • ๐Ÿง‘โ€โš–๏ธJudging
      • Judging Conduct Guidelines
      • Criteria for Issue Validity
        • Criteria Changelog
      • Lead Judge
      • ๐Ÿง‘โ€โš–๏ธCommunity Judging
      • Dedicated Judge
      • Discussion
      • Sherlock's Exclusive Judging Apprentice Program
    • ๐ŸคReferral Program
  • Bug Bounties
    • ๐ŸŒฑPre-Launch Bounty
    • ๐Ÿš€Post-Launch Bounty
      • ๐Ÿ“œPlatform Rules
      • โš–๏ธDispute Resolution
  • Coverage
    • ๐Ÿ›ก๏ธSherlock Shield
    • ๐Ÿ’ฐStakers
      • Overview
      • Lockup Period
      • Payout Flow
      • Staking APY
    • ๐Ÿง‘โ€๐Ÿ’ปProtocol Teams
      • Getting Started
      • Coverage Premiums
      • Pricing
      • Composability and Coverage
      • Payout Flow
      • FAQ
    • ๐Ÿ“Claims
      • Claims Process
  • Tokens
    • SHER
    • Receipt NFTs
  • Governance
    • Roles
  • Developer
    • Overview
    • Stake Position Lifecycle
    • Claim Lifecycle
    • Protocol Lifecycle
    • SHER Distribution
    • Deployed Contracts
    • Contract Reference
    • Audits
Powered by GitBook
On this page
  1. Coverage
  2. Protocol Teams

Composability and Coverage

PreviousPricingNextPayout Flow

Last updated 1 year ago

Sherlock recognizes that composability and a protocolโ€™s need to integrate with other projects is a valuable part of the DeFi ecosystem. However, for the security of Sherlockโ€™s staking pool, and consequently its covered customers, Sherlock needs to take a slightly risk-averse approach to how integrations are covered.

Both extremes of composability/integrations are problematic. On one extreme, itโ€™s unreasonable for Sherlock to only cover integrations that are done with protocols previously audited by Sherlock. However, itโ€™s equally unreasonable to expect Sherlock to cover any integration under the sun. So, Sherlock is taking an incremental approach, where the covered integrations will include a whitelisted set of protocols, as well as any protocol that has previously been audited by Sherlock.

The current list (which will be updated periodically) can be found .

If the uncovered protocol has coverage from Sherlock or another coverage provider, and a payout takes place (or is scheduled to take place) for that protocol, and the Protocol Customer receives reimbursement from that payout, then the total amount possible to be paid out to the Protocol Customer will be netted against the first payout. This is to ensure that Sherlock doesnโ€™t pay the same affected party double their loss amount. In the event of a covered smart contract exploit or economic exploit, the Protocol Customer can submit a claim and be reimbursed for lost on-chain funds up to the stated Active Coverage Amount at the start block of the exploit. If for any reason the affected user(s) or affected protocol(s) see a partial or full return of the exploited funds before or after a payout from Sherlock, the returned funds must be deducted from the Sherlock payout and any amount paid out by Sherlock relating to the returned funds that had been lost (as part of a claim) must be returned to Sherlock.

๐Ÿง‘โ€๐Ÿ’ป
here